Diese WordPress htaccess ist die perfekte .htaccess für dein WordPress und sorgt für einen enormen Performanceschub und ein hohes Sicherheitslevel. Setze meine über 10 Jahre perfektionierte WordPress .htaccess Datei für dein WordPress-Tuning ein und freue dich über beste Ergebnisse und enorm viel Zuwachs an Sicherheit.
Mehr als zehn Jahre Erfahrung sind in meine perfekte .htaccess Datei eingeflossen und sie wurde von Jahr zu Jahr stets verbessert und überarbeitet.
Letztes Update der WordPress .htaccess: 03.03.2025 / Version 2.0.12
- Dazugekommen: Aggressives Scannen nach Uploads-relevanten Zielen vereiteln – 27.08.2020
- Dazugekommen: der Strict Origin When Cross Origin Security Header – 10.08.2020
- Dazugekommen: Ultimate Hotlink Protection in 2018
- Dazugekommen: Adminbereich mit HTTP Schutz versehen in 2018
Aktualisiert 08 / 2019: 7G Firewall auf 6G Firewall @2019Aktualisiert: Strict Transport Security Header mit korrektem »max-age« Eintrag- Dazugekommen: Referrer-Policy Header am 05.06.2018
- Dazugekommen: Block Nuisance Requests
- Dazugekommen in 2019: Der Schutz gegen den »ReallyLongRequest« Bot
- Dazugekommen in 2019: Der experimentelle Security Header EXPECT-CT
- Update 02/2020: 6G Firewall auf 7G Firewall aktualisiert
- Update 05/2021: Cache-Laufzeiten für Grafikformate und Fonts optimiert
- Update 11/2021: 7G-Firewall auf Version 1.5 aktualisiert
- Update 01/2022: Security Header „upgrade-insecure-requests“
- Update 05/2022: Security Header „Permissions-Policy Header“
- Update 08/2022: Caching für JavaScript-Module (
.mjs) – 2.0.5 - Update 10/2022: Neue WordPress Version 6 Standardregeln – 2.0.6
- Update 12/2022: Expect-CT Header entfernt, weil veraltet.
- Update 12/2022: WordPress-Autoren-Scans blockieren
- Update 04/2023: 7G-Firewall auf Version 1.6 aktualisiert.
- Update 03/2024: Die 8-G-Firewall ersetzt die 7-G-Firewall
- Update 03/2024: 7G-Addon gegen das 8G-Addon getauscht
- Update 06/2024: Strict Transport Security Header gesetzt auf den empfohlenen Wert von zwei Jahren
- Update 03/2025: Update der 8G-Firewall auf Version 1.4
Du magst dich vielleicht wundern, dass die Datei nicht gerade ein Leichtgewicht ist. Doch das Laden dieser Datei dauert nur einen Wimpernschlag. Der Effekt auf deine Website hingegen ist enorm. Ohne weitere Optimierungen wird dein WordPress schon deutlich schneller werden, weil alle wichtigen Bereiche komprimiert und gecacht werden. Und damit bildet diese Datei auch eine der Grundlagen für die Suchmaschinenoptimierung.
Alle optionalen Elemente sind mit Rauten (#) auskommentiert, zur Nutzung diese bitte entfernen.
Die perfekte .htaccess Datei teilt sich in 15 einzelne Bereiche auf:
- HTTP zu HTTPS Umleitung
- CORS aktivieren für bestimmte Dateitypen
- Block Nuisance Requests (Lästige Anfragen blocken) – aktualisiert 07/2019
- Dateien komprimieren und cachen
- Die 8G-Firewall von Jeff Starr gegen die Einschleusung von Schadcode
- Das 8G Addon gegen das aggressive Scannen von Upload-Dateien
- Das Blocken von WordPress-Dateien gegen Zugriff von außen
- Hotlink Protection gegen das Verlinken Deiner Bilder auf anderen Websites – 2018
- Das Blockieren von externen Scans der Autorennamen
- Blocking the »ReallyLongRequest« Bandit – Neu in 2019
- Das Schützen des Adminbereichs mittels HTTP – 2018
- Das Blocken des Sicherheitsrisikos XML-RPC
- Der Referrer Header – 05.06.2018
- Die HTTP-Security-Header
- Die WordPress Standard-Regeln
Deine Wettbewerber werden bei Google besser gefunden als Du?
Mit unserer laufenden SEO Betreuung wirst Du schnell bessere Rankings in Googles Suchergebnissen erreichen und so mehr Kunden gewinnen und mehr Umsatz erzielen.
Übrigens: Hier erfährst Du, wie Du Deine Cloud Sicherheit herstellst
Die WordPress htaccess als Zip-Datei zum Download
Falls Du Probleme mit dem Einbau der .htaccess bekommst, die SEO Agentur Hamburg kann diesen Job kostenpflichtig für Dich erledigen.
Die perfekte WordPress htaccess, die einzelnen Bereiche
1 – Garantierte HTTP zu HTTPS Umleitung
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>Dieser Code sorgt im Gegensatz zu anderen Schnipseln für eine garantierte Weiterleitung aller HTTP-Anfragen auf die HTTPS-Version. In der .htaccess ist dieser Bereich auskommentiert, wenn du den Code nutzen möchtest, entferne die Rauten vor den einzelnen Elementen. Falls es zu Problemen mit diesem Code kommt, existiert bereits irgendwo in Deiner Installation eine Umleitung von HTTP auf HTTPS.
Mehr zum Thema: Garantierte Weiterleitung von HTTP zu HTTPS
Auch interessant: .htaccess Weiterleitung aller Seiten
2 – CORS aktivieren für bestimmte Dateitypen
Was genau ist CORS?
Cross-Origin Resource Sharing (CORS) ist ein Mechanismus, der Webbrowsern oder auch anderen Webclients Cross-Origin-Requests ermöglicht. … CORS ist ein Kompromiss zugunsten größerer Flexibilität im Internet unter Berücksichtigung möglichst hoher Sicherheitsmaßnahmen.
CORS ist ein wichtiger Beitrag zu einer Sicherheitsstrategie in Verbindung mit einer Content Security Policy. Solltest Du diese Strategie einsetzen, dann ist dieser Teil bereits in meiner Datei enthalten.
Eine Website umfasst vieles. Eine perfekte .htaccess gehört dazu.<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js|mjs|gif|png|jpe?g|svg|svgz|ico|webp)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>3 – Block Nuisance Requests (lästige Anfragen blocken)
Manche Bots suchen sehr emsig nicht existente Dateien auf Deinem Server / Webhosting und blockieren auf diese Weise die Ressourcen des Hostings. Der böswillige Datenverkehr spamt zudem die Fehlerprotokolle des Servers zu, sodass eigentliche Probleme durch diese Anfragen an nicht existente Dateien kaum mehr gefunden werden.
Auf günstigen Shared-Hostings können diese Anfragen durchaus Deine Website in die Knie zwingen und sehr langsam machen. Daher: gleich blockieren.
# ----------------------------------------------------------------------
# | BLOCK NUISANCE REQUESTS - @Update 2019
# https://perishablepress.com/block-nuisance-requests
# ----------------------------------------------------------------------
<IfModule mod_alias.c>
RedirectMatch 403 (?i)\.php\.suspected
RedirectMatch 403 (?i)apple-app-site-association
RedirectMatch 403 (?i)/autodiscover/autodiscover.xml
</IfModule>4 – Dateien komprimieren und cachen
Update 08/2022 – Support für JavaScript Module (.mjs Dateien)
Dieser Bereich ist der umfassendste. Doch jede einzelne Zeile Code ist für die Performance deiner Website wichtig. Jede Dateiart wird komprimiert an den Browser ausgeliefert und in diesem optimal in den Cache aufgenommen. Auch wenn du Plugins wie zum Beispiel Autoptimize und Cache Enabler einsetzt, muss dieser Abschnitt sein, denn er ergänzt diese Plugins für noch mehr Speed.
# Serve resources with far-future expires headers.
#
# (!) If you don't control versioning with filename-based
# cache busting, you should consider lowering the cache times
# to something like one week.
#
# https://httpd.apache.org/docs/current/mod/mod_expires.html
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 1 month"
# CSS
ExpiresByType text/css "access plus 1 year"
# Data interchange
ExpiresByType application/atom+xml "access plus 1 hour"
ExpiresByType application/rdf+xml "access plus 1 hour"
ExpiresByType application/rss+xml "access plus 1 hour"
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType application/ld+json "access plus 0 seconds"
ExpiresByType application/schema+json "access plus 0 seconds"
ExpiresByType application/vnd.geo+json "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType text/xml "access plus 0 seconds"
# Favicon (cannot be renamed!) and cursor images
ExpiresByType image/vnd.microsoft.icon "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 week"
# HTML - Behält die Website eine Stunde im Cache, neues wird erst nach Ablauf einer Stunde
# angezeigt. Wenn nicht gewuenscht, bei 3600 eine Null eintragen
ExpiresByType text/html "access plus 0 seconds"
# JavaScript
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
# Manifest files
ExpiresByType application/manifest+json "access plus 1 week"
ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds"
ExpiresByType text/cache-manifest "access plus 0 seconds"
# Media files
ExpiresByType audio/ogg "access plus 1 year"
ExpiresByType image/bmp "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType video/mp4 "access plus 1 year"
ExpiresByType video/ogg "access plus 1 year"
ExpiresByType video/webm "access plus 1 year"
# Web fonts
# Embedded OpenType (EOT)
ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
ExpiresByType font/eot "access plus 1 year"
# OpenType
ExpiresByType font/opentype "access plus 1 year"
# TrueType
ExpiresByType application/x-font-ttf "access plus 1 year"
# Web Open Font Format (WOFF) 1.0
ExpiresByType application/font-woff "access plus 1 year"
ExpiresByType application/x-font-woff "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
# Web Open Font Format (WOFF) 2.0
ExpiresByType application/font-woff2 "access plus 1 year"
# Other
ExpiresByType text/x-cross-domain-policy "access plus 1 week"
</IfModule>
<IfModule mod_deflate.c>
# Insert filters / compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/vtt
AddOutputFilterByType DEFLATE text/x-component
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/js
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/atom+xml
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE application/ld+json
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/font-woff2
AddOutputFilterByType DEFLATE application/x-font-woff
AddOutputFilterByType DEFLATE application/x-web-app-manifest+json font/woff
AddOutputFilterByType DEFLATE font/woff
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
# Exception: Images
SetEnvIfNoCase REQUEST_URI \.(?:gif|jpg|jpeg|png|svg)$ no-gzip dont-vary
# Drop problematic browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</IfModule>
#Alternative caching using Apache's "mod_headers", if it's installed.
#Caching of common files - ENABLED
<IfModule mod_headers.c>
<FilesMatch "\.(ico|pdf|flv|swf|js|mjs|css|gif|png|jpg|jpeg|txt|woff2|woff)$">
Header set Cache-Control "max-age=31536000, public"
</FilesMatch>
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "\.(js|mjs|css|xml|gz)$">
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
# Set Keep Alive Header
<IfModule mod_headers.c>
Header set Connection keep-alive
</IfModule>
# If your server don't support ETags deactivate with "None" (and remove header)
<IfModule mod_expires.c>
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
FileETag None
</IfModule>
<IfModule mod_headers.c>
<FilesMatch ".(js|mjs|css|xml|gz|html|woff|woff2|ttf)$">
Header append Vary: Accept-Encoding
</FilesMatch>
</IfModule>5 – 8G-Firewall gegen die Einschleusung von Schadcode
Dieser Abschnitt sorgt für echte Sicherheit. Immer wieder weisen Plugins und Themes eklatante Sicherheitslücken auf, durch die man Schadcode in eine Website einschleusen könnte. Diese Firewall schiebt dem einen Riegel vor und blockt die gängigen Methoden der Einschleusung.
Wenn Dich die WordPress Sicherheit interessiert, dann schaue Dir diesen Artikel an: WordPress absichern wie ein Profi.
# 8G FIREWALL v1.4 20250120
# https://perishablepress.com/8g-firewall/
# 8G:[CORE]
ServerSignature Off
Options -Indexes
RewriteEngine On
RewriteBase /
# 8G:[QUERY STRING]
<IfModule mod_rewrite.c>
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC,OR]
RewriteCond %{QUERY_STRING} ([a-z0-9]{4000,}) [NC,OR]
RewriteCond %{QUERY_STRING} (/|%2f)(:|%3a)(/|%2f) [NC,OR]
RewriteCond %{QUERY_STRING} (etc/(hosts|motd|shadow)) [NC,OR]
RewriteCond %{QUERY_STRING} (order(\s|%20)by(\s|%20)1--) [NC,OR]
RewriteCond %{QUERY_STRING} (/|%2f)(\*|%2a)(\*|%2a)(/|%2f) [NC,OR]
RewriteCond %{QUERY_STRING} (`|<|>|\^|\|\\|0x00|%00|%0d%0a) [NC,OR]
RewriteCond %{QUERY_STRING} (f?ckfinder|f?ckeditor|fullclick) [NC,OR]
RewriteCond %{QUERY_STRING} ((.*)header:|(.*)set-cookie:(.*)=) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|127(\.|%2e)0(\.|%2e)0(\.|%2e)1) [NC,OR]
RewriteCond %{QUERY_STRING} (cmd|command)(=|%3d)(chdir|mkdir)(.*)(x20) [NC,OR]
RewriteCond %{QUERY_STRING} (globals|mosconfig([a-z_]{1,22})|request)(=|\[) [NC,OR]
RewriteCond %{QUERY_STRING} (/|%2f)((wp-)?config)((\.|%2e)inc)?((\.|%2e)php) [NC,OR]
RewriteCond %{QUERY_STRING} (thumbs?(_editor|open)?|tim(thumbs?)?)((\.|%2e)php) [NC,OR]
RewriteCond %{QUERY_STRING} (absolute_|base|root_)(dir|path)(=|%3d)(ftp|https?) [NC,OR]
RewriteCond %{QUERY_STRING} (s)?(ftp|inurl|php)(s)?(:(/|%2f|%u2215)(/|%2f|%u2215)) [NC,OR]
RewriteCond %{QUERY_STRING} (\.|20)(get|the)(_|%5f)(permalink|posts_page_url)(\(|%28) [NC,OR]
RewriteCond %{QUERY_STRING} ((boot|win)((\.|%2e)ini)|etc(/|%2f)passwd|self(/|%2f)environ) [NC,OR]
RewriteCond %{QUERY_STRING} (((/|%2f){3,3})|((\.|%2e){3,3})|((\.|%2e){2,2})(/|%2f|%u2215)) [NC,OR]
RewriteCond %{QUERY_STRING} (benchmark|exec|fopen|function|html)(.*)(\(|%28)(.*)(\)|%29) [NC,OR]
RewriteCond %{QUERY_STRING} (php)([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}) [NC,OR]
RewriteCond %{QUERY_STRING} (e|%65|%45)(v|%76|%56)(a|%61|%31)(l|%6c|%4c)(.*)(\(|%28)(.*)(\)|%29) [NC,OR]
RewriteCond %{QUERY_STRING} (/|%2f)(=|%3d|$&|_mm|cgi(\.|-)|inurl(:|%3a)(/|%2f)|(mod|path)(=|%3d)(\.|%2e)) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3c)(.*)(e|%65|%45)(m|%6d|%4d)(b|%62|%42)(e|%65|%45)(d|%64|%44)(.*)(>|%3e) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3c)(.*)(i|%69|%49)(f|%66|%46)(r|%72|%52)(a|%61|%41)(m|%6d|%4d)(e|%65|%45)(.*)(>|%3e) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3c)(.*)(o|%4f|%6f)(b|%62|%42)(j|%4a|%6a)(e|%65|%45)(c|%63|%43)(t|%74|%54)(.*)(>|%3e) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3c)(.*)(s|%73|%53)(c|%63|%43)(r|%72|%52)(i|%69|%49)(p|%70|%50)(t|%74|%54)(.*)(>|%3e) [NC,OR]
RewriteCond %{QUERY_STRING} (\+|%2b|%20)(d|%64|%44)(e|%65|%45)(l|%6c|%4c)(e|%65|%45)(t|%74|%54)(e|%65|%45)(\+|%2b|%20) [NC,OR]
RewriteCond %{QUERY_STRING} (\+|%2b|%20)(i|%69|%49)(n|%6e|%4e)(s|%73|%53)(e|%65|%45)(r|%72|%52)(t|%74|%54)(\+|%2b|%20) [NC,OR]
RewriteCond %{QUERY_STRING} (\+|%2b|%20)(s|%73|%53)(e|%65|%45)(l|%6c|%4c)(e|%65|%45)(c|%63|%43)(t|%74|%54)(\+|%2b|%20) [NC,OR]
RewriteCond %{QUERY_STRING} (\+|%2b|%20)(u|%75|%55)(p|%70|%50)(d|%64|%44)(a|%61|%41)(t|%74|%54)(e|%65|%45)(\+|%2b|%20) [NC,OR]
RewriteCond %{QUERY_STRING} (\\x00|(\"|%22|\'|%27)?0(\"|%22|\'|%27)?(=|%3d)(\"|%22|\'|%27)?0|cast(\(|%28)0x|or%201(=|%3d)1) [NC,OR]
RewriteCond %{QUERY_STRING} (g|%67|%47)(l|%6c|%4c)(o|%6f|%4f)(b|%62|%42)(a|%61|%41)(l|%6c|%4c)(s|%73|%53)(=|\[|%[0-9A-Z]{0,2}) [NC,OR]
RewriteCond %{QUERY_STRING} (_|%5f)(r|%72|%52)(e|%65|%45)(q|%71|%51)(u|%75|%55)(e|%65|%45)(s|%73|%53)(t|%74|%54)(=|\[|%[0-9A-Z]{2,}) [NC,OR]
RewriteCond %{QUERY_STRING} (j|%6a|%4a)(a|%61|%41)(v|%76|%56)(a|%61|%31)(s|%73|%53)(c|%63|%43)(r|%72|%52)(i|%69|%49)(p|%70|%50)(t|%74|%54)(:|%3a)(.*)(;|%3b|\)|%29) [NC,OR]
RewriteCond %{QUERY_STRING} (b|%62|%42)(a|%61|%41)(s|%73|%53)(e|%65|%45)(6|%36)(4|%34)(_|%5f)(e|%65|%45|d|%64|%44)(e|%65|%45|n|%6e|%4e)(c|%63|%43)(o|%6f|%4f)(d|%64|%44)(e|%65|%45)(.*)(\()(.*)(\)) [NC,OR]
RewriteCond %{QUERY_STRING} (@copy|\$_(files|get|post)|allow_url_(fopen|include)|auto_prepend_file|blexbot|browsersploit|call_user_func_array|(php|web)shell|curl(_exec|test)|disable_functions?|document_root) [NC,OR]
RewriteCond %{QUERY_STRING} (elastix|encodeuricom|exploit|fclose|fgets|file_put_contents|fputs|fsbuff|fsockopen|gethostbyname|ghost|grablogin|hmei7|hubs_post-cta|input_file|invokefunction|(\b)load_file|open_basedir|outfile|p3dlite) [NC,OR]
RewriteCond %{QUERY_STRING} (pass(=|%3d)shell|passthru|phpinfo|phpshells|popen|proc_open|quickbrute|remoteview|root_path|safe_mode|shell_exec|site((.){0,2})copier|sp_executesql|sux0r|trojan|udtudt|user_func_array|wget|wp_insert_user|xertive) [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|\'|\"|\)|%0a|%0d|%22|%27|%3c|%3e|%00)(.*)(/\*|alter|base64|benchmark|cast|concat|convert|create|encode|declare|delay|delete|drop|hex|insert|load|md5|null|replace|request|script|select|set|sleep|truncate|unhex|update) [NC,OR]
RewriteCond %{QUERY_STRING} ((\+|%2b)(concat|delete|get|select|union)(\+|%2b)) [NC,OR]
RewriteCond %{QUERY_STRING} (union)(.*)(select)(.*)(\(|%28) [NC,OR]
RewriteCond %{QUERY_STRING} (concat|eval)(.*)(\(|%28) [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_QUERY_STRING:%1___%2___%3]
</IfModule>
# 8G:[REQUEST URI]
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_URI} (,,,) [NC,OR]
RewriteCond %{REQUEST_URI} (-------) [NC,OR]
RewriteCond %{REQUEST_URI} (\^|`|<|>|\\|\|) [NC,OR]
RewriteCond %{REQUEST_URI} ([a-z0-9]{2000,}) [NC,OR]
RewriteCond %{REQUEST_URI} (=?\\(\'|%27)/?)(\.) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(\*|\"|\'|\.|,|&|&?)/?$ [NC,OR]
RewriteCond %{REQUEST_URI} (\.)(php)(\()?([0-9]+)(\))?(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} /((.*)header:|(.*)set-cookie:(.*)=) [NC,OR]
RewriteCond %{REQUEST_URI} (\.(s?ftp-?)config|(s?ftp-?)config\.) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(f?ckfinder|fck/|fckeditor|fullclick) [NC,OR]
RewriteCond %{REQUEST_URI} (/)((force-)?download|framework/main)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (\{0\}|\"?0\"?=\"?0|\(/\(|\.\.\.|\+\+\+|\\\") [NC,OR]
RewriteCond %{REQUEST_URI} (/)(vbull(etin)?|boards|vbforum|vbweb|webvb)(/)? [NC,OR]
RewriteCond %{REQUEST_URI} (\.|20)(get|the)(_)(permalink|posts_page_url)(\() [NC,OR]
RewriteCond %{REQUEST_URI} (///|\?\?|/&&|/\*(.*)\*/|/:/|\\\\|0x00|%00|%0d%0a) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(cgi_?)?alfa(_?cgiapi|_?data|_?v[0-9]+)?(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (thumbs?(_editor|open)?|tim(thumbs?)?)((\.|%2e)php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)((boot)?_?admin(er|istrator|s)(_events)?)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/%7e)(root|ftp|bin|nobody|named|guest|logs|sshd)(/) [NC,OR]
RewriteCond %{REQUEST_URI} (archive|backup|db|master|sql|wp|www|wwwroot)\.(gz|zip) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(\.?mad|alpha|c99|php|web)?sh(3|e)ll([0-9]+|\w)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(admin-?|file-?)(upload)(bg|_?file|ify|svu|ye)?(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(etc|var)(/)(hidden|secret|shadow|ninja|passwd|tmp)(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} (s)?(ftp|http|inurl|php)(s)?(:(/|%2f|%u2215)(/|%2f|%u2215)) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(=|\$&?|&?(pws|rk)=0|_mm|_vti_|cgi(\.|-)|(=|/|;|,)nt\.) [NC,OR]
RewriteCond %{REQUEST_URI} (\.)(ds_store|htaccess|htpasswd|init?|mysql-select-db)(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} (/)(bin)(/)(cc|chmod|chsh|cpp|echo|id|kill|mail|nasm|perl|ping|ps|python|tclsh)(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} (/)(::[0-9999]|%3a%3a[0-9999]|127\.0\.0\.1|ccx|localhost|makefile|pingserver|wwwroot)(/)? [NC,OR]
RewriteCond %{REQUEST_URI} ^(/)(123|backup|bak|beta|bkp|default|demo|dev(new|old)?|new-?site|null|old|old_files|old1)(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} (/)?j((\s)+)?a((\s)+)?v((\s)+)?a((\s)+)?s((\s)+)?c((\s)+)?r((\s)+)?i((\s)+)?p((\s)+)?t((\s)+)?(%3a|:) [NC,OR]
RewriteCond %{REQUEST_URI} ^(/)(old-?site(back)?|old(web)?site(here)?|sites?|staging|undefined|wordpress([0-9]+)|wordpress-old)(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} (/)(filemanager|htdocs|httpdocs|https?|mailman|mailto|msoffice|undefined|usage|var|vhosts|webmaster|www)(/) [NC,OR]
RewriteCond %{REQUEST_URI} (\(null\)|\{\$itemURL\}|cast\(0x|echo(.*)kae|etc/passwd|eval\(|null(.*)null|open_basedir|self/environ|\+union\+all\+select) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(db-?|j-?|my(sql)?-?|setup-?|web-?|wp-?)?(admin-?)?(setup-?)?(conf\b|conf(ig)?)(uration)?(\.?bak|\.inc)?(\.inc|\.old|\.php|\.txt) [NC,OR]
RewriteCond %{REQUEST_URI} (/)((.*)crlf-?injection|(.*)xss-?protection|__(inc|jsc)|author-panel|cgi-bin|database|downloader|(db|mysql)-?admin)(/) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(haders|head|hello|helpear|incahe|includes?|indo(sec)?|infos?|ioptimizes?|jmail|js|king|kiss|kodox|kro|legion|libsoft)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(awstats|document_root|dologin\.action|error.log|extension/ext|htaccess\.|lib/php|listinfo|phpunit/php|remoteview|server/php|www\.root\.) [NC,OR]
RewriteCond %{REQUEST_URI} (base64_(en|de)code|benchmark|curl_exec|e?chr|eval|function|fwrite|(f|p)open|html|leak|passthru|p?fsockopen|phpinfo)(.*)(\(|%28)(.*)(\)|%29) [NC,OR]
RewriteCond %{REQUEST_URI} (posix_(kill|mkfifo|setpgid|setsid|setuid)|(child|proc)_(close|get_status|nice|open|terminate)|(shell_)?exec|system)(.*)(\(|%28)(.*)(\)|%29) [NC,OR]
RewriteCond %{REQUEST_URI} (/)((c99|php|web)?shell|crossdomain|fileditor|locus7|nstview|php(get|remoteview|writer)|r57|remview|sshphp|storm7|webadmin)(.*)(\.|%2e|\(|%28) [NC,OR]
RewriteCond %{REQUEST_URI} /((wp-)((201\d|202\d|[0-9]{2})|ad|admin(fx|rss|setup)|booking|confirm|crons|data|file|mail|one|plugins?|readindex|reset|setups?|story))(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(^$|-|\!|\w|\.(.*)|100|123|([^iI])?ndex|index\.php/index|3xp|777|7yn|90sec|99|active|aill|ajs\.delivery|al277|alexuse?|ali|allwrite)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(analyser|apache|apikey|apismtp|authenticat(e|ing)|autoload_classmap|backup(_index)?|bakup|bkht|black|bogel|bookmark|bypass|cachee?)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(clean|cm(d|s)|con|connector\.minimal|contexmini|contral|curl(test)?|data(base)?|db|db-cache|db-safe-mode|defau11|defau1t|dompdf|dst)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(elements|emails?|error.log|ecscache|edit-form|eval-stdin|evil|fbrrchive|filemga|filenetworks?|f0x|gank(\.php)?|gass|gel|guide)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(logo_img|lufix|mage|marg|mass|mide|moon|mssqli|mybak|myshe|mysql|mytag_js?|nasgor|newfile|news|nf_?tracking|nginx|ngoi|ohayo|old-?index)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(olux|owl|pekok|petx|php-?info|phpping|popup-pomo|priv|r3x|radio|rahma|randominit|readindex|readmy|reads|repair-?bak|robot(s\.txt)?|root)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(router|savepng|semayan|shell|shootme|sky|socket(c|i|iasrgasf)ontrol|sql(bak|_?dump)?|support|sym403|sys|system_log|test|tmp-?(uploads)?)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(traffic-advice|u2p|udd|ukauka|up__uzegp|up14|upa?|upxx?|vega|vip|vu(ln)?(\w)?|webroot|weki|wikindex|wordpress|wp_logns?|wp_wrong_datlib)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(wp-?install|installation|wp(3|4|5|6)|wpfootes|wpzip|ws0|wsdl|wso(\w)?|www|(uploads|wp-admin)?xleet(-shell)?|xmlsrpc|xup|xxu|xxx|zibi|zipy)(\.php) [NC,OR]
RewriteCond %{REQUEST_URI} (bkv74|cachedsimilar|core-stab|crgrvnkb|ctivrc|deadcode|deathshop|dkiz|e7xue|eqxafaj90zir|exploits|ffmkpcal|filellli7|(fox|sid)wso|gel4y|goog1es|gvqqpinc) [NC,OR]
RewriteCond %{REQUEST_URI} (@md5|00.temp00|0byte|0d4y|0day|0xor|wso1337|1h6j5|3xp|40dd1d|4price|70bex?|a57bze893|abbrevsprl|abruzi|adminer|aqbmkwwx|archivarix|backdoor|beez5|bgvzc29) [NC,OR]
RewriteCond %{REQUEST_URI} (handler_to_code|hax(0|o)r|hmei7|hnap1|home_url=|ibqyiove|icxbsx|indoxploi|jahat|jijle3|kcrew|keywordspy|laobiao|lock360|longdog|marijuan|mod_(aratic|ariimag)) [NC,OR]
RewriteCond %{REQUEST_URI} (mobiquo|muiebl|nessus|osbxamip|phpunit|priv8|qcmpecgy|r3vn330|racrew|raiz0|reportserver|r00t|respectmus|rom2823|roseleif|sh3ll|site((.){0,2})copier|sqlpatch|sux0r) [NC,OR]
RewriteCond %{REQUEST_URI} (sym403|telerik|uddatasql|utchiha|visualfrontend|w0rm|wangdafa|wpyii2|wsoyanzo|x5cv|xattack|xbaner|xertive|xiaolei|xltavrat|xorz|xsamxad|xsvip|xxxs?s?|zabbix|zebda) [NC,OR]
RewriteCond %{REQUEST_URI} (\.)(7z|ab4|ace|afm|alfa|as(h|m)x?|aspx?|aws|axd|bash|ba?k?|bat|bz2|cfg|cfml?|cgi|cms|conf\b|config|ctl|dat|db|dist|dll|eml|eng(ine)?|env|et2|exe|fec|fla|git(ignore)?)$ [NC,OR]
RewriteCond %{REQUEST_URI} (\.)(hg|idea|inc|index|ini|inv|jar|jspa?|lib|local|log|lqd|make|mbf|mdb|mmw|mny|mod(ule)?|msi|old|one|orig|out|passwd|pdb|php\.(php|suspect(ed)?)|php([^\/])|phtml?|pl|profiles?)$ [NC,OR]
RewriteCond %{REQUEST_URI} (\.)(psd|pst|ptdb|production|pwd|py|qbb|qdf|rar|rdf|remote|save|sdb|sql|sh|soa|svn|swf|swl|swo|swp|stx|tar|tax|tgz?|theme|tls|tmb|tmd|wok|wow|xsd|xtmpl|xz|ya?ml|za|zlib)$ [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_REQUEST_URI:%1___%2___%3]
</IfModule>
# 8G:[USER AGENT]
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_USER_AGENT} ([a-z0-9]{2000,}) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|%0a|%0d|%27|%3c|%3e|%00|0x00|\\\x22) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (ahrefs|archiver|curl|libwww-perl|pycurl|scan) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (oppo\sa33|(c99|php|web)shell|site((.){0,2})copier) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (base64_decode|bin/bash|disconnect|eval|unserializ) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (acapbot|acoonbot|alexibot|asterias|attackbot|awario|backdor|becomebot|binlar|blackwidow|blekkobot|blex|blowfish|bullseye|bunnys|butterfly|careerbot|casper|censysinspect) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (checkpriv|cheesebot|cherrypick|chinaclaw|choppy|claudebot|clshttp|cmsworld|copernic|copyrightcheck|cosmos|crawlergo|crescent|datacha|(\b)demon(\b)|diavol|discobot|dittospyder) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (dotbot|dotnetdotcom|dumbot|econtext|emailcollector|emailsiphon|emailwolf|eolasbot|eventures|extract|eyenetie|feedfinder|flaming|flashget|flicky|foobot|fuck) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (g00g1e|getright|gigabot|go-ahead-got|gozilla|grabnet|grafula|harvest|heritrix|httracks?|icarus6j|imagesiftbot|jetbot|jetcar|jikespider|kmccrew|leechftp|libweb|liebaofast) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (linkscan|linkwalker|lwp-download|majestic|masscan|mauibot|miner|mechanize|mj12bot|morfeus|moveoverbot|mozlila|nbot|netmechanic|netspider|nicerspro|nikto|ninja|nominet|nutch) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (octopus|pagegrabber|petalbot|planetwork|postrank|proximic|purebot|queryn|queryseeker|radian6|radiation|realdownload|remoteview|rogerbot|scan|scooter|seekerspid) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (semalt|siclab|sindice|sistrix|sitebot|siteexplorer|sitesnagger|skygrid|smartdownload|snoopy|sosospider|spankbot|spbot|sqlmap|stackrambler|stripper|sucker|surftbot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (sux0r|suzukacz|suzuran|takeout|teleport|telesoft|true_robots|turingos|turnit|vampire|vikspider|voideye|webleacher|webreaper|webstripper|webvac|webviewer|webwhacker) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (winhttp|wwwoffle|woxbot|xaldon|xxxyy|yamanalab|yioopbot|youda|zeus|zmeu|zune|zyborg) [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_USER_AGENT:%1]
</IfModule>
# 8G:[REMOTE HOST]
<IfModule mod_rewrite.c>
RewriteCond %{REMOTE_HOST} (163data|amazonaws|colocrossing|crimea|g00g1e|justhost|kanagawa|loopia|masterhost|onlinehome|poneytel|sprintdatacenter|reverse.softlayer|safenet|ttnet|woodpecker|wowrack) [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_REMOTE_HOST:%1]
</IfModule>
# 8G:[HTTP REFERRER]
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_REFERER} (order(\s|%20)by(\s|%20)1--) [NC,OR]
RewriteCond %{HTTP_REFERER} (@unlink|assert\(|print_r\(|x00|xbshell) [NC,OR]
RewriteCond %{HTTP_REFERER} (100dollars|best-seo|blue\spill|cocaine|ejaculat|erectile|erections|hoodia|huronriveracres|impotence|levitra|libido|lipitor|mopub\.com|phentermin) [NC,OR]
RewriteCond %{HTTP_REFERER} (pornhelm|pro[sz]ac|sandyauer|semalt\.com|social-buttions|todaperfeita|tramadol|troyhamby|ultram|unicauca|valium|viagra|vicodin|xanax|ypxaieo) [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_HTTP_REFERRER:%1]
</IfModule>
# 8G:[HTTP COOKIE]
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_COOKIE} (<|>|\'|%0A|%0D|%27|%3C|%3E|%00) [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_HTTP_COOKIE:%1]
</IfModule>
# 8G:[REQUEST METHOD]
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^(connect|debug|move|trace|track) [NC]
RewriteRule .* - [F]
# RewriteRule .* /nG_log.php?log [END,NE,E=nG_REQUEST_METHOD:%1]
</IfModule>6 – 8G Addon gegen das aggressive Scannen von Upload-Dateien
Dieses kleine Addon stoppt die zum Teil sehr aggressiven Angriffe auf Uploads-relevante Ziele, die sich hauptsächlich auf Uploadify, Plupload, TimThumb und ähnliches konzentrieren. Doch auch gegen normale WP-Dateien richten sich die Angriffe, wie zum Beispiel wp-config.php und die xmlrpc.php. Das Addon stoppt über 90% dieser Angriffe.
# 8G FIREWALL:[ROGUE PHP FILES]
# https://m0n.co/8g-addon-rogue-php-files
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_URI} /(_0-load|00|00212|007|00x69|01|05623ecdddd|07|08_45_27_loggo|0803|0|0aa1883c|0byte|0day|0m|0wn3d|1|2|10|100|404|911|1050804k|a|b|d|g|k|abc|admin1|adminer|ajaxcommandshell|akismet|alf4|alfa|alfa2|alfa5|alfashell|alfx|alfa4|alfav4|amad|anasslost|anassgmr|ancvxia|ande|andre|andr3a|angel|angelwhitehat|angie|anonghost|anonghostshell|an0n)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(an0nym0us|anoncol7|anongt|anonym0us|anonymous|anzost|ars|as|b374k|beez|black|bloodsecv4|bump|byp|byp4ss|bypas|bypass|c|c22|c99|c100|cgi|changeall|cmd|con|config|configuration|cp|cpanel|cpn|css|cyber|d0mains|d4rk|dam|db|disqus|dom|drm|dz|dz0|egy|egyshell|eval|exp|exploit|exploits|f0x|file|filemanager|fm|fox|foxx|func|fx|fx0|gaza|golge)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(h4ck|h4cked|h4ntu|h4x|h4x0r|hack|hax|index1|indoxploit|info|inj3ct0r|ironshell|isko|islam|j3|jackal|jacker|jaguar|ja|jaja|jajaja|jar|java|javacpl|killer|king|ksa|l3b|ls|m1n1|madspot|madspotshell|m4r0c|marvins|mini|minishell|modules|mysql|network|newshell|newup|nkr|offline|olux|pr1v|press-this|priv|priv8|r1z|r0k|r00t|r57|readme|root)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(s|sa|sa2|sado|sh3ll|shel|shell|sm|smevk|sniper|sok|sql|sql-new|ss|sym|sym403|sym404|symbpass|syml1nk|symlink|symlinkbypass|syrian_shell|system|system_log|t00|think|tmp|up|uploader|uploads|uploadfile|uploadfile1|user|v4team|vuln)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(w|w3br00t|webadmin|webr00t|webroot|whmcrack|whmcracker|whmcs|wp-|ws|ws0|wso|wsoshell|ws0shell|wso25|wsoshell|up|x|xa|xccc|xd|xx|xxx|zdz|zone-h)\.php [NC,OR]
RewriteCond %{REQUEST_URI} /(admin2\.asp|alfa-shell-v4(.*)|blindshell\.c|cgishell\.pl|controller\.ashx|jaguar\.izri|perl\.alfa|xx\.pl) [NC]
RewriteRule .* - [F,L]
</IfModule>7 – WordPress-Dateien gegen Zugriff blocken
Dieser Bereich sperrt den Zugriff von außen auf so extrem wichtige und sensible Dateien wie die wp-config.php, die install.php und den sehr gefährdeten wp-includes Ordner.
# No access to the install.php
<files install.php>
Order allow,deny
Deny from all
</files>
# No access to the wp-config.php
<files wp-config.php>
Order allow,deny
Deny from all
</files>
# No access to the readme.html
<files readme.html>
Order Allow,Deny
Deny from all
Satisfy all
</Files>
# No access to the liesmich.html for DE Edition
<Files liesmich.html>
Order Allow,Deny
Deny from all
Satisfy all
</Files>
# No error log access
<files error_log>
Order allow,deny
Deny from all
</files>
#No access to the .htaccess und .htpasswd
<FilesMatch "(\.htaccess|\.htpasswd)">
Order deny,allow
Deny from all
</FilesMatch>
# Block access to includes folder
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>8 – Hotlink Protection gegen Bildklau
Das Hotlinking verhindert, dass Deine Bilder auf anderen Websites verlinkt werden können und somit die Ressourcen Deines Webhostings negativ beeinflussen. Mit diesem Schutz werden Deine Bilder nur dort angezeigt, wo sie es auch sollen. Auf Deiner Website. Du musst nur das Wort »domain« in Zeile 6 gegen Deine Domain tauschen. Bei mir steht dort andreas-hecht.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://([^.]+\.)?domain\. [NC]
RewriteRule \.(gif|jpe?g?|png)$ - [F,NC,L]
</ifModule>9 – Autoren-Scans blockieren
Hier werden Bots blockiert, die alle WordPress-Websites nach den Usernamen der Autoren scannen, um im Anschluss diese Websites anzugreifen. Dankeschön für den Code an Kommentator Andreas.
#Block WordPress Author Scans
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [OR]
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule ^ – [NC,F,L]
</ifModule>10 – Schutz gegen den »ReallyLongRequest« Banditen
Der »ReallyLongRequest« Bandit ist eine recht neue Bedrohung, die nicht direkt schädlich ist, sondern den Server mit gigantisch vielen Anfragen „erschlagen“ will. Das kann unter Umständen dazu führen, dass Deine Website extrem langsam wird oder nicht mehr erreichbar ist.
»ReallyLongRequest« Bandit heißt der Bot deshalb, weil die gigantisch langen Anfragen alle mit »YesThisIsAReallyLongRequest…« beginnen. Um den Server zu entlasten, blockieren wir diese nutzlosen Anfragen.
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} .* [NC]
RewriteCond %{THE_REQUEST} (YesThisIsAReallyLongRequest|ScanningForResearchPurpose) [NC,OR]
RewriteCond %{QUERY_STRING} (YesThisIsAReallyLongRequest|ScanningForResearchPurpose) [NC]
RewriteRule .* - [F,L]
</IfModule>11 – Schütze Deinen Adminbereich mittels HTTP-Veriegelung
Mit der Kombination aus .htaccess und .htpasswd erzeugst Du einen sehr wirksamen Schutz gegen das Hacking Deines Adminbereichs. Du musst nur den Pfad zu Deiner .htpasswd anpassen.
# If you want to use it, comment it out and set your path to .htpasswd
#<Files wp-login.php>
#AuthName "Admin-Bereich"
#AuthType Basic
#AuthUserFile /usr/local/www/apache24/your-path/your-domain.com/.htpasswd
#require valid-user
#</Files>12 – Die XML-RPC Datei sperren
Die XML-RPC Datei ist zusammen mit dem Adminbereich von WordPress das beliebteste Angriffsziel.
Die Schnittstelle ist ein nützliches Werkzeug für die Verwaltung von Inhalten. Sie dient dazu, dass man mittels der Desktop– und der Smartphone-Apps die Website verwalten und Artikel verfassen kann. Ebenso kümmert sie sich um Pingbacks. Die Pingback-API ermöglicht eine Art »Vernetzung« zwischen den Blogs und dient gleichzeitig als Schnittstelle, um WordPress über externe Programmen verwalten zu können.
Genau diese Funktionen sorgen für teilweise wesentlich heftigere Angriffsorgien als auf den Adminbereich selbst. Denn auch über die Schnittstelle haben Angreifer dann vollen Zugriff auf die Website.
### @see https://digwp.com/2009/06/xmlrpc-php-security/
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>13 – Der Referrer Header für mehr Datenschutz
Wenn Du auf einen Link klickst, sendet Dein Browser den Header HTTP Referrer an den Webserver, auf dem sich die Zielwebseite befindet. Der Header enthält die vollständige URL der Seite, von der Du gekommen bist. So können Websites sehen, wo der Traffic herkommt. Der Header wird auch gesendet, wenn externe Ressourcen (z. B. Bilder, Schriftarten, JS und CSS) geladen werden.
Der Referrer-Header ist ein Albtraum für die Privatsphäre, da Websites und Dienste Dich über das Internet verfolgen und Deine Surfgewohnheiten (und somit möglicherweise private, vertrauliche Informationen) erkennen können, insbesondere in Verbindung mit Cookies.
Angenommen, Du bist bei Facebook angemeldet. Du besuchst eine Seite mit der URL http://www.some-hospital.com/some-medical-condition. Auf dieser Seite klickst Du auf einen Link zu Deinem Facebook-Profil. Dein Browser sendet dann Referrer: http://www.some-hospital.com/some-medical-condition zu www.facebook.com, zusammen mit Deinen Facebook-Cookies, so dass Facebook Deine Identität mit dieser bestimmten Seite verknüpfen kann.
Das Problem wird noch verschlimmert durch die Tatsache, dass viele Webseiten Ressourcen wie Bilder und Skripte von Dutzenden von Drittanbietern laden, indem sie alle Informationen an sie senden, wobei der typische Besucher keine Ahnung hat, dass dies geschieht.
Gut ist, dass dieser datenschutzrechtliche SuperGau unterbunden werden kann durch den einfachen Befehl an den Browser, keinen Referrer zu senden.
## No-Referrer-Header
<IfModule mod_headers.c>
Header set Referrer-Policy "no-referrer"
</IfModule>14 - Die HTTP-Security-Header - Update 06/2024
Jedes Mal, wenn ein Browser eine Seite von einem Webserver anfordert, antwortet der Server mit der Auslieferung der Seite und sendet einen HTTP-Response-Header mit dem Inhalt. Diese Header können nicht nur alltägliche Dinge wie den Zeichensatz enthalten, sondern auch sicherheitsrelevante Einstellungen senden.
Hierfür nutzt man die sogenannten HTTP-Response-Header, mit denen man das Verhalten eines Browsers steuern kann. Ein Strict-Transport-Security-Header würde dem Browser zum Beispiel die Anweisung erteilen, nur über HTTPS zu kommunizieren.
Ein Update hat der Strict-Transport-Security Header erfahren. Er wurde auf den von https://hstspreload.org empfohlenen Wert von 2 Jahren max-age=63072000 gesetzt.
### @see https://scotthelme.co.uk/hardening-your-http-response-headers
## X-FRAME-OPTIONS-Header
<IfModule mod_headers.c>
Header set X-Frame-Options "sameorigin"
</IfModule>
## Strict Origin when cross origin Header
#@see https://scotthelme.co.uk/a-new-security-header-referrer-policy/
<IfModule mod_headers.c>
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
## X-XSS-PROTECTION-Header
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>
## X-Content-Type-Options-Header
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>
## Strict-Transport-Security-Header - für HTTPS / Update 06/2024
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age= 63072000; includeSubDomains; preload"
</IfModule>
# Upgrade Insecure Requests to prevent mixed content
<ifModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>
# Permissions Policy is a new header that allows a site to control which features and APIs can be used in the browser.
<IfModule mod_headers.c>
Header always set Permissions-Policy "geolocation=(), midi=(),sync-xhr=(),accelerometer=(), gyroscope=(), magnetometer=(), camera=(), fullscreen=(self)"
</IfModule>Der Security Header "upgrade-insecure-requests"
Der "upgrade-insecure-requests"-Header ist für die Sicherheit des Inhalts einer Website gedacht, um Browsern mitzuteilen, dass sie ausschliesslich HTTPS- statt HTTP-Anfragen stellen sollen. Er behebt zum Beispiel auch Probleme mit gemischten Inhalten bei der Umstellung auf HTTPS. (Gemischte Inhalte: Website wird über HTTPS abgerufen, Bilder und Grafiken jedoch noch über HTTP).
Er kann als HTTP-Header oder als Meta-Tag auf Seitenebene verwendet werden.
Beispiel 1: Der HTTP-Header in der .htaccess
#HTTP Header
<ifModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests;"
</IfModule>
Beispiel 2: Der Meta-Tag
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">Der neue Permissions-Policy Header
Der Permissions-Policy Header (früher Feature-Policy genannt) steuert die Browser-Funktionen, die für den Datenschutz und die Sicherheit der Besucher infrage kommen. Das meint zum Beispiel das Einschalten von Mikrofon und Webcam, den Standort des Besuchers abzufragen ebenso wie die Aktivierung der Zahlungs-API für Funktionen wie zum Beispiel ApplePay.
Die hier angegebenen Regeln gelten nicht nur für die eigene Website, sondern schließen auch externe Iframes ein, damit auch diese die sicherheitsrelevanten Funktionen nicht nutzen können. Das sorgt für ein deutliches Plus an Sicherheit für die eigene Website. Der neue Header verhindert somit Angriffe, die es auf die Daten Deiner Besucher abgesehen haben.
Mit den Einstellungen in der .htaccess sind alle Funktionen abgeschaltet.
# Permissions Policy is a new header that allows a site to control which features and APIs can be used in the browser.
<IfModule mod_headers.c>
Header always set Permissions-Policy "geolocation=(), midi=(),sync-xhr=(),accelerometer=(), gyroscope=(), magnetometer=(), camera=(), fullscreen=(self)"
</IfModule>Ein Tutorial dazu kannst Du auf GitHub finden (EN)
15 - Die WordPress Standard Regeln
Dies sind die Standard-Regeln, die jede WordPress-Website während der Installation anlegt. Wenn Du eine Multisite nutzt, oder sich dein WordPress in einem Unterordner befindet, müssen diese Regeln angepasst werden.
Update der Standardregeln auf WordPress ab Version 6
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
333 Kommentare. Hinterlasse eine Antwort
Hi Andreas,
deine htaccess verwende ich schon sehr lange, ohne große Probleme. Danke daher erst mal für die Mühe.
Seit Kurzem habe ich beim Page Builder Elementor das Problem, dass er bei manchen Seiten nicht mehr lädt. Ich konnte das auf diese htaccess-Regel zurückführen. Wenn sie auskommentiert ist, läuft alles. Das tritt aber erst seit ein paar Tagen bei mir auf. Hast du evtl. eine Erklärung dafür?
# Block WordPress Author Scans
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [OR]
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule ^ – [NC,F,L]
Hi Alex! Erklären kann ich mir auf die Schnelle nicht. Hilf Dir einfach, indem Du diesen Bereich auskommentierst mit einer Raute davor.
Alles gut, das auskommentieren habe ich natürlich schon gemacht.
Noch ein Nachtrag. Es kam scheinbar durch eines der letzten Elementor Updates, denn alle meine Seiten, welche die aktuellste Version drauf haben, sind jetzt betroffen. Bin kein Experte für die Rewrite Regeln, aber scheinbar wird ein Teil der Rest Api die Elementor jetzt neu braucht, blockiert. Auskommentieren hilft natürlich weiterhin.
Hi, die neue 8G FIREWALL v1.4 20250120 ist da. Kann diese bitte wieder eingebunden werden?
Hi Frank!
Danke für Deinen Kommentar. Ist erledigt!
Ist geschehen! Danke für die Info.
Hallo Andreas, ist es möglich eine oder zwei IP Adressen zu einer Whitelist hinzuzufügen, damit bei diesen die Regeln der htaccess nicht angewendet werden?
Hallo Andreas,
seit einiger Zeit zeigt mir WordPress folgende „empfohlene Verbesserung“ an:
Seiten-Cache kann wegen eines möglichen Loopback-Anfrageproblems nicht erkannt werden. Bitte überprüfe, ob der Loopback-Anforderungstest erfolgreich ist. Fehler: Forbidden (Code: http_403)
Der Seiten-Cache verbessert die Geschwindigkeit und Leistung deiner Website, indem er statische Seiten speichert und bereitstellt, anstatt bei jedem Besuch eines Benutzers eine Seite aufzurufen.
Seiten-Cache wird erkannt, indem nach einem aktiven Seiten-Cache-Plugin gesucht wird, drei Anfragen an die Homepage gestellt werden und nach einem oder mehreren der folgenden HTTP-Client-Cache-Antwort-Header gesucht wird:
cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.
Ein cache-Plugin habe ich nicht installiert, weil ich deine .htaccess benutze.
Soll ich irgendwas unternehmen oder kann ich die Meldung ignorieren?
Gruß Heiko
Hallo Heiko,
das kannst Du getrost ignorieren. Allerdings könnte ein zusätzliches Cache-Plugin Deine Website noch weiter beschleunigen.
Einfach klasse, bisher habe ich mir diverse Snippets selbst zusammengesucht. Hier ist alles drin. Allerdings verstehe ich von der Firewall nichts. Da vertraue ich einfach mal.
Vielen Dank.
Spende kommt.
Hallo Andreas, heute habe ich durch Zufall festgestellt, dass meine bzw. die von dir geschriebene .htaccess um eine Uhrzeit an dem ich selbst nicht am Server bzw. an der Datei gearbeitet habe Veränderungen geschrieben worden. Dazu habe ich inzwischen gelesen, dass WordPress beispielsweise bei Permalinks Anpassungen in die .htaccess schreibt. Sollte ich das so belassen? Oder empfiehlst du beispielsweise den Zugriff über die Zugriffsrechte 444 zu sperren?
Danke im Voraus für deine Mühen!
Beste Grüße Rüdiger
Gegen WordPress user enumeration- ja wordpress leaked by default die usernames. Einfach mal selbst ausprobieren, https://www.example.com/wp-json/wp/v2/users (https://www.example.com/wp-json/wp/v2/users)
# Block WordPress Author Scans
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [OR]
RewriteCond %{QUERY_STRING} (author=\d+) [NC]
RewriteRule ^ – [NC,F,L]
Hi Andreas,
danke für Deine Ergänzung. Ich werde Sie einmal ausgiebig testen und eventuell implementieren.
# Block WordPress Author Scans
Hallo Andreas,
Hinweis:
bei Verwendung des Autorenscan funktioniert das exportieren der WordPress Daten in eine XML Datei nicht mehr. Zum verwenden für diese Funktion müsste man es zumindest kurzfristig auskommentieren!
Grüße
Cornelia
Habe leider gerade herausgefunden, dass es noch deutlich mehr Wege gibt, an die !usernames! zu kommen: https://www.gosecure.net/blog/2021/03/16/6-ways-to-enumerate-wordpress-users/ (https://www.gosecure.net/blog/2021/03/16/6-ways-to-enumerate-wordpress-users/)
Habe leider noch kein .htaccess Beispiel gefunden, dass alle diese Fälle abdeckt.
Hallo Andreas,
vielen Dank für die Bereitstellung und Pflege deiner .htacess Datei! Beim lesen der vielen Kommentare ist mir aufgefallen, dass sehr viele Berufskollegen/innen deine .htacess Datei nutzen und loben. Ich komme nicht aus der Branche und versuche mich so gut wie möglich in die Materie einzuarbeiten.
In den letzten Tagen stosse ich beim überprüfen meiner Site-Sicherheit wiederholt auf nachstehende Meldung. Mir ist noch nicht klar wie ernst ich die Meldungen nehmen muss und ob wirklich dringender Handlungsbedarf besteht!?
Meldungen:
PageSpeed Insights:
Sicherstellen, dass CSP effektiv gegen XSS-Angriffe wirkt
Die Direktive „script-src“ fehlt. Dies kann die Ausführung unsicherer Skripts ermöglichen.
script-src
Hoch
Wenn „object-src“ fehlt, können Plug-ins eingeschleust werden, die unsichere Skripts ausführen. Sie sollten daher „object-src“ auf „none“ setzen.
object-src
Hoch
Mozilla Observatory:
Content Security Policy
-20
Content Security Policy (CSP) implemented unsafely.
This includes ‚unsafe-inline‘ or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src.
siwecos.de:
Content Security Policy unsicher:
Die Anweisung default-src fehlt.
Referrer Policy unsicher:
Die Anweisung ’strict-origin-when-cross-origin‘ ist gesetzt. Wir empfehlen die Option ’no-referrer‘.
Nimmt deine .htacess die aufgezeigten Empfehlungen schon auf?
Bzw. ist es wichtig für mich sich darum zu kümmern? Würde ich bei Bedarf Hilfe von dir, deiner Agentur bekommen? Zum Thema CSP habe ich bereits in den Kommentaren gelesen, das es eine individuelle Anpassung sein müsste.
Besten Dank! Und beste Grüße
Rüdiger
Hallo Rüdiger,
all diese Empfehlungen sind in der .htaccess inklusive.
Hallo Andreas,
ich danke dir für deine schnelle Rückmeldung und deine Mühen!!!
Beste Grüße
Rüdiger
Ich erhalte auch in google pagespeed:
„““
Ensure CSP is effective against XSS attacks
A strong Content Security Policy (CSP) significantly reduces the risk of cross-site scripting (XSS) attacks. Learn how to use a CSP to prevent XSS
Description: script-src directive is missing. This can allow the execution of unsafe scripts.
Directive: script-src
Severity: High
Description: Missing object-src allows the injection of plugins that execute unsafe scripts. Consider setting object-src to ’none‘ if you can.
Directive: object-src
Severity: High
„““
Hilfst du mir kurz auf die Sprünge? Ich konnte weder einen „script-src“ noch „object-src“ explizit gesetzten Header entdecken. Wird das implizit durch eine andere Option aktiviert? Warum bringt Google Pagespeed dann aber diese Meldung?
Vielen Dank!!
Bei dem ganzen caching und expires könnte man das Grafikformat avif ergänzen.
Wenn ich die Seite
https://securityheaders.com/ (https://securityheaders.com/)
im Google Chrome aufrufe und die Entwicklertools öffne, dann wird mir eine Fehlermeldung bezüglich des Expect-CT-Headers angezeigt.
Ist dieser nicht veraltet und sollte daher entfernt werden?
Hi Lena,
ich würde ihn nicht als veraltet ansehen. Ich nutze ihn auch bei dieser Seite. Es besteht keinerlei Veranlassung, den Expect-CT-Header zu entfernen.
Die Entwicklertools geben folgendes aus:
Der „Expect-CT“-Header wurde verworfen und wird entfernt. Chrome verlangt, dass alle nach dem 30. April 2018 ausgestellten öffentlich vertrauenswürdigen Zertifikate die Anforderungen der Certificate Transparency erfüllen.
Das kann man dann also ignorieren, oder wie?
Ja, kann man. Sagte ich ja bereits so ähnlich…
Danke für Ihre Antwort!
Beste Grüße, Lena
Im aktuellen WordPress 6.0.2 ist folgender Abschnitt in der htaccess:
# BEGIN WordPress
# Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind
# dynamisch generiert und sollten nur über WordPress-Filter geändert werden.
# Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Kannst Du diesen bitte in deine htaccess übernehmen?
Hi Frank,
danke für die Anregung. Ist erledigt!
Super, Danke für diesen Code für htacess!
Zwei kleine Fragen: beim ersten „Header append Vary: Accept-Encoding“ fehlt der Doppelpunkt – bewusst? Und: Nach der Implementierung fehlt bei mir im Frontend die Admin-Bar – selbst wenn ich sämtliche Plugins deaktiviere. Sobald ich die htaccess vom neuen Code befreie, ist sie wieder da?
Hi Gustavo,
nein, da fehlt kein Doppelpunkt. Das muss an der Stelle so sein. Und bei mir ist die Admin-Bar im Frontend noch vorhanden – und bei den vielen anderen Usern auch.
Hallo Andreas,
die Aufbereitung des 7G Artikels finde ich wiklich super, tolle Arbeit. Eine Frage zum Schutz mit der htpasswd bleibt bei mir, trotz umfangreicher Rechereche unbeantwortet.
Wenn ein User sein Passwort ändert, muss dann jedesmal die htpasswd manuell geändert werden? Falls nein, vergiss den Rest, falls ja, bitte weiterlesen.
Also ja! – das ist dann sehr unkomfortabel – und – Gibt es eine vernünftige Lösung das automatisiert zu machen? Ich meine ja, den MD5 Hash kann man ja beliebig portieren.
Hast Du dann dafür eine KUNDENTAUGLICHE Standardlösung? Oder ein Server Script? Oder muss ich dafür dann erst ein Plugin bauen 😉 ?
Sollte eigentlich Alles kein Problem sein, oder?
Hi, ja, da solltest Du ein Plugin für bauen. Ich habe nämlich keine Zeit dafür:-)
Also ich habe die 7G Firewall mal installiert und hatte dann genau selbiges Problem, daß KEINE Seite mehr aufrufbar war. Habe mir dann etwas Arbeit gemacht und Zeile für Zeile alles durchforstet.
Trotz Studium des Apache Module mod_rewrite bin ich nicht richtig schlau geworden. Jedenfalls, wenn ich diese Zeile auskommentiere, dann läufts. Mich würde aber brennend interessieren warum???
# 7G:[REQUEST URI]
RewriteCond %{REQUEST_URI} (\^|`||\\|\|) [NC,OR]
RewriteCond %{REQUEST_URI} ([a-z0-9]{2000,}) [NC,OR]
RewriteCond %{REQUEST_URI} (=?\\(\’|%27)/?)(\.) [NC,OR]
# — disabled !!!!! ——-RewriteCond %{REQUEST_URI} (/)(\*|\“|\’|\.|,|&|&?)/?$ [NC,OR]
RewriteCond %{REQUEST_URI} (\.)(php)(\()?([0-9]+)(\))?(/)?$ [NC,OR]
RewriteCond %{REQUEST_URI} (/)(vbulletin|boards|vbforum)(/)? [NC,OR]
RewriteCond %{REQUEST_URI} /((.*)header:|(.*)set-cookie:(.*)=) [NC,OR]
RewriteCond %{REQUEST_URI} (/)(ckfinder|fck|fckeditor|fullclick) [NC,OR]
Hallo, die 7G-Firewall in der Version 1.3 hat mir bisher gute Dienste geleistet und funktionierte auf allen Webseiten. Leider ist das bei der Version 1.5 anders. Ich bekomme keinen Zugriff auf alle meine Seiten. Was ist anders und ist dir das Problem bekannt?
Hi Andreas,
ich würde mal an Deiner Stelle testen, welcher Part der
.htaccessfür das Problem verantwortlich ist. Lösche einfach mal einen Block nach dem anderen und teste es aus. Ansonsten gibt es hier den Changelog der 7G-Firewall: https://perishablepress.com/downloads/7G-Changelog.txt (https://perishablepress.com/downloads/7G-Changelog.txt)Lieber Andreas, ein Sicherheitsrisiko kann ich mit deiner hoch wert geschätzten htaccess noch nicht abwenden und muss ein zusätzliches Plugin nutzen: der Zugriff auf die Daten über wp-json/wp/v2/users. Gibt es eine Möglichkeit, das über die htaccess abzusichern? Oder übersehe ich etwas? Das wäre MEGA.
Vielen lieben Dank vorab.
Hi Penelope,
ich werde zu dem Thema noch einen Artikel posten, mit dem man dann diesen Zugriff unterbinden kann. Danke für Deine nützliche Ergänzung.
Hallo und herzlichen Dank für den umfangreichen und informativen Artikel.
Leider bekomme ich beim Download eine zip-Datei, die nach dem entzippen einen leeren Ordner auf meinem Mac bringt.
Ja, logisch oder?
Die
.htaccessist ja auch eine versteckte / Systemdatei. Vielleicht mal die Anzeige von versteckten Dateien aktivieren?Soviel sollte jemand, der mit solchen Dateien arbeiten möchte, eigentlich wissen.
Danke für die freundliche Antwort 😉
Nicht dran gedacht …
Hallo Andreas,
vielen Dank für die dauerhafte Bereitstellung Deiner htaccess-Version und inklusive der ständigen Updates! Ich orientiere mich sehr gerne, und das schon seit Jahren, an Deinen hier gelisteten Empfehlungen. Eine Frage dazu: Mein Kunde wünscht (nach Durchführung eines Pentest seiner von mir betreuten WP-Installation), den X-XSS-PROTECTION-Header auf ‚0‘ zu setzen, da dieser veraltet wäre für Angreifer als Schachstelle dienen könne. Anstelle dessen wünscht er die Verwendung der CSP, welche aber (zumindest mir so bekannt) sich bei ständig ändernden Umständen einer WP-Installation kaum zu konfigurieren wäre. Ist Dir der XSS-Header als Schwachstelle bekannt? Und würdest Du empfehlen, diesen weiterhin auf ‚1‘ stehen zu lassen?
Vielen Dank für eine Rückmeldung im voraus und beste Grüße nach Hamburg!
Hi Eik,
der XSS-Header ist definitiv keine Schwachstelle. Das würde ansonsten eine kleine Suche mit Google ja sofort ans Tageslicht bringen. Also, Schwachsinn. CSP ist zwar toll, aber bei 95% aller Websites nicht umsetzbar, weil sich Dinge wie gesagt ja schnell mal ändern können. Wenn der Kunde dann jedesmal Deine Arbeitsstunden bezahlen möchte, weil die Website wieder mal zerschossen aussieht… Mach dem Kunden eines klar: Er bezahlt Dich dafür, dass Du in Website-Angelegenheiten der Chef bist.
Hi Andreas,
na, das ist dann mal eindeutig formuliert!
Herzlichen Dank für Dein feedback und lieben Gruß – von Chef an Chef 😉
Eik
Hi,
What an excellent htaccess, i would like to provide an english version.
Would you give permission to create an english version of this page, so that also non german
people can acquire this awesome knowledge?
Please le me know, kind regards
Charles
Hallo Andreas,
ich wollte an dieser Stelle einfach mal Danke sagen für diese wunderbare Anleitung und Unterstützung. Ich setze diesen Aufbau, bzw. htaccess Datei inzwischen auf 3 meiner Webseiten ein und bin mehr als zufrieden. Abgelöst habe ich damit dads Plugin WordFence Security.
Viele Grüße,
Stefan
Hi Stefan,
gern geschehen. Freut mich zu hören:-)
Meiner Meinung nach wäre es sinnvoll, dass folgende zu ergänzen:
Header set Content-Security-Policy „upgrade-insecure-requests“
Hi Lena,
danke für die nützliche Ergänzung! Ich habe die
.htaccessmit dem Header aktualisiert.Vielen Dank dass Sie meine Verbesserungsvorschlag angenommen haben!
Hallo,
ich habe die .htaccess ausprobiert, kam ein Fatal Error, alte .htaccess wieder aktiviert.
Jetzt kennen alle meine Homepages keine Umlaute mehr und der Admin Bereich in allen WP Seiten ist zerschossen, ohne Layout.
Andere Homepages welche mit einem anderen CMS erstellt worden sind funktionieren normal.
Was kann ich tun?
Hi Claus,
an der
.htaccessDatei liegt es definitiv nicht, die wurde mittlerweile auf Tausenden von Websites getestet. Außerdem ändert die keine Umlaute und kein Design.Hallo Andreas, ich bin sehr dankbar für deine .htaccess und setze sie seit Jahren auf all meinen Webseiten ein. Seit dem letzten Update sehe ich jedoch in der Ansicht im Visual Studio Code Editor bei den farblich unterschiedlichen Code Abschnitten eine Unterbrechung in der Farbgebung ab Zeile 248. Das deutet normal auf einen Fehler im Code hin. Oder hast du eine eigene Erklärung dafür?
Da ich nun gelesen habe, dass du empfiehlst gar keine Sicherheitsplugin zu nutzen (stimmt das??) möchte ich nur sicherstellen, dass es korrekt ist.
Herzlichen Dank schon mal
Hallo,
keine Angst, der Code ist absolut korrekt. Manchmal zeigen Entwicklungsumgebungen gerade bei sehr umfassenden Codebereichen nicht richtig an. Und ja, ich halte nichts von »Sicherheits-Plugins«, weil sie nicht für echte Sicherheit sorgen. Eine anständige Absicherung des Adminzugangs in Kombination mit einem sicheren Passwort schafft sehr viel mehr Sicherheit.
Hallo Andreas,
habe WordPress neu aufgesetzt und natürlich deine .htaccess verwendet (DANKE ).
Mein Problem ist das mein Theme jetzt das Menu auf der der Linken Seite (zusammengestaucht) statt auf der rechten Seite angezeigt wird. Das Logo und den dazugehörigen Logo Link wird extra und untereinander angezeigt. Ich habe neben dem Logo meinen Seitennamen der besteht aus 2 Wörtern diese werden nicht nebeneinander sondern untereinander angezeigt.
Welcher Bereich der htaccess könnte dafür verantwortlich sein?
Für eine Rückmeldung danke ich schon im Voraus, DANKE.
Mit besten Grüssen
Ernest
Hi Ernest,
meine .htaccess greift nicht in das Design ein. Wie kommst Du auf sowas??? Das ist ein CSS Problem.
Sorry Andreas,
hatte falsche Gedanken in meinen Gehirngängen. Es war schlicht und ergreifend ein Routerproblem. War was im Router hängengeblieben und deshalb wurde auf meiner Seite nicht alles Korrekt angezeigt. Habe meine Seite über mein Handyprovider aufgerufen (ohne WLAN) wurde meine Seite richtig angezeigt.
Mit besten Grüßen
Ernest
Ps.: Das größte Problem sitzt immer vor dem Bildschirm.
Servus. Wie würde sowas denn für eine Subdomain Multisite aussehen?
Ich hab enorme Schwierigkeiten das zum laufen zu bekommen.
Gruß.
Hallo Andreas, zuerst einmal vielen Dank für deine tolle Arbeit.
Ich nutze deine htaccess schon längere Zeit ohne jegliche Probleme.
Heute habe ich die neue eingebaut und bekomme einen Internel Server Error.
Log. Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‚LimitInternalRecursion‘ to increase the limit if necessary. Use ‚LogLevel debug‘ to get a backtrace.
Ich nutze Notepad++ und habe es auch auf 3 verschiedenen Domains getestet. Überall das gleiche.
Die Version von Anfang des Jahres läuft perfekt. Kannst du mir da einen Tip geben.
Im Voraus, vielen Dank
Wenn es nicht läuft, dann nimm die Version vom Anfang des Jahres. Oder mach einen Downgrade auf die 6G-Firewall (ist im Artikel verlinkt).
Alles klar werde ich testen. Vielen Dank.
Hallo Herr Hecht,
also ich habe nun soweiit die .htaccess umgesetzt.
Allerdings macht mir folgender Abschnitt Probleme
# Block access to includes folder
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L]
RewriteRule !^wp-includes/ – [S=3] <— Verurscht Fehler und zerschießt das Themplate
RewriteRule ^wp-includes/[^/]+\.php$ – [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
RewriteRule ^wp-includes/theme-compat/ – [F,L]
Was könnte man den noch versuchen???
Gruss Andre
Der Block des Includes-Ordners kann eigentlich kein Theme verschießen. Da muss dann ein Copy/Paste Fehler drin sein. Bitte nicht aus den Code-Blöcken kopieren, sondern nur aus dem Gist unten.
Hallo Herr Hecht,
Danke für die rasche Antwort. Ich hätte da noch ne kleine Frage:
Ich habe für den Adminbereich von WP erst einmal den Verzeichnisschutz über das ACP meines Servers realisiert. Kann ich hier den Abschnitt Verzeichnisschutz für den WP-Admin dann überspringen???
Was ist eigentlich eine 7 G Firewall???
Die kenne ich noch nicht???
Ist das ein Plugin für WP, das dann über die .htaccess gefüttert wird????
Ups, da waren es schon zwei Fragen *schmunzel*
Grüsse aus Berlin…
Andre
Hi,
ja, der Adminschutz kann dann entfallen. Die 7-G Firewall ist ein Schutz vor Hacking und bösartigen Angriffen auf Deine Website. Und nein, es ist kein Plugin. Du solltest eh keine »Sicherheitsplugins« verwenden, da diese eh keinen echten Schutz bieten.
Hallo Herr Hecht,
ich finde ihre Anleitung sehr interessant und wollte wissen ob ich die so auch für die WP Milestone 5.8.1 ohne Komplikationen übernehmen kann.
Moin,
ja, die Datei kann ohne Probleme verwendet werden.
Habe meine Datei nun auch aufgewertet aber der Schadsoftware-Code verursacht bei meiner Seite dass sie nicht mehr erreichbar ist mit nem „forbidden“-Error
Nicht der Code verursacht den Fehler. Den hast Du beim Kopieren verursacht. Bei mittlerweile wohl Tausend Websites läuft die .htaccess ja fehlerfrei.
Vergessen eben zu fragen: mit dieser .htaccess scheint mir ein ziemlicher Teil der Funktionalität von BBQ Pro und NinjaFirewall bereits abgedeckt. Sehe ich das richtig?
Hochinteressant, vielen Dank für die Arbeit!
Werde demnächst mal testen, wie diese .htaccess
— sich bewährt wenn NGiNX als Proxy vorgeschaltet ist, Apache also erst für PHP-Aufrufe zum Einsatz kommt
— zusammen mit WP Rocket arbeitet
— auf Plesk-Installationen läuft, wo einiges daraus schon auf Server-Ebene ohne Eintrag ins .htaccess bereits vorbereitet ist (im WordPress Toolkit).
Gibt’s etwas ähnliches auch für reine NGiNX-Server?
Hallo Andreas,
danke für Deinen wunderbaren, sehr wichtigen Beitrag. Erst gestern in unserer Veranstaltung zum Thema: „(Fast) Alles zum Thema WP-Sicherheit“ mit Berhard Kau (Berlin) des WordPress Meetup Dresden wurde wieder auf Deine .htaccess verwiesen.
Frage:
In Zeile 451 in Deiner kompletten WordPress .htaccess als Gist empfielst Du einen Test mit dem Prüfwerkzeug »Security Headers« auf https://securityheaders.com (https://securityheaders.com) an.
Wenn ich meine Seite https://bildermann.de/ (https://bildermann.de/) mit diesem Prüfwerkzeug checke lasse, kommt der Hinweis für »Missing Headers«, dass die »Content Security Policy« und die »Permissions Policy« fehlen.
Wie groß ist hier bitte das Sicherheitsrisiko?
Gibt es bitte hierfür noch einen Code, welchen ich zur Abhilfe in die .htaccess einfügen könnte? Oder wie sähen Maßnahmen zu deren Abhilfe bitte aus?
Danke,
Karl
Vielen Dank für die tolle Arbeit mit der htaccess-Datei. Ich habe diese im Einsatz, jetzt jedoch festgestellt, dass sie mir den Zugriff von Matomo auf dessen Website-Einstellungen verhindert. Könnten Sie mir evtl. mitteilen, welche Stelle in dieser Datei dafür verwantwortlich sein könnte? Wenn ich die ganze Datei deaktiviere, funktioniert der Zugriff.
Hallo Andreas,
ich verwende deine htaccess auf mehreren Seiten und habe noch nie Probleme gehabt. Besten Dank für die tolle Arbeit!
Auf einer Hauptseite verwende ich eine Portfolio Page die eine Livevorschau bietet. Seit deiner neuen Version weder aber diese Seiten nicht abgerufen. Es kommt die Meldung, … hat die Verbindung abgelehnt. Wo muss ich diese Seiten eintragen, dass eine Verbindung zustande kommt?
Vielen Dank vorab!
Swen
Wie wäre es mit folgender Ergänzung
Disable HTTP Trace Method
There is a security attack technique called Cross Site Tracing (XST) which can be used together with another attack mechanism called Cross Site Scripting (XSS) which exploits systems which have HTTP TRACE functionality. HTTP TRACE is a default functional feature on most webservers and is used for things like debugging. Hackers who use XST will usually steal cookie and other sensitive server information via header requests.
You can disable the trace functionality either via your Apache configuration file or by putting the following in your .htaccess file:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* – [F]
Hallo Andreas,
vielen Dank für diese wirklich extrem umfangreiche Vorlage. Beim Referrer Header bin ich mir immer unschlüssig. Als Datenschutzbeauftragter empfehle ich das ja auch gerne. Als Affiliate Betreiber möchte ich den Referrer aber gerne übermitteln. Wie so oft eine Zwickmühle. Da nehme ich dann auch mal die Variante: Header set Referrer-Policy „strict-origin“
Hallo Andreas!
Zuerst danke für deine sehr wertvolle Arbeit und für das zur Verfügung stellen. DANKE!
Meine Frage: UserKommentare mittels 2-auth Login absichern, kann ich dann die htaccess auch noch verwenden bzw. auf was muss man achten oder Rücksicht nehmen?
Ein ganz dickes Dankeschön für diese hervorragende Arbeit!
Guten Tag – eine ganz blöde Frage. Ich habe Deine fantastische (ernst gemeint) htacess bei mir eingespielt, und die entsprechenden Anpassungen vorgenommen. Einzig bei den Security Headers scheint es ein Problem zu geben. Sie sind aktiv (nicht auskommentiert), aber dennoch bemängelt securityheaders.com ihr Fehlen. Was übersehe ich?
Mit Gruß und großem Dank für die Arbeit
Daniel
Ich hatte eine Seite über Hetzner, DreamHost und andere + Cloudflare.
In allen Fällen funktioniert diese Datei nicht gut
Hetzner – Fehler 522 Zeitüberschreitung der Verbindung
Zeitüberschreitung der DreamHost – Ray 522-Verbindung
Andere – Fehler 522 Zeitüberschreitung der Verbindung
Meine Seite ist seit einem Jahr nicht mehr verfügbar.
[Do 4 März 13:11: 21.945368 2021] [access_compat: error] [pid 18983: tid
139956685047552] [Client-IP: 22638] AH01797: Client wurde von abgelehnt
Serverkonfiguration: /home//wp-admin/install.php
Die obige „versteckte“ Adresse hat versucht, den folgenden Pfad aufzurufen, und das Hosting hat die Site abgeschnitten und nie funktioniert.
341 # Zugriff auf install.php nicht möglich
342
343 Befehl Zulassen oder Verweigern
344 Verweigere alle
345
346
Vor 20 Jahren funktionierten Hosting-Pläne besser 🙁
Danke für diese Datei. Hiermit werden die Sites die wir betreuen (alles gemeinnützige Vereinssites) viel viel schneller aufgerufen.
Ich habe nur einen Effekt, den ich mir nicht erklären kann:
Manch Plugins können mit der htacces nicht aktualisieren.
Eine Idee woran das liegen könnte?
Wenn ich die „Standard htaccess verwende, funktioniert das sauber.
Ich wechsle zur Zeit fürs Updaten immer zwischen den beiden Dateien hin und her…
Fantastische Datei, vielen Dank für die Mühe!
Endlich hat das mühsame Zusammenstricken von htaccess-Dateien hoffentlich ein Ende 🙂
Ich habe von Servern leider keine Ahnung, aber sollte der Code zur xmlrpc.php nicht für Apache 2.4 aktualisiert/ergänzt werden?
# xmlrpc.php sperren
# Apache 2.4
Require all denied
Feb 2021 Hey, dass ist doch mal eine super Seite! Wichtiges Thema und ganz tolle copy Paste Buttons. Kleiner Tipp: Die 7G Firewall funktionierte bei mir als ich den Teil request URI mit dem Original Text der aktuellen 7G Firewall ausgetauscht habe!
Hallo, kurze Frage wenn ich zum Eintrag Header set Referrer-Policy „no-referrer“ jetzt noch diesen setze
Header set Referrer-Policy „strict-origin-when-cross-origin“ bekomme ich eine Anmerkung im Webbkoll das ich das strict-origin-when-cross-orgin nicht zwingend verwenden sollte. Was macht das genau und ist es notwendig?
LG Andreas
Hallo Andreas,
es gibt eine neue Version der 7G Firewall (v1.3). Darauf aufmerksam wurde ich, da es mit der Version v1.2 nach einem Update des Yoast-Plugins auf die Version 15.2.xx das Problem gab, dass eine Bearbeitung der Yoast Meta Box nicht mehr möglich war. Nach dem Update auf 7G v1.3, ist es wieder möglich.
Danke für deine Tipps zur Absicherung von WordPress und ein erfolgreiches neues Jahr.
Viele Grüße Guido
Hi Guido,
danke für die Info!
Sehr tolle Zusammenstellung und super, dass du das aktualisierst!
Da war für mich einiges Neues dabei – und meine Güte, was hat mich das Zusammensuchen vor einigen Jahren noch für Arbeit gekostet.
Hallo Andreas,
auch von mir erst einmal ein großes Dankeschön für die wertvollen Hinweise. Bei mir funktioniert es als Ergänzung sehr gut. Anstelle der Firewall Regeln setze ich das Plugin von Jeff Starr ein. Sollte einiges an Wartung ersparen. Was allerdings nicht funktioniert sind die Settings für die Security Header. Dies haben bei mir erst funktioniert, als ich sie in die WP-Config eingetragen habe. Hast Du hier eine Erklärung?
Liebe Grüsse Johannes
Hallo Andreas,
ist es noch notwendig aus Sicherheitsgründen, dass man die Ordner wp-content, plugins, … etc. umbenennt, wenn man deine .htaccess verwendet?
Freue mich über deine Antwort.
Liebe Grüße
Isabella
Hi Isabella,
solchen Unfug sollte man keinesfalls tun! Wer verbreitet so idiotische Ratschläge?
Danke für deine rasche Antwort!
Auf ein paar Seiten, wo es um die Absicherung geht, weil Bots oder so nach wp-content etc. suchen, aber bin ich froh, dass das nicht notwendig ist, weil es doch oft Troubles mit Plugins macht.
Hey Andreas,
auch ich bedanke mich recht herzlich für all deine guten Tipps, Tricks und Erfahrungen die du mit uns teilst!
Darüber hinaus wollte ich gerne erfragen, ob durch die .htacces auch ein Plugin wie WP Rocket überflüssig ist?
Würde mich natürlich sehr freuen und verbleibe,
Mit besten Grüßen
Manuel
Sorry für die späte Antwort. Seit Corona habe ich mehr Arbeit als ich bewältigen kann. Nein, ein solches Plugin kann Deine Website trotzdem noch weiter beschleunigen.
Kein Problem, dass verstehe ich! Würde gerne noch erfragen, wie man dies am besten einstellt ohne deine htaccess zu behindern !?
Beste Grüße
Das kannst Du in der Dokumentation von WP Rocket erfahren. Ansonsten einfach googlen.
Vielen Dank nochmals…! 😉 würde nur gerne erfragen wie man wp rocket weiterhin nutzen kann, dies aber keine zeilen in die htaccess schreibt, damit diese wie vorgesehen arbeiten kann…konnte diesbezüglich leider nichts finden bzw. ergooglen -.-
Hallo Andreas,
unsere WP-Installation (Blog) ist in einem Unterverzeichnis von unserer Webseite.
Meine „original WordPress Rewrite Rules“ sehen daher auch etwas anders aus (z.B. RewriteBase /verzeichnis-vom-blog/ ).
Kann ich trotzdem deinen kompletten Code nutzen, oder muss ich jedes RewriteBase/ usw. anpassen ?
Mit freundlichen Grüßen ,
Patrick
Hallo Andreas,
vielen Dank für das abermalige Update.
Beim Vergleich mit meiner alten .htaccess ist mir der Eintrag
#Full Path Disclosure abschalten – unterdrueckt die Anzeige des vollstaendigen Fehlerpfads
php_flag display_errors Off
aufgefallen, der nun fehlt. Ist das nicht mehr relevant?
Ich weiß es nicht mehr, wie(so) es da steht, aber ich hab noch
Order deny,allow
deny from all
Seh ich es richtig, dass es ganz nett, aber sinnlos ist, da die wlwmanifest.xml komplett harmlos ist?
Guten Tag,
bin Anfänger und mir ist folg. nicht klar:
In Apache 2.3 wurde im Modul mod_authz_core eine Änderung gemacht, die die Direktive “Allow from all” durch “Require all granted” bzw. “Deny from all” durch “Require all denied” ersetzt.
Und “Order allow,deny” fliegt raus.
In dem Abschnitt: „Block WordPress files from outside access“ ab Zeile 356 wird „Deny from all“ verwendet.
Muss/sollte hier nicht auch, wie in Abschnitt ‚5.1 – Falls Probleme mit der 7G auftauchen, nutze die 6G-Firewall [2020]‘ unterschieden werden zwischen Apache = 2.3 und „Require all granted“ verwendet werden?
Oder bin ich da auf dem Holzweg?
Viele Grüße
Karl
Hallo Andreas, ich erfreue mich seit langer Zeit Deiner vorzüglichen htaccess-Versionen und verwende sie in allen Projekten. Herzlichen Dank dafür! Darf ich fragen wie Deine derzeitige Einschätzung zum Thema CORS ist? Du schneidest das Thema kurz an mit der Definition zulässiger Dateitypen. Nun möchte einer meiner Kunden, dass ich seine Site mit einer CSP, natürlich ohne Verwendung von unsafe-eval/unsafe-inline, ausstatte. Trotz intensiver Recherche finde ich keine gangbare Lösung, die CSP mit den sich ständig ändernden hash bzw. nonce-Werten zu versorgen.
LG Eik
Hi Eik,
es gibt auch keine Möglichkeit, dass bei sich ständig ändernden Umständen zu konfigurieren.
Ich glaube das Thema CSP & WordPress wird noch etwas andauern
Link: https://core.trac.wordpress.org/ticket/39941 (https://core.trac.wordpress.org/ticket/39941)
im Moment sehe ich keine Lösung außer Flickwerk … nicht super
Hallo Andreas, meine htaccess sieht zur Zeit wie folgt aus,
könnte ich diese mit deiner vervollständigen oder meine Zeilen, die in deiner nicht vorkommen mit reinziehen?
Gibt es nicht irgendeine Software, in der man code snipes einfügt und die erkennt Fehler oder gar zeigt mir dann ggf. doubletten an?
Auch nutze ich ein HTTP Header plugin (https://de.wordpress.org/plugins/http-headers/ (https://de.wordpress.org/plugins/http-headers/) ). wenn ich jetzt manuell in die htaccess Datei zb deine htaccess reinkopier, würde mein Plugin die Einstellung erkennen und akzeptieren?
# BEGIN WP Rocket v3.7.1.1
# Use UTF-8 encoding for anything served text/plain or text/html
AddDefaultCharset UTF-8
# Force UTF-8 for a number of file formats
AddCharset UTF-8 .atom .css .js .json .rss .vtt .xml
# FileETag None is not enough for every server.
Header unset ETag
# Since we’re sending far-future expires, we don’t need ETags for static content.
# developer.yahoo.com/performance/rules.html#etags
FileETag None
Header set X-Powered-By „WP Rocket/3.7.1.1“
Header unset Pragma
Header append Cache-Control „public“
Header unset Last-Modified
Header unset Pragma
Header append Cache-Control „public“
# Expires headers (for better cache control)
ExpiresActive on
ExpiresDefault „access plus 1 month“
# cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
ExpiresByType text/cache-manifest „access plus 0 seconds“
# Your document html
ExpiresByType text/html „access plus 0 seconds“
# Data
ExpiresByType text/xml „access plus 0 seconds“
ExpiresByType application/xml „access plus 0 seconds“
ExpiresByType application/json „access plus 0 seconds“
# Feed
ExpiresByType application/rss+xml „access plus 1 hour“
ExpiresByType application/atom+xml „access plus 1 hour“
# Favicon (cannot be renamed)
ExpiresByType image/x-icon „access plus 1 week“
# Media: images, video, audio
ExpiresByType image/gif „access plus 4 months“
ExpiresByType image/png „access plus 4 months“
ExpiresByType image/jpeg „access plus 4 months“
ExpiresByType image/webp „access plus 4 months“
ExpiresByType video/ogg „access plus 4 months“
ExpiresByType audio/ogg „access plus 4 months“
ExpiresByType video/mp4 „access plus 4 months“
ExpiresByType video/webm „access plus 4 months“
# HTC files (css3pie)
ExpiresByType text/x-component „access plus 1 month“
# Webfonts
ExpiresByType font/ttf „access plus 4 months“
ExpiresByType font/otf „access plus 4 months“
ExpiresByType font/woff „access plus 4 months“
ExpiresByType font/woff2 „access plus 4 months“
ExpiresByType image/svg+xml „access plus 1 month“
ExpiresByType application/vnd.ms-fontobject „access plus 1 month“
# CSS and JavaScript
ExpiresByType text/css „access plus 1 year“
ExpiresByType application/javascript „access plus 1 year“
# Gzip compression
# Active compression
SetOutputFilter DEFLATE
# Force deflate for mangled headers
SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
RequestHeader append Accept-Encoding „gzip,deflate“ env=HAVE_Accept-Encoding
# Don’t compress images and other uncompressible content
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g|mp4|webm|webp|pdf)$ no-gzip dont-vary
# Compress all output labeled with one of the following MIME-types
AddOutputFilterByType DEFLATE application/atom+xml \
application/javascript \
application/json \
application/rss+xml \
application/vnd.ms-fontobject \
application/x-font-ttf \
application/xhtml+xml \
application/xml \
font/opentype \
image/svg+xml \
image/x-icon \
text/css \
text/html \
text/plain \
text/x-component \
text/xml
Header append Vary: Accept-Encoding
AddType text/html .html_gzip
AddEncoding gzip .html_gzip
SetEnvIfNoCase Request_URI \.html_gzip$ no-gzip
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} on [OR]
RewriteCond %{SERVER_PORT} ^443$ [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} https
RewriteRule .* – [E=WPR_SSL:-https]
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond „%{DOCUMENT_ROOT}/wp-content/cache/wp-rocket/%{HTTP_HOST}%{REQUEST_URI}/.no-webp“ !-f
RewriteRule .* – [E=WPR_WEBP:-webp]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteRule .* – [E=WPR_ENC:_gzip]
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{QUERY_STRING} =““
RewriteCond %{HTTP:Cookie} !(wordpress_logged_in_.+|wp-postpass_|wptouch_switch_toggle|comment_author_|comment_author_email_) [NC]
RewriteCond %{REQUEST_URI} !^(/(.+/)?feed/?.+/?|/(?:.+/)?embed/|/(index\.php/)?wp\-json(/.*|$))$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^(facebookexternalhit).* [NC]
RewriteCond „%{DOCUMENT_ROOT}/wp-content/cache/wp-rocket/%{HTTP_HOST}%{REQUEST_URI}/index%{ENV:WPR_SSL}%{ENV:WPR_WEBP}.html%{ENV:WPR_ENC}“ -f
RewriteRule .* „/wp-content/cache/wp-rocket/%{HTTP_HOST}%{REQUEST_URI}/index%{ENV:WPR_SSL}%{ENV:WPR_WEBP}.html%{ENV:WPR_ENC}“ [L]
# END WP Rocket
# BEGIN WordPress
# The directives (lines) between „BEGIN WordPress“ and „END WordPress“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
order allow,deny
deny from all
# Wordfence WAF
php_value auto_prepend_file ‚/home/www/auberge-sankt-laurentius.com/wordfence-waf.php‘
php_value auto_prepend_file ‚/home/www/auberge-sankt-laurentius.com/wordfence-waf.php‘
Require all denied
Order deny,allow
Deny from all
# END Wordfence WAF
# BEGIN HttpHeaders
# The directives (lines) between „BEGIN HttpHeaders“ and „END HttpHeaders“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeaders
# BEGIN HttpHeadersAuth
# The directives (lines) between „BEGIN HttpHeadersAuth“ and „END HttpHeadersAuth“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeadersAuth
# BEGIN HttpHeadersCompression
# The directives (lines) between „BEGIN HttpHeadersCompression“ and „END HttpHeadersCompression“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeadersCompression
# BEGIN HttpHeadersContentType
# The directives (lines) between „BEGIN HttpHeadersContentType“ and „END HttpHeadersContentType“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeadersContentType
# BEGIN HttpHeadersExpires
# The directives (lines) between „BEGIN HttpHeadersExpires“ and „END HttpHeadersExpires“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeadersExpires
# BEGIN HttpHeadersCookieSecurity
# The directives (lines) between „BEGIN HttpHeadersCookieSecurity“ and „END HttpHeadersCookieSecurity“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeadersCookieSecurity
# BEGIN HttpHeadersTiming
# The directives (lines) between „BEGIN HttpHeadersTiming“ and „END HttpHeadersTiming“ are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
# END HttpHeadersTiming
Hi,
kurze Antwort: Nein. Das ist jetzt schon ein einziges Mischmasch. Dazu kommt noch ein sinnfreies »Security Plugin« und ein noch sinnfreieres Header Plugin, zig Zeilen von WP Rocket usw. Meine .htaccess ist dafür konzipiert, dass sie so wie sie ist übernommen wird. Nur so kann sie Ihre Aufgaben erfüllen und perfekt arbeiten.
Moin Andreas,
vielen Dank für Deine tolle Hilfe! Die Implementierung der htaccess hat in meinem Fall hervorragend funktioniert, lediglich die Absicherung der wp-login.php führt zu einem Konflikt:
AuthName „Admin-Bereich“
AuthType Basic
AuthUserFile /pfad/wohin/auch/immer/.htpasswd
require valid-user
WordPress nutzt für passwortgeschützte Seiten und für den User-Login offenbar eine Funktion, die vom .htaccess-Schutz ummantelt wird: /wp-login.php?action=postpass.
wp-login.php und damit die dahinterliegende Funktion ‚action=postpass‘ ist allerdings .htaccess geschützt, weshalb zusätzlich der Serverseitige Login erscheint – sowohl bei (durch WP Bordmittel) passwortgeschützten Inhalten, als auch beim regulären User-Login.
Ich habe das gesamte Wochenende damit verbracht, im Internet nach einer Lösung zu suchen – erfolglos. Dazu habe ich u.a. folgenden Artikel gelesen und versucht, die dort gemachten Vorschläge umzusetzen – ebenfalls erfolglos: https://stackoverflow.com/questions/22134475/htaccess-pass-protect-interfereing-with-wordpress-functionality (https://stackoverflow.com/questions/22134475/htaccess-pass-protect-interfereing-with-wordpress-functionality)
Die Antworten im Internet scheinen sich aber im Wesentlichen auf die folgenden zwei Optionen zu beschränken:
1. Usern die Login-Daten für den .htaccess Schutz mitteilen (dämliche Idee)
2. .htaccess-Schutz wieder entfernen (noch dämlichere Idee)
Mir ist schleierhaft, warum WordPress über dieses Thema seltsam wenig zu sagen hat. Das Problem scheint dort bereits seit Jahren bekannt zu sein, eine Lösung wird allerdings nicht erbracht. Vielleicht übersehe ich aber auch etwas? Hast Du vielleicht eine bessere Antwort?
Vielen Dank nochmal!
LG
Lasse
Hi Lasse,
danke für Deinen Kommentar! Nein, ich kann Dir auch keine befriedigendere Antwort geben. Tut mir leid…
Schade, trotzdem nochmal vielen Dank 🙂
Könnte mit einem fehlenden Referrer-Header zusammenhängen, zum Beispiel, weil „HTTP-Header Referrer-Policy“ auf „no-referrer“ gesetzt wurde (ich hoffe, dass Links hier nicht ausgefiltert werden):
https://www.wp-wartung24.de/passwortgeschuetzte-seiten-und-referrer-policies/ (https://www.wp-wartung24.de/passwortgeschuetzte-seiten-und-referrer-policies/)
Hallo Andreas,
auf dem Blog von Jeff Starr bin ich auf ein Addon der 7G-Firewall gestoßen – https://perishablepress.com/stop-aggressive-scanning-uploads/ (https://perishablepress.com/stop-aggressive-scanning-uploads/)
# 7G Addon: Stop Aggressive Scanning for Uploads-Related Targets
Soweit ich das richtig beurteile, ist dies noch nicht Teil deiner hier offengelegten .htaccess-Datei.
Meinst du es macht Sinn, die .htaccess um diese Maßnahme zu erweitern?
Das hört sich grundsätzlich gut an. Allerdings muss es erst getestet werden, bevor es in die finale Version meiner
.htaccesskommt. Denn die muss für mindestens 98% aller User funktionieren.Hallo Herr Hecht,
neben den von Ihnen erwähnten Http-Security-Headern gibt es ja auch noch den „Public Key Pinning (HPKP) Header“. Empfehlen Sie diesen auch zur Sicherung der eigenen Website oder kann dieser vernachlässigt werden?
Die Recherchen ergaben, dass einige diesen Header empfehlen, andere halten nur bedingt etwas von dieser Option, da ein Angreifer den auch gegen einen selbst verwenden könnte.
Über Ihre Meinung dazu, bin ich sehr gespannt.
Besten Dank im Voraus.
MfG
Andreas
Noch ein Nachtrag:
Hat ein Angreifer ein Zertifikat für die gleiche Domain erworben, nützt Ihm das eigentlich nichts, weil er nicht den richtigen Schlüssel (Pin) mitliefert, den der aufrufende Browser bei ersten Aufruf erworben und für sich auf dem Client gespeichert hat. So wird der „Man in the MIddle“ zusätzlich unterbunden.
So sagt es die Theorie. Aber ist es auch wirklich so in der Praxis oder birgt dieser SChutz im Grunde auch eine zusätzliche Sicherheitslücke?
Hallo,
sicherlich gibt es eine Menge Dinge, die man noch zusätzlich machen kann, um die eigene Website vor einem Hack zu schützen. Aber man kann es auch schnell übertreiben. Denn einen echten Hacker interessiert es nicht, eine »normale« Website zu hacken. Wenn der Adminbereich gut geschützt ist und eine gute
.htaccessin Verwendung ist, dann ist ein Hack immer eine Kosten- / Nutzenrechnung. Auch diese „Herren“ fragen sich dann ziemlich schnell, ob sich der Aufwand lohnt. Also nein, ich empfehle den Header nicht, weil hier die Kosten- / Nutzenrechnung nicht stimmt. Viel Aufwand für wenig Schutz.Hallo Herr Hecht,
tolle Beschreibung und besten Dank für die Bereitstellung Ihrer .htaccess-Datei.
Da ich ein absoluter Beginner bin, stelle ich einfach einmal die folgende Frage:
Gibt es eine Möglichkeit die Zugriffsberechtigungen auf die durch die .htaccess gesperrten Dateien und Ordner zu prüfen?
Ich stelle nichts in Frage, möchte nur prüfen, ob ich alles richtig gemacht habe.
Sonnige Grüße aus dem Harz.
Cheers Andreas
Einfach den betreffenden Dateinamen hinten an Deine Domain anhängen und laden.
Hallo.
Danke für den tollen Service.
Bei korrekter Einbindung wären dann PlugIns wie NinjaFirewall oder Wordfence obsolet?
Freue mich auf Feedback
Grüße
Max
Hi Max,
das ist so. Weg mit dem Kram:-)
Danke für die Info. Wieso zeigt mir dann Ninja Firewall noch zahlreiche Attack-Versuche jeglicher Schwere an? Sind dies dann keine Angriffe?
Angriffe gibt es immer und zu jeder Zeit und bei jeder Website auf diesem Planeten. Die Frage ist nur, ob sie erfolgreich sind. Wenn meine
.htaccessinstalliert ist und Du für den Adminbereich ein wirklich sicheres Passwort verwendest, kommt da nichts durch.Wirklich beeindruckend diese .htaccess! Habe ich 1:1 ohne Probleme übernehmen können. Danke für diese Mühe!
Wenn ich das richtig verstehe (ich bin nahezu Laie), ergibt sich zusammen mit den empfohlenen Verbesserungen in der functions.php eine recht weitgehende Absicherung der WordPress-Installation. Gibt es überhaupt Security-Plugins, die einen wirklichen Mehrwert gegenüber diesen Maßnahmen bieten?
Hi Holger,
danke für Deinen Kommentar! Und nein, Security-Plugins bieten nicht einmal Ansatzweise diesen Schutz.
Prima! Dann kann ich mir ja die Installation eines weiteren, fummelig zu konfigurierenden Plugins sparen. Je schlichter und übersichtlicher, desto einfacher die Administration.
Hallo, wo finde ich den die empfohlenen Verbesserungen zur functions.php?
Hallo Andreas,
ich hatte gerade ein Problem mit dem Passwortschutz von WordPress und der .htaccess. Erklärung und Lösung habe ich hier gefunden: https://www.wp-wartung24.de/passwortgeschuetzte-seiten-und-referrer-policies/ (https://www.wp-wartung24.de/passwortgeschuetzte-seiten-und-referrer-policies/)
Vielleicht kannst Du den betroffenen Teil der .htaccess von Dir anpassen?
Danke und Gruß
Frank
Moin Andreas,
vielen Dank für die tolle Dokumentation.
Leider finde ich den Komplett-Download der gesamten Module nicht.
Irgendwie führt der Klick auf den Button ins Leere.
Und kann man die http zu https Umleitung auch dann nutzen, wenn man das Plugin Really Simple SSL nutzt?
Danke und Grüße:
Keno
Hallo Keno,
danke für die Fehlermeldung. Ist jetzt behoben.
Zu Deiner Frage: Höchstwahrscheinlich. Du musst es ausprobieren. Gibt es eine Fehlermeldung, kommentieren den Bereich wieder aus. Übrigens sollte eine HTTPS-Umstellung niemals über ein Plugin geschehen, das kann eine Menge Ärger verursachen. Mache es lieber gleich richtig. Hier findest Du eine gute Anleitung dafür. https://seoagentur-hamburg.com/7326/ (https://seoagentur-hamburg.com/7326/)
Hallo Andreas,
vielen Dank. Das sieht alles sehr gut aus bei mir.
Zwei Fragen:
1. securityheaders.com vermisst bei mir Feature-Policy. Was habe ich übersehen?
2. Es gibt anscheinend laut securityheaders.com ein Problem mit einem Cookie. T“he ‚httpOnly‘ flag is not set on this cookie. The ’secure‘ flag is not set on this cookie. There is no Cookie Prefix on this cookie. This is not a SameSite Cookie.“ Hast du einen Tipp, wo ich schauen muss oder weitere Hilfe bekomme?
Falls du es selber prüfst: nicht wundern: den CSP Teil habe ich (noch) weggelassen.
Danke im Voraus.
Bleib gesund
Jonas
Hallo Andreas,
der Schutz des Adminbereich mittels HTTP-Veriegelung scheint sehr simpel zu sein.
Wie sieht dann die .htpasswd aus? Ist dort irgendeine Information verwahrt?
Danke und Gruß
Max
Moin Andreas,
großartige Deine Arbeit mit der .htaccess. Vielen und mach bitte weiter so!
Zeile 384 >> „Change »?domain\« in line 361 to your domain name“
Die korrekte Zeile wäre (bei mir unter Notepad++) >> 392
Frage:
Wenn ich bei mir unter /root einen Ordner namens „dwl“ besitze, dann kann ich mit der 7G/6G keine Dateien aus dem Ordner mehr downloaden .. wie stell ich das ab?
Danke im voraus für Deine Hilfe.
Grüße aus Hemmoor
Frank
Hallo, ich habe 2 kleine Probleme mit deine .htacess. zum einen funktioniert das ganz nicht mit der Firewall 7G, mit der 6G hab ich keine Probleme. Passt da eventuell noch irgendwas nicht? Ebenfalls bekomme ich mit dem Browser MS Edge keine Bilder auf meinen Seiten angezeigt. An welcher Einstellung könnte das liegen?
LG Andreas
Kann es sein, dass das mit
ServerSignature Off
nicht funktioniert?
Als ich meine, wenn ich ihre Seite bei https://securityheaders.com/ (https://securityheaders.com/) testen lasse dann wird der Server genannt
Hallo, ich habe nochmal eine andere Frage, Habe über deine .htacces die gzip Kompression eingeschaltet. Ebenfalls lasse ich Autoptimize und den Cache Enabler laufen. Wieso sagt mir Pingdom Tools ein Hinweis mit Grade D bei der Gzip Compression? Muss ich da nochmehr oder was anderes einstellen?
LG Michael
Hi, du hast ja in deiner .htaccess den Teil für die gzip compression mit implementiert. Nur Warum zeigt pingdom tools immer noch an, das diese nicht stattfindet?
LG
Weil es dann externe Dateien sind. Da kann keine Komprimierung von Deinem Hosting funktionieren.
Hallo Andreas,
dann habe ich da noch eine weitere Frage. Nutze als CachePlugin das Borlabs Cache in der freien Version. Funktioniert das auch im Zusammenspiel mit Autoptimize oder sollte ich hier zwingend den Cache Enabler verwenden?
LG
Und wie siehts hier mit der wp-config.php aus? Reicht es diese einfach zu schützen oder ist es sogar sinnvoll diese in einen anderen Ordner zu schieben?
LG
Hi,
guckst Du Dir vielleicht die
.htaccessmal genauer an?Hi, was meinst du? Ich habe jetzt schon häufiger gelesen, das man die wp-config auch in einen Unterordner packen kann und die im Root nur auf die verschobene Datei verweist.
Wenn Du Dir die Datei mal richtig angeschaut hättest, würdest Du wissen, dass die
wp-config.phpbereits geschützt ist. DAS MEINE ICH.Hi,
mit Cache Enabler wird die Website schneller.
Ja das macht das Borlabs Cache auch und es hat in vielen Tests perfekt angeschnitten. Ich weiß natürlich nicht wie das Zusammenspiel mit Autopimize und deiner .htaccess so ist. Deswegen frage ich ich
Hallo Andreas, ich habe mal eine Frage zum Schutz des Admin – Bereiches. Du setzt ja nur einen Schutz auf die wp-login.php. Reicht das oder sollte man auch noch einen Schutz auf den Ordner wp-admin setzen?
Heisst also wenn ich meine Domain mit wp-admin aufführe gibt es dann auch das Login-Fenster?
Ich setze auch gerne mal das Plugin WPS Hide Login ein, wenn ich hier also aus wp-admin einfach nur login machen, muss ich dann darauf auch noch einen Schutz setzen? Wenn ja wo?
LG Michael
Hi Michael,
das reicht vollkommen. Es wird sowohl die
wp-login.phpals auch der Ordner/wp-admin/komplett geschützt. WPS Hide Login und ähnliche Plugins solltest Du nicht einsetzen, die bieten keine echte Sicherheit. Setze den HTTP-Schutz ein und niemand hackt Deinen Adminbereich.Hallo Andreas,
ich hab deine tolle .htaccess eingesetzt und bin bestens zufrieden und habe keinerlei Probleme mit unangenehmen sachen, recht herzlichen Danke für Deine Zeit und Arbeit die du uns zur Verfügung stellst.
Habe jetzt ein Theme in einsatz bei dem ich eine Fehlermeldung bekomme:
Fehler beim Laden der Plugin-URL: https://meineurl.com/wp-content/themes/enfold/config-templatebuilder/avia-template-builder/assets/js/avia-tinymce-buttons-4 (https://meineurl.com/wp-content/themes/enfold/config-templatebuilder/avia-template-builder/assets/js/avia-tinymce-buttons-4). js
Was muss ich in der .htacces deaktivieren damit diese Datei geladen wird.
Ich sage schon mal Danke im Voraus
Ernest
Hallo Ernest,
das liegt nicht an der
.htaccess. Da würde ich mal die Console zu Rate ziehen.Hallo Andreas,
ich habe in der htaccess mal alles rausgenommen – bis auf: „Beginn WordPress“ und „Protect wp-login.
Dannach hat meine Internetseite wieder funktioniert.
Weil ich wissen wollte von welchen Modul (Firewall etc.) habe ich alle Sektionen einzeln rausgenommen und dann die Seite probiert. Es kammen keine Fehler mehr vor.
Also ist es so wie du geschrieben hast: es liegt nicht an der htaccess.
Deshalb werden ich diesen Themeherstelle auf die Nerven gehen.
Danke für die Hilfestellung
Ernest
Hallo Andreas,
nur zur Info!
Es hat doch an der Firewall G7 im Teilbereich: # 7G:[REQUEST URI] gelegen.
Hab es jetzt gegen Firewall G6 getauscht, jetzt funktioniert es, bekomme manchmal Darstellungfehler wenn ich zwischen den Layout-Editor und dem Standart-Editor hin und her switche.
Mal sehen wie ich jetzt weiter mache, ist ja nur ein Testlauf – oder ob ich dieses Theme in die Tonne kloppe.
Mit Besten Grüssen
Ernest
Hallo Andreas,
schön, dass sich jemand mal in einem Artikel dem Thema ziemlich erschöpfend widmet.
Zum Browser-Caching habe ich aber mal eine Frage bezüglich der Zeitangabe, wie lange etwas im Cache bleiben soll. Ich lese da z.B. hier im Artikel, aber auch bei anderen Quellen immer wieder mal „0 Sekunden“, also z.B. :
ExpiresByType application/ld+json „access plus 0 seconds“
Was macht es für einen Sinn, eine Caching-Zeit von „0“ festzulegen? Wozu dann überhaupt cachen?
So ein JSON-LD-Code ändert sich nicht oft im Regelfall und selbst wenn, hat es keine Auswirkung auf den Besucher, da das reine Meta-Informationen für Sumas sind. Warum nicht besser 1 Monat oder so?
Grüße,
Martin
Hi,
JSON zu cachen wäre eine echt schlechte Idee. Wie kommst Du darauf, dass sich da nichts ändert? Die API wird mittlerweile von etlichen Anwendungen genutzt, die Live-Daten zur Verfügung stellen. Jede Steuerung von WordPress oder Inhalten von Extern geht über diese API. Wird diese gecacht, sind etliche Daten nicht mehr aktuell.
Hallo,
nicht JSON, sondern JSON-LD-Code für die Sumas. Ich bin kein Experte, aber ich glaube, das sind verschiedene Dinge. Was ich meine, ist z.B. für eine Über-mich-Seite, bei der man sich im JSON-LD-Code als „Person“ den Sumas beschreibt: https://jsonld.com/person/ (https://jsonld.com/person/) bzw. bei schema.org: https://schema.org/Person (https://schema.org/Person).
Oder man kann z.B. ein „Event“ damit beschreiben, ein Rezept, einen News-Artikel usw. usw.
Wenn so ein Code fertig ist, dann kommt er in die WP-Page, in den head oder auch in den body irgendwo und je nach Datentyp ändert sich da meist nichts mehr so schnell. Name, Adresse, Beruf usw. für mich als „Person“ bleiben ja gleich. Wenn ich den Code in die WP-page einfüge, fasse ich den so schnell nicht mehr an. Warum auch. Bei den meisten anderen Dingen, z.B. einem Rezept oder Artikel ist das ähnlich – es sei denn, ich ändere das Rezept bzw. den Artikel selbst. Dann mus man evtl. auch den schema-Code anpassen.
JSON-LD-Code sind reine Meta-Informationen, ähnlich einer meta description, der Besucher sieht das nicht.
Hallo Andreas, vielen Dank für die tolle Arbeit. Hat mir wirklich sehr geholfen.
Hätte nur eine kurze Frage. Ich habe in meinem WordPress einen Ordner liegen den ich von außen zugänglich machen will. Wenn dieser mit deiner htaccess angesprochen wird kommt die Meldung 403. Was müsste ich ändern um das zu erlauben. Vielen Dank im Voraus.
Hi Jürgen,
kann ich so auf die Schnelle nicht sagen. Musst Du austesten.
Hallo, OK, trotzdem vielen Dank.
Setzen Sie diese htaccess auch auf https://andreas-hecht.com/ (https://andreas-hecht.com/) ein?
Wenn ja, dann gibt es laut PageSpeed Insights etwas zu verbessern. Es wird folgende Empfehlungen gegeben:
Statische Inhalte mit einer effizienten Cache-Richtlinie bereitstellen
was sagen Sie dazu?
Die
.htaccesswird auf Hunderten von Seiten eingesetzt. Und PageSpeed Insights taugt einen Schei… Das solltest Du nun wirklich nicht nutzen. Die Pingdom Tools zeigen Dir den Speed genau. Googles Tool wird nur von Amateuren eingesetzt, die sich die Haare raufen, weil der Scheiß besonders auch seine eigenen Dateien anmahnt.Danke für Ihre Antwort!
Wenn ich Ihre Seite mit PINGDOM teste, dann wird folgendes vorgeschlagen:
add expires headers
die gleiche Meldung kommt auch bei anderen WordPress-Seiten, die ich getestet habe.
Meiner Meinung haben Sie das doch getan. Was will denn PINGDOM noch? Verstehe ich nicht.
Hallo Herr Hecht,
erstmal danke für diese grandiose htaccess.
Wenn ich die 7G Firewall nutze, komme ich nicht mehr in das Backend. Es wird mir forbidden access ( 403 ) angezeigt. Mit der 6G Firewall klappt alles einwandfrei.
Ich nutze das Plugin “ WPS Hide Login “ und bin mir sicher, dass es daran liegt. Hätten Sie eine Idee, was ich an der 7G Firewall ändern oder löschen könnte, damit es funktioniert ?
Vielen Dank
Grüsse
Hallo Herr Otterpohl,
warum kommen Sie auf die Idee, etwas an der Firewall ändern zu wollen? Das wäre eine total schlechte Idee. Löschen Sie lieber das völlig sinnfreie Plugin und verwenden Sie starke Passwörter. Dann benötigen Sie kein Plugin, dass Ihnen nur Sicherheit vorgaukelt, anstatt sie zu bieten.
Hallo Herr Hecht,
genau nach so einer htaccess habe ich lange gesucht. Nun habe ich sie endlich gefunden. Leider funktioniert die 7G Firewall nicht bei mir. Aber das ist nicht so schlimm, die 6 Version funzt ohne Probleme. Vielen dank dafür.
Grüße aus Essen
Hi Dennis,
schön, dass ich Dir damit helfen konnte:-)
Hallo,
ich habe die komplette htaccess Datei in die Website übernommen.
auf der Webseite gibt es einen Link intern mit Passwortabfrage.
Dieser Link funktioniert mit dem IE komplett, aber nicht mit dem neuesten Firefox.
Nach Eingabe des Passwortes erhält man einen weissen Screen.
Wenn ich die htaccess Datei gegen die standardmäßige austausche, funktioniert es.
Alle anderen Links arbeiten sonst korrekt. Woran liegt das in Ihrer htacces Datei?
Danke für einen Tip.
Gruß
Ralph Missing
Hallo Ralph,
bitte lies den Artikel komplett.
Welchen Artikel meinst Du?
Gruß
Ralph
Hi Andreas!
danke erstmal für das Script 🙂 ich glaube deine Übersetzung des Kommentars widerspricht sich…welche Variante stimmt?
# Comment it out, if you don’t use Let’s Encrypt, because Let’s Encrypt is using .well-known
# Wenn Du Let’s Encrypt nutzt, kannst Du das nicht verwenden, weil Let’s Encrypt .well-known nutzt.
Hi Torsty,
wenn ich meine Kommentare dazu lese, dann sagen sie beide für mich das Gleiche aus. Nur anders geschrieben. Bei beiden kommt sinngemäß heraus: du kannst den Block nur nutzen, wenn du kein Let’s Encrypt-Zertifikat verwendest.
Hallo Andreas,
sollte die Datei wp-cron.php nicht auch geschützt werden?
Gruß Frank
Hi Frank,
die ist nicht so leicht für einen Hack zu nutzen. Daher: Nein!
Hallo Andreas,
im aktuellen wp-scan wird die wp-cron als mögliches Ziel gelistet:
https://www.iplocation.net/defend-wordpress-from-ddos (https://www.iplocation.net/defend-wordpress-from-ddos)
https://github.com/wpscanteam/wpscan/issues/1299 (https://github.com/wpscanteam/wpscan/issues/1299)
Ein Schutz mittels htaccess würde ja nicht schaden, oder?
Gruß Frank
Hallo Frank,
das ist grundsätzlich richtig. Doch ein Schutz durch eine
.htaccessist grundsätzlich schwierig – was ja auch Deine Links aussagen. Das sit definitiv nichts, was normale User implementieren können und sollten. Denn die wp-cron wird ja für die WordPress-Updates zwingend benötigt.Hi,
aufwändige Zusammenfassung, sehr schön, danke!
Hallo Andreas,
danke für die aktualisierte Version deiner tollen HTACCESS-Datei!
Bzgl. dem Block „Block Nuisance Requests for Non-Existent Files“ (Zeile 31 – 43) habe ich eine Frage.
Wenn ich Let’s Encrypt benutze, sollte ich dann den gesamten Block nicht verwenden oder kann ich lediglich die Zeile 40 (RedirectMatch 403 (?i)\.(git|well-known)) mit einem # deaktiviert lassen und den Rest verwenden?
Ich verwende momentan den gesamten Block und konnte bisher keine negativen Auswirkungen feststellen, obwohl ich Let’s Encrypt bei meiner Seite verwende – oder wirken sich die Einstellungen evtl. an einer anderen Stellen negativ aus?
Gruß
Alex
Hi,
Du kannst die Zeile 40 auskommentieren, dann funktioniert Let’s Encrypt bei den meisten Hostern. Negative Auswirkungen gibt es erst, wenn das Zertifikat erneuert werden muss. Dazu muss auf
.well-knownzugegriffen werden können.Danke für die tolle Zusammenfassung.
Hat schon jemand herausgefunden warum die Mediathek bei der 7g Firewall nicht funktioniert? Wäre doch sinnvoller das zu fixen als einfach auf die 6g auszuweichen.
Grüße,
Peter
Hi Andreas,
für Yoast-Nutzer muss die /wp-content/-.htaccess so aussehen, damit die Sitemaps generiert werden können.
LG
Dirk
Order deny,allow
Deny from all
Allow from all
Hi Dirk,
ich nutze auch Yoast SEO und habe keinerlei Änderungen an meiner
.htaccessvorgenommen. Die Generierung der Sitemaps läuft ohne Probleme.Hi,
schöne Zusammenfassung, top Artikel, danke!
Gruß
Rüdiger
Hallo,
spircht irgendetwas dafür oder dagegen diese .htaccess mit der NinjaFirewall für WP zu kombinieren? Ich verwende die jetzt seit über 2 Jahren und bin seither von Hacks verschont geblieben auf über 10 Websites. Davor war das anders. Zumindest hatte ich daruch eine gute Routine zum Bereinigen und Wiederherstellen entwickelt 😉
LG
Jürgen
Hallo Jürgen,
die
.htaccesshat bereits eine Firewall integriert, die hervorragend funktioniert und Deine Website optimal schützt. Einer Plugin-Firewall würde ich persönlich grundsätzlich nicht vertrauen.Hallo Andreas,
Ich bin Hendrik und erst mal vielen, vielen Dank für deine Mühe und deine Sachkenntnis. Ich bin eher zufällig über diesen tollen Beitrag gestoßen, weil ich mit meiner Seite Probleme hatte.
Vor etwa einer Woche wollte ich meine Seite https://www.discoflexibel.de/ (https://www.discoflexibel.de/) aufrufen und da wurden unerwartet Sexseiten geöffnet, die man auch nicht mehr schließen konnte. Na toll, eine besondere Promotion für meine Kunden!!!!
Ich konnte das nur wieder retten, indem ich ein Backup vom März 2019 eingespielt hatte. Leider gingen dann auch die aktuellen Veränderungen verloren.
Ich habe nun die komplette .htacess_Datei auf meinen Server bei Netcup hochgeladen und bis jetzt funktioniert alles ohne Probleme.
Ich habe dazu noch 2 Fragen?
Muss ich nachfolgenden Code noch anpassen oder bleibt der so?
# No error log access
Order allow,deny
Deny from all
#No access to the .htaccess und .htpasswd
Order deny,allow
Deny from all
Und wie kann ich überprüfen ob das alles so funktioniert wie du das das ja beschreibst?
Ich bedanke mich jetzt schon für deine Antwort und viele nette Grüße nach Hamburg.
DJ Hendrik
Hallo Hendrik,
Du musst da nichts mehr anpassen. Und Du kannst Dir sicher sein, dass alles funktioniert, wie es soll. Vielleicht setzt Du noch den einen oder anderen Tipp aus diesem Artikel um: 4 Profi-Tipps: So sicherst Du Dein WordPress richtig ab! (https://seoagentur-hamburg.com/1584/). Der Punkt 2 aus diesem Artikel ist ebenfalls hilfreich: Wie Du Hacker richtig ärgern kannst mit diesen Snippets (https://seoagentur-hamburg.com/7257/).
Nachtrag: …auf die über „IfModule !authz_core_module“ bzw. „IfModule authz_core_module“ sowohl Apache 2.2 als auch Apache 2.4+ reagieren… ist irgendwie weggefiltert worden?!
Hallo Andreas,
die Zusammenstellung Deiner .htaccess ist grandios; doch müssten für Apache 2.4 nicht alle Vorkommnisse von:
Order deny,allow
Deny from all
ersetzt werden durch:
Require all denied
oder alternativ eine konditionale Direktive zum Einsatz kommen, auf die über bzw. sowohl Apache 2.2 als auch Apache 2.4+ reagieren.
Siehe: https://htaccessbook.com/access-control-apache-2-4/ (https://htaccessbook.com/access-control-apache-2-4/)
In der 6G-Firewall – Version 2019 (line 58-72) verwendest Du ebenfalls die konditionale Direktive, nicht jedoch im Abschnitt 6 (WordPress-Dateien gegen Zugriff blocken) d.h. im .htaccess (Gist, line 329-369).
Hat das einen Grund?
Vielen Dank für Deine Mühe!
Marcel
Hi Marcel,
hier geht es um größtmögliche Kompatibilität. Deshalb wird das so notiert.
Vielen vielen Dank, Ihre geniale htaccess!
Das mit dem EXPECT-CT verstehe ich jedoch noch nicht so recht und dazu habe ich keine Antwort auf meine Frage gefunden oder vielleicht auch habe ich es nicht kapiert.
Woher bekomme ich das Zertifikat, das durch diesen Header abgefragt wurde überprüft wird?
Kann ich diesen Header gefahrlos einsetzen und was ist, wenn das Zertifikat falsch ist?
Hi Christine,
Du kannst das gefahrlos einsetzen.
Zwischenzeitlich habe ich für die Bilder-Optimierung das Plugin Optimole Images benutzt. Mit etwas Verzögerung fiel mir auf, dass ich keinen Zugriff auf die Mediathek mehr hatte, jedenfalls nicht aus dem Backend heraus. Beim Schreiben konnte ich zugreifen und auch ihren Inhalt sehen. Beim direkten Aufruf wurde nichts angezeigt bis auf eine leere Seite. Ich habe in der .htaccess die Firewall 7 gegen die Version 6 ausgetauscht. Jetzt funktioniert es wieder. Kann das deiner Meinung nach damit zu tun gehabt haben? Danke und beste Grüße H.
Das Komische ist, ich hatte in der Zwischenzeit im 7G Bereich mit auskommentieren versucht den Fehler zu finden. Irgendwann war er dann weg. Allerdings ging es auch noch als alles wieder aktiviert war. Muss da noch mal in Ruhe gucken.
Hallo Andreas,
mir ist ein Problem mit deiner htaccess Datei aufgefallen. Ich nutze Akeeba Backup für all meine WordPress Seiten. Sobald ich eine Seite auf deine wirklich tolle htaccess Datei umstelle funktioniert die Konfigurations-Seite von Akeeba nicht mehr.
Irgendwie blockiert ein Parameter der htaccess den Zugriff.
Folgenden Fehler finde ich per Webconsole:
wp-content/plugins/akeebabackupwp/app/media/js/solo/configuration.min.js?ver=3.4.2.2 net::ERR_ABORTED 403 (Forbidden)
Kannst du daraus Rückschlüsse auf die Ursache ziehen?
Danke
Alex
Hi Alex,
das könnte an der 7G-Firewall liegen. Wechsle mal bitte auf die 6G zurück.
Ah, okay habe gefunden, dass ich Funktion Punkt 3 nicht nutzen kann. Gibt es vielleicht alternative Möglichkeiten?
Guten Morgen Herr Hecht,
Danke für Deine Mühe oben.
Ich habe eine Frage. Kann es sein, dass ein Eintrag in der .htaccess zu folgender Anzeige im PlugIn „SUCURI“, führt?
SUCURI: SiteCheck error: Unable to properly scan your site. 403 Forbidden
Besten Dank
Hi Marcel,
ja, wenn Du die 7G-Firewall verwendest. Tausche Sie gegen die 6G aus, dann sollte es funktionieren.
Hallo Andreas,
tolles Script, vielen Dank.
Einen kleinen Hinweis hätte ich da allerdings, bei mir funktionierte nach der Integration des 7G Firewall-Update mein Kontaktformular nicht mehr. Du schriebst ja schon, dass es Probleme geben könnte, nur verwende ich kein WP. ???. Nach dem Zurücksetzen war alles wieder tipi topi. Vieleicht findest Du ja eine Lösung für dieses Problem.
Beste Grüße
Hallo, ich denke das ist eine superSache! Werde ich bald ausprobieren. Danke dafuer! Leider habe ich ein Problem in Punkt 3: Block Nuisance Requests. Was mache ich denn wenn ich gerade ein Let’s Crypt Zertifikat nuze? Muss ich dann komplett auf diese Funktion verzichten?
Wow, was für eine tolle Anleitung. Bin seit ein paar Tagen schon auf der Suche nach so etwas gewesen, da ich meine .htaccess bezüglich HTTP Security-Header aufrüsten wollte.
Habe das auf anderen Seiten gelesen und es ausprobiert. Aber wenn ich meine Seite analysiert habe, hat sich rein gar nichts verändert. Es werden immer noch die gleichen Fehler angezeigt. Dachte das liegt an mir und hab nach weiteren Lösungen gesucht. Und jetzt habe ich deine Beispiele eingefügt (aus Gist) und trotzdem tut sich nichts.
An was könnte das liegen? Muss ich meinen Hoster (all-inkl) mal besser anschreiben? Bin echt langsam verzweifelt…
MfG
Rainer
Hallo Andreas,
super Beitrag von dir, vielen dank dafür!
Ich habe eine kurze Frage, ich betreibe 2 Seiten von 1 Hoster, dh ich habe im sftp [/] 2 Ordner mit jeweils 2 verschiedenen Ordner IDs von den Seiten.Muss ich das Verzeichniss aus deinen Code irgendwie ändern?
Vielen Dank für Ihre schnelle Antwort.
Lieber Herr Hecht,
danke für die geleistete Arbeit und das Sie Ihre Datei auch noch gratis der Community zur Verfügung stellen. Ich hätte ein/zwei Fragen: Kann ich Ihre .htaccess Datei auch in Kombination mit dem Plugin „WP Rocket“ verwenden oder kommt es zu Problemen? Bzw. gibt es ein Plugin (z.B. Sicherheitsplugins wie iTheme Security) welches ich auf keinen Fall zusammen mit Ihrer Datei verwenden sollte?
Beste Grüße
Hallo Paul,
anstatt WP Rocket würde ich Autoptimize und Cache Enabler nehmen, die sind in Kombination deutlich schneller. Sicherheitsplugins würde ich definitiv nicht einsetzen.
Siehe: https://seoagentur-hamburg.com/1584/ (https://seoagentur-hamburg.com/1584/)
Hey Andreas,
nochmals vielen Dank an dieser Stelle für deine hammermäßige .htaccess.
Allerdings wunder ich mich dass die Pingdom Tools das fehlende gzip anmeckern:
F45 Compress components with gzip
Das wird doch in der htaccess aktiviert, oder?
Hi Alex,
ist aktiviert. Pingdom meckert aber auch bei Fremd-Ressourcen…
Hallo Andreas, guten Abend Herr Hecht,
vielen Dank für diese tolle .htaccess . Ich habe eine kleine Frage. Wie kann ich über die .htaccess eine Verbindung zu Gravatar.com verbieten ? Es gibt zwar viele Möglichkeiten Gravatare zu unterbinden/verbieten usw, ich kenne diese Möglichkeiten fast alle. Ich habe aber einen Code-Schnipsel “ #profile-header .background-avatar “ gefunden, der trotz aller mir bekannten Möglichkeiten Gravatare in meine Seite einbindet. Die für mich einfachste Möglichkeit diese zu verhindern wäre über die .htaccess. Kannst du mir mit einem einfachen Code-Schnipsel weiter helfen ? Vielen Dank im Voraus ! gtx, Olli
Hi Olli,
warum so kompliziert? Log Dich in WP ein und gehe zu »Einstellungen => Diskussion«. Da kannst Du die Avatare komplett abschalten.
Hallo Anderas,
erst mal Danke für deine Antwort. Genau diese Lösungsansätze meinte ich, als ich schrieb, ich kenne fast alle. Und genau diese Möglichkeit bringt rein gar nichts. Es werden dann nur die Gravatare ausgeblendet. Die Verbindung zu, und der Datenabgleich mit, Gravatar.com findet trotzdem statt. Und genau das will ich verhindern. Nur das Abschalten, wie du es beschreibst, verhindert nicht den Datenabgleich. Auch die bekannten PlugIns, die Gravatare ausschalten sollen, blenden nur die Bilderchen aus. Die eigentliche Verbindung zu Gravatar.com läuft aber weiter. Ich habe dich schon gezielt nach einer .htaccess Möglichkeit gefragt. WordPress nimmt mit so vielen Diensten im Hintergrund Verbindung auf, ohne das wir wissen mit welchen. Woher weiß ein PlugIn, dass es ein Update gibt? Das mag ja nett und komfortabel sein. Aber Kontrolle ist etwas anderes. Ich will die Verbindung zu Gravatar.com verhindern.
Hallo,
ich wollte dir gerne mitteilen dass ich nun nach schrittweisem einfügen der htaccess zeilen den Übeltäter für die im wp-admin nicht-fixierte sidebar sowie der fehlenden mouse over effekte gefunden habe:
RewriteCond %{QUERY_STRING} (globals|mosconfig([a-z_]{1,22})|request)(=|[|%[a-z0-9]{0,2}) [NC,OR]
Kannst du mir mehr dazu sagen was genau dieser Befehl tut, und weshalb dieser die Darstellung zerstört?
Bei einer frischen wordpress installation passiert dies übrigens nicht. Heisst es muss mit irgendeinem Plugin oder einer Konfiguration in Konflikt geraten.
Hi,
ich habe deinen Kommentar gelesen, jedoch wüsste ich nicht dass in den Einstellungen des Webhosters eine force www option gäbe.
Die URL Ansich ist dort bereits mit https://www (https://www). hinterlegt.
Das weiterleiten auf https://www (https://www). funktioniert ja auch wenn die domain ganz gewöhnlich geöffnet wird in allen varianten. (mit und ohne www, mit und ohne https).
Jedoch bei einer direkten Eingabe einer Bild URL in die Browser Adressleiste, funktioniert dies leider nicht.
http://domain.com/bild.jpg (http://domain.com/bild.jpg) -> https://domain.com/bild.jpg (https://domain.com/bild.jpg)
https://domain.com/bild.jpg (https://domain.com/bild.jpg) -> https://domain.com/bild.jpg (https://domain.com/bild.jpg)
Nur folgende variante wird zum gewünschten Ziel weitergeleitet:
http://www.domain.com/bild.jpg (http://www.domain.com/bild.jpg) -> https://www.domain.com/bild.jpg (https://www.domain.com/bild.jpg)
Oder verursacht dies kein Duplicate Content wenn sowohl mit und ohne www links/bilder geöffnet werden können?
Übrigens scheint eine der Rules auch Schwierigkeiten mit Javascript zu verursachen.
Die sidebar im backlink ist nicht mehr fixiert und bewegt sich beim scrollen nicht mit.
Ebenfalls tauchen keine untermenus beim mouse over effect auf.
Auch sucuri meldet dass zugriffe zu manchen .js dateien geblockt sei.
/wp-content/plugins/revslider/public/assets/js/jquery.themepunch.revolution.min.js
Unable to scan the page. 403 Forbidden
/wp-content/plugins/revslider/public/assets/js/jquery.themepunch.tools.min.js
Unable to scan the page. 403 Forbidden
Habe bereits die Rules angeschaut konnte aber auf anhieb nichts finden, welches diese blockiert.
Bevor ich nun jede Zeile einzeln entferne bis ich den Fehler finde, wäre ich dir sehr dankbar mir da kurz weiterzuhelfen, sofern dir der Fehler bekannt ist.
Vielen Dank im Voraus und sorry wegen des Langen Textes, aber ich wollte dies gerne genauer Erläutern bezüglich des „force https with www“.
Hallo,
leider wird jedoch die URL dann nicht zwingend über https://www (https://www). aufgerufen sondern auch über https:// (was zum duplicate content führt). Beispielsweise wenn eine Image URL ohne www. im browser geöffnet wird.
Habe es nun mit Hilfe folgenden Rules hinbekommen, jedoch scheint sich dies sehr auf die Performance auszuwirken.
Ich vermute es sind zuviele Abfragen welche gemacht werden? Möglicherweise kann man diese Rule irgendwie zusammenfassen?
Ansonsten habe ich keine Möglichkeit gefunden zwingend https://www (https://www). verwenden zu können ohne eine solche Rule zu erstellen? Da hilft leider auch das hinterlegen der https://www (https://www). in den Einstellungen nicht.
# ———————————————————————-
# FORCE USING https://WWW (https://WWW).
# ———————————————————————-
RewriteEngine On
RewriteCond %{HTTPS} =off [OR]
RewriteCond %{HTTP_HOST} !^www. [OR]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index.(html|php)
RewriteCond %{HTTP_HOST} ^(www.)?(.+)$
RewriteRule ^(index.(html|php))|(.*)$ https://www.%2/$3 (https://www.%2/$3) [R=301,L]
Hast Du meinen Kommentar überhaupt gelesen?
Ich zitiere mich mal:
Punkt.
Danke nochmals!
Mir ist gerade aufgefallen dass wenn ich mein backend über http://www.beispiel.com/wp-admin (http://www.beispiel.com/wp-admin)
aufrufe, diese zu folgender URL weitergeleitet wird:
https://www.www.beispiel.com/wp-admin (https://www.www.beispiel.com/wp-admin)
Das Problem besteht nur in der Kombination, bei der http://www (http://www). am Anfang sowie /wp-admin am Ende der URL steht.
Da ich generell das www in meiner Domain nutze, habe ich dafür lediglich folgende Zeile bearbeitet:
RewriteRule ^ https://www.% (https://www.%){HTTP_HOST}%{REQUEST_URI} [L,R=301]
Ich vermute dass dies so nicht funktioniert und ggf. auch weitere Zeilen bearbeitet / eingefügt werden müssen?
Ebenfalls möchte ich gerne erreichen dass jede URL auf https://www (https://www). weitergeleitet wird, sprich auch wenn links zu images direkt per http:// oder http://www (http://www). oder https:// geöffnet werden.
Dies hatte ich zuvor mit anderen Rules hinbekommen, funktioniert aber in der Zusammenstellung mit deinen htaccess Rules leider nicht 🙁
Übrigens, ich gehe davon aus, dass es sich bei folgender Zeile um blockierte user agents handelt? Genügt es hier |ahrefs| zu entfernen um den crawler wieder zu zulassen?
RewriteCond %{HTTP_USER_AGENT} (360Spider|acapbot|acoonbot|ahrefs| ….
Nochmals vielen Dank im Voraus!
Hi,
nicht im Code der Datei herumfummeln. Das geht immer schief. Der betreffende Code-Teil ist nur zur definitiven Umleitung von http auf https da. Die von Dir gewünschte Domain stellst Du unter »Einstellungen => Allgemein« ein. Zudem noch in den Einstellungen Deines Webhosters. Das war es dann.
Danke!
Dann hat ggf mein hoster diese Regeln erstellt. Jedenfalls sind die oben genannten Rules nicht sinnvoll, könnten sogar die gesamte Konfiguration durcheinander bringen?
Wegen des Settings bezüglich WebP mit Optimus. Ich habe diese deaktiviert und nutze stattdessen imagify. Was ist deiner Meinung nach sinnvoller?
Optimus HQ, also die Premium-Version für 29 USD / Jahr. Ist das zurzeit beste Plugin.
Hallo,
vielen, vielen Dank für die sehr ausführliche htaccess Datei! 🙂
Ich habe jedoch eine Frage zum cache-enabler. Und zwar erstellt dieser mir ebenfalls Rules in die .htaccess Datei. Kann ich diese zusätzlich, am Ende der Datei einfügen? Oder überschreiben sich hier die einen oder anderen Rules?
Beispielsweise folgendes würde dann doppelt auftauchen (in deinen htaccess rules und in denen vom cache-enabler. Sollte ich hier alles was doppelt ist entfernen?
RewriteEngine On
RewriteBase /
Ebenfalls bin ich mit folgender Zeile etwas unsicher. In deinen rules steht:
RewriteRule . /index.php [L]
In denen vom cache-enabler:
RewriteRule . /index.php [END]
Hier die gesamte Auflistung der Rules vom Cache Enabler.
# BEGIN Cache Enabler
RewriteEngine On
RewriteBase /
# set blog sub path
SetEnvIf Request_URI „^(.*)$“ SUB_PATH=/wp-content/cache/cache-enabler/
# set Cache Enabler path
SetEnvIf Request_URI „^(.*)$“ CE_PATH=$1
SetEnvIf Request_URI „^(/)index.php$“ CE_PATH=$1
# webp HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =““
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTP:Accept} image/webp
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index-webp.html.gz -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index-webp.html.gz [L]
# gzip HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =““
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html.gz -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html.gz [L]
AddType text/html .gz
AddEncoding gzip .gz
# webp HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =““
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{HTTP:Accept} image/webp
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index-webp.html -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index-webp.html [L]
# default HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =““
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html [L]
# wp override
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [END]
# END Cache Enabler
Hallo Nissa,
ich höre zum ersten Mal, dass Cache Enabler Regeln in der
.htaccessDatei erstellt. Da scheint etwas mit der Konfiguration nicht zu stimmen. Oder hast Du die selbst hinzugefügt? Wie auch immer, die kannst Du löschen, wenn Du meine KOMPLETTE.htaccessverwendest.Bei der Verwendung des Plugins „All-in-One Event Calendar“ kann es im Frontend beim Durchblättern des Kalenders zu einem 403 kommen. Auf der Suche Suche nach dem Grund wurde ich hier fündig:
https://www.academiathemes.com/2018/all-in-one-event-calendar-something-went-wrong-while-fetching-events-403-forbidden/ (https://www.academiathemes.com/2018/all-in-one-event-calendar-something-went-wrong-while-fetching-events-403-forbidden/)
Auch bei mir half es, die Zeile „RedirectMatch 403 (?i)(~|`||:|;|,|%|\\|\s|\{|\}|\[|\]|\|)“ auszukommentieren.
Lieber Andreas, ich hab bitte eine Frage. Wenn ich für eine neue Seite ein gutes WordPress Hosting, wie Kinsta oder Raidboxes benutze, brauche ich trotzdem viel an der .htaccess zu ändern? Ich habe nämlich wenig Ahnung und es wäre nicht schlecht, wenn ich mir etwas Arbeit ersparen könnte.
Viele Grüße
Franko
Hallo Franko,
Kinsta oder Raidboxes ist nicht gerade sehr gutes WordPress-Hosting. Ich würde immer zu hostNET tendieren (https://seoagentur-hamburg.com/1211/), weil die wirklich schnell sind. Und ja, die
.htaccesswürde ich immer verwenden. Und zwar die komplette. Hat schon seinen Grund, warum die so ist, wie sie ist.Vielen Dank für die tolle .htaccess! Ich habe auch die Aktualisierungen im Auge behalten und bei mir immer wieder erneuert. Läuuuft. Klasse, dass du dir die Mühe machst, dich mit dieser komplizierten Materie so detailliert auseinanderzusetzen und dein Wissen in dieser Form weiterzugeben.
Hallo Horst,
gern geschehen!
Hi Andreas,
In meiner alten htaccess war schon irgendwie totales Chaos :D.
Da hat mir das echt geholfen!
weiter so
Viele Grüße
Hi Domi,
das freut mich!
Dankeschön Herr Hecht für ihre erneute Erklärung.
Wenn ich nun eine voll und ganz funktionierende Content security Policy habe, dann brauche ich das mit den CORS nicht???
Der Artikel auf Dr. Web über die HTTP security header Ist schon etwas älter. Wie wäre es mit einem Update für diesen Artikel oder auch einen neuen Artikel, in welchem auch über CORS aktivieren informiert wird, also wann man das ganze braucht bzw. wann dies sinnvoll ist und auch mit dem neuen header Feature-Policy ?
Hi Franz,
den Artikel auf Dr. Web werde ich so schnell wohl nicht updaten. Warum man das Ganze braucht steht ja schon in diesem Artikel. Header die in meiner
.htaccessnicht enthalten sind, sind zu kompliziert zu implementieren und bringen dafür letztendlich nicht ausreichend zusätzliche Sicherheit.Recht herzlichen Dank für Ihre Antwort!
Habe anscheinend ein Verständnisproblem.
In einer Content Security Policy lege ich doch fest, welche Dateitypen von welchen Domains geladen werden dürfen. Wieso braucht man dann auch noch den Abschnitt Aktivierung der CORS bzw. wieso wird dadurch die Sicherheit erhöht, wenn dabei alle Quellen oder domains zugelassen werden???
Und Kommt der Abschnitt mit den CORS in der .htaccess Vor oder nach der CSP?
Moin,
CORS ist einfach eine wichtige Ergänzung (https://de.wikipedia.org/wiki/Cross-Origin_Resource_Sharing) zur Content Security Policy. Oder: Ein Kompromiss, wenn man die Content Security Policy nicht festlegen will, weil diese extrem kompliziert zu erstellen ist. Macht man dort einen Fehler, funktionieren Updates nicht mehr richtig usw… Der Pflegeaufwand ist also größer als der Sicherheitsgewinn.
Genervt? Ok, da steht zwar der Absatz
Header append Vary: Accept-Encoding
aber das ist jetzt nicht die Antwort auf meine Frage bzw. eine Erklärung, warum sich Google Google Pagespeed Insights im Bereich “Statische Inhalte mit einer effizienten Cache-Richtlinie bereitstellen” immer noch über Woff2-Dateien beschwert, aber gut. Frag ich halt jemand anders.
Ich verfolge deine spitzenmäßige .htaccess-Vorlage seit Jahren und bin wirklich froh darum! Gerade in Verbindung mit Autoptimize und Cache Enabler eine super Performance-Turbo!
Eine Frage habe ich jedoch: Warum fehlt in Abschnitt „4 – Dateien komprimieren und cachen“ im Bereich Media Files „jpg“? Sollte das nicht unter Zeile 44 als
ExpiresByType image/jpg „access plus 1 month“
stehen?
Noch ist jpg ja das am weitesten verbreitete Bildformat. 🙂
Moin,
nein, da soll exakt stehen, was da steht:-) Das umfasst neben
.jpegauch.jpgDateien.Interessant, dann wird quasi JPG, jpeg, jpg usw. als ein Summs betrachtet?
Dachte nur weil mir Google Pagespeed Insights im Bereich „Statische Inhalte mit einer effizienten Cache-Richtlinie bereitstellen“ immer noch diverse jpg-Bilder anmäkelt.
Gleiches gilt für woff2-Schriften. Fehlt da vielleicht in Zeile 72 nicht das hier:
ExpiresByType font/woff2 „access plus 1 month“
Vielleicht schaust Du einfach mal in die
.htaccessDatei am Ende des Artikels hinein, wie von mir im Beitrag empfohlen? Bitte also zuerst lesen und dann was dazu sagen.WOWW
Ich danke dir, ich war auf der Suche für ein Problem, da eine Webseite von Mexiko aus nicht erreichbar war (403 Forbidden). Immer noch ohne Erfolg. Jedoch habe mir erlaubt ein paar Teile deiner Vorlage zu nutzen und jetzt saußt die Page auch in anderen Ländern wo teils noch 3G Verbindung als perfekt angesehen werden darf, super flott durchs Netzt. Das eine „noch“ nicht gelöst, aber was anderes dafür optimiert.
Danke Dir dafür.
Hallo Stefan,
schön, dass ich Dir helfen konnte:-) Und danke für Deinen Kommentar.
Danke Dir 🙂
Ich habe diese htaccess Datei nun auf meinem Blog laufen. Sieht bislang recht schick aus alles und läuft schneller. Ist denn da eigentlich mein Cache-Plugin überflüssig? Danke schon mal und VG
Hallo Iris,
nein, das Cache-Plugin ist ebenfalls sehr wichtig.
Hat jemand schon Erfahrung mit bmbfotos.com gesammelt ? meine Fotos werden einfach nicht entfernt! über 10 meiner Webseiten werden dort angezeigt
Image Traffic Verlust -60% schrecklich!
LG: Frank
Hallo Andreas,
danke für die gute Zusammenfassung!
Eine Frage und einen Vorschlag hab ich:
Warum ist archive.org für dich als User Agent Bot problematisch? Das ist doch ein guter Dienst…
Und ein Vorschlag als Zusatzoption für die Headers als Erinnerung als Terry Prattchet 🙂
Hi xwolf,
grundsätzlich wäre archive.org ein toller Dienst, wenn er beim crawlen der Website nicht so viel Server-Kapazität beanspruchen würde. Genau deshalb hat Jeff Starr (https://perishablepress.com/6g/) den Dienst in seiner 6G-Firewall als „Bad Bot“ gekennzeichnet.
Vielen Dank für die Aktualisierung. Zwei kleine Hinweise und eine Frage:
Zeile 36 – ein „t“ zu viel 😉
… because Let’s Encrypt ist using .well-known => is using
Zeile 351 falsche Zeilennummer
IMPORTANT: Change »?domain\« in line 332 to your domain name
steht in Zeile 361, da wurde wohl nachträglich noch was eingefügt
——
Ich möchte ein Redirect von statischen URLs wie *.html zu WordPress-URLs einrichten (also einfach nur ein / statt .html) und nicht alle Seiten einzeln per Redirect 301 auflisten. Der folgenden Schnippsel, den ich bei Stack Overflow gefunden habe, erweitert den Standard-WordPress. Ist das deiner Meinung nach okay? Und harmoniert das mit deiner .htaccess?
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule (.+)\.html?$ http://www.example.com/$1/ (http://www.example.com/$1/) [R=301,L]
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Danke für deine Expertenblick auf den Schnippsel 😉
Hallo Peter,
Danke Dir für die Fehlermeldung, ich habe das nun korrigiert. Die Erweiterung der WordPress-Regeln dürfte kein Problem sein. Das betrifft die anderen Bereiche ja nicht.
Gern geschehen, und danke für die schnelle Antwort!
Ich habe jetzt doch alle manuell umgestellt, denn es gab letztlich doch zu viele Ausnahmen von der Regel 🙂
Hallo Andreas,
tolle Arbeit, danke für diesen Beitrag! Bei mir scheint der Abschnitt „Ultimate hotlink protection“ nicht zu funktionieren. Meine Domain lautet „https://monz.photos“. Ich habe nun „monz.photos“ eingetragen. Wahrscheinlich passt die verwendete Regex ehjer für *.de-Domains? Ich bekomme keine Bilder mehr angezeigt, wenn dieser Absatz drin ist 😉 Hast Du eine Idee?
Hallo Suitbert,
auf die Schnelle fällt mir da auch keine Lösung ein. Eigentlich sollte es auch mit anderen Domain-Endungen funktionieren. .com und .net zum Beispiel funktionieren problemlos.
Guten Tag,
vielen Dank, dass ich diese hervorragende htaccess veröffentlicht haben!
Vieles habe ich noch nicht gewusst und werde es nun einsetzen.
Ein paar Fragen habe ich dazu jedoch:
bei den folgenden drei Zeilen gibt es Unterschiede bevor die verschiedenen Dateitypen aufgezählt werden. Also ich meine bei manchen steht ein \ vor der Auflistung, bei einer Zeile nicht und bei einer anderen Zeile sind es gleich zwei \ .
Ist es egal, ob kein \ oder ein \ oder gleich zwei \\ ?
Bisher war mein Wissensstand, dass WOFF2-Dateien schon komprimiert sind und nicht mehr mit GZIP komprimiert werden müssen bzw. dass das sinnlos ist. Ist das korrekt?
Hallo Sabine,
an dieser
.htaccessist nichts sinnlos, sondern eine jahrelange Entwicklung zu einem Optimum. Nur so, wie sie ist, erzielt sie in Verbindung mit Autoptimize und Cache Enabler Ladezeiten, die zum Teil doch unter einer halben Sekunde liegen.O.k., alles klar. Danke für Ihre Antwort!
Die .htacccesa ist echt Super. Vielen Dank hierfür.
Leider scheint sie aber Blogger Software wie MarsEdit auszuschliessen obwohl ich das
xmlrpc ausgeklammert habe.
Eine Idee?
Hallo Andy,
kommentiere mal im Bereich »HTTP Security Header« den Block mit
Header set Referrer-Policy "no-referrer"aus. Das könnte das Problem beheben.Hallo Andreas,
danke für den tollen Artikel! Leider habe ich das Problem, dass Google PageSpeed immer noch behauptet ich sollte die .css und .js Dateien komprimieren!?
Hast Du zufällig eine Idee wo es hackt??
Danke für Deine Hilfe!
Manfred
Hallo Manfred,
ich würde auf externe Dateien tippen, wie zum Beispiel das Analytics.js von Google. Davon abgesehen solltest Du keinesfalls Google PageSpeed Insights nutzen. Siehe dieser Artikel hier: https://seoagentur-hamburg.com/2498/ (https://seoagentur-hamburg.com/2498/)
Genau diese Kombination hatte ich schonmal – war auf meiner Seite mit Pingdom gemessen mehr als 20% langsamer als WP-Rocket…
(Hängt vielleicht auch davon ab was man an Skripten etc. auf seiner Seite hat, bin da eher schlank unterwegs)
Werde dem Ganzen aber demnächst an einem regnerischen Wochenende nochmal eine Chance geben, entwickelt sich ja alles weiter. 🙂
Hallo Andreas, super Anleitung!
Habe einige Sicherheitselemente bei mir eingebaut. Bei den Performance-Elementen habe ich festgestellt dass die sich die Komprimierungseinstellungen nicht so gut mit dem WP-Plugin WP-Rocket vertragen. Da ist bei mir die Ladezeit sogar gestiegen. Werde aber in Kürze auch mal einen Versuch ohne WP-Rocket und nur mit den htaccess-Einstellungen machen. Mal sehen was dann tatsächlich schneller ist. Wäre ja um so besser wenn man noch ohne Plugin die gleiche oder sogar eine bessere Performance erreichen kann 🙂
Hi Thomas,
deaktiviere mal WP-Rocket und benutze stattdessen Autoptimize (https://de.wordpress.org/plugins/autoptimize/) zur Minimierung der CSS-/JavaScript-Dateien und zum Cachen Cache Enabler (https://de.wordpress.org/plugins/cache-enabler/).
Dann wirst Du sehen, was wahrer Speed ist. Und messen kannst Du es dann auch:-)
Guten Abend,
harmonieren, die beiden angesprochenen Plugins, wenn ich die ganze o.g. htaccess-Datei nutze?
Oder muss ich da im Cache-Abschnitt was anpassen.
mfg
Daniel
Hi Daniel,
nein, Du musst nichts anpassen. Das sollte so einwandfrei funktionieren.
Besten Dank!
Immer gern!
Hallo Andreas,
Danke natürlich erst mal für die tolle Arbeit!
Ich musste meinen Blok komplett neu aufsetzen und habe gleich mal deine htaccess verwendet, musste jedoch feststellen, dass nun keine Bilder mehr an mobile Endgeräte ausgeliefert werden.
Blockt die htaccess irgendwie den Zugriff auf die responsive option meines Avada themes?
Wenn ich die htaccess nicht verwende, bekomme ich Bilder geladen.
Bitte um Hilfe 😀
Danke schon mal
Hi Daniel,
es kann auch sein, dass Du den
No-Referrer-Headerauskommentieren musst. Probiere es aus. Es liegt auf jeden Fall nicht an der.htaccessDatei, denn die läuft fehlerfrei auf mittlerweile über 380 Websites. Könnte in Deinem Fall auch ein Kompatibilitätsproblem mit einem Plugin sein, darauf tippe ich mal ganz stark.Z.B. Ein Caching-Plugin oder ähnliches.
Hallo Andreas,
ich habe eine Frage zu 1 – Garantierte HTTP zu HTTPS Umleitung:
Ich habe den Code eingebaut, damit aber kein Ergebnis erzielt. Links wie „http://www.bauernhof.net/category/tiere/“ rufen die Startseite des Auftritts auf.
Ich weiß nicht wo der Fehler liegt bzw. ich ansetzen kann. Vielleicht hast du ja einen Tip, wo ich nachschauen muss. Ich verwende zum Caching das Plugin WP-Rocket, dass auch in die htacsess schreibt.
Vielen Dank
Hallo Bernhard,
zur Fehlersuche würde ich definitiv WP-Rocket deaktivieren. Danach kannst Du es nochmal testen. Wenn es nicht funktioniert, kann da auch irgendwo ein 301-Redirect für genau diese URL existieren. Ich vermute das ganz stark, weil andere Links von http auf https bei dir funktionieren.
Hallo Andreas,
herzlichen Dank für Deinen Tipp. Die RewriteBase musste in diesem Fall auf /kalender/ geändert werden.
Hallo Andreas,
Deine htaccess ist wirklich Klasse. Sie funktioniert einwandfrei bei:
https://oldtimer-veranstaltung.de/ (https://oldtimer-veranstaltung.de/)
aber nicht bei
https://oldtimer-veranstaltung.de/kalender/ (https://oldtimer-veranstaltung.de/kalender/) etc.
Bei dieser Webseite werden alle Links beim Anklicken auf die 404.php Seite von WP geleitet.
Wie kann ich das Problem lösen?
Beste Grüße
Michael
Hallo Michael,
gehe mal in »Einstellungen => Permalinks« und speichere sie ohne Änderungen nochmals ab. Dann sollte es wieder funktionieren.
Hallo Andreas,
danke für deine Antwort.
Denke auch, dass es an den von Dir genannten Stellen liegen könnte, habe aber von der Materie so gut wie keine Ahnung.
Nehme ich an den 4 Stellen „cgi-“ und „cgi“ einfach raus, oder gibt es einen eleganteren Weg?
RedirectMatch 403 (?i)/(=|\$&|_mm|cgi-|etc/passwd|muieblack)
RedirectMatch 403 (?i)\.(aspx?|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf)$
RedirectMatch 403 (?i)/(=|\$&|_mm|cgi-|etc/passwd|muieblack)
RedirectMatch 403 (?i)(&pws=0|_vti_|\(null\)|\{\$itemURL\}|echo(.*)kae|etc/passwd|eval\(|self/environ)
RedirectMatch 403 (?i)\.(aspx?|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf)$
Hallo Detlef,
das musst du einfach ausprobieren. Sorry, ich helfe gern, kann aber keinen kostenlosen Support anbieten.
Hallo Andreas,
rausnehmen hat geklappt.
Danke nochmals für Deine Mühe und die super .htaccess
Viele Grüße
Detlef
Hallo Andreas
ich danke Dir sehr für Deine perfekte .htaccess.
Beim versuch mit dem Mysqldumper per Perl-Cronscript automatische backups zu erstellen habe ich folgende Fehlermeldung:
You don’t have permission to access /cgi-bin/crondump.pl on this server.
Hast du eine Idee wie ich dies lösen könnte?
Lieben Dank
Detlef
Hallo Detlef,
das könnte meiner Meinung nach entweder an den HTTP-Security-Headern oder an der 6G-Firewall liegen. Oder Du hast noch weitere Einstellungen in der .htaccess getätigt.
Hallo,
ich habe fast alles übernommen, aber nach èberprüfung bsplw. durch Observatory oder webkoll erhalte ich keine besseren Bewertungen. Dann noch die Frage: bei mir stand zuerst die php Info (bin bei 1und1) bleibt die ganz Anfang? Das habe ich nämlich so gemacht,
Danke für eine Info
Claudia
Hi Claudia,
keine besseren Bewertungen zu bekommen heißt nicht, nichts Wertvolles für die Sicherheit der Website getan zu haben. Davon abgesehen ist die .htaccess nur ein Baustein im Bereich der Absicherung von WordPress.
Und bitte lösche die info.php wieder von Deinem Server nach Gebrauch. Sie ist ein Sicherheitsrisiko.
Ganz wunderbarer Artikel – vielen Dank!
Zu der Geschichte mit dem Bilderklau (hotlinking) würde ich gern ein paar Gedanken hierlassen. Wenn man Produkte verkauft, wird man möglicherweise (sicher!) wollen, dass Google & Co. diese auch in Form der Produktbilder indizieren und in den Ergebnissen anzeigen können. Man passt also ein paar Zeilen an und schon können mögliche Kunden über die entsprechenden Bildersuchen zur eigenen Webseite gelangen. Der Rest der Welt („Content-Diebe“) bleibt außen vor – fast.
Warum nur fast? Da draußen hat es merkwürdige Seiten (häufig in Form von Blogs) mit zum Teil kuriosen Domain-Namen, die offensichtlich nur den Zweck haben, wild durcheinander Bilder zu irgendwelchen Stichworten aufzulisten. Ein paar davon haben Bilder von meiner Seite per direkter Verlinkung eingebunden. Das hat mich schon immer geärgert und die paar Zeilen in der .htaccess kamen mir damals wie gerufen. Ich habe es so gelöst, dass ich ein sogenanntes „Hotlink-Bild“ anstatt der originalen Bilddatei ausliefern lasse. Funktioniert soweit.
Wenn man wie ich jedoch ohne Referrer unterwegs ist, bringt das alles natürlich nichts – das Original Bild wird anstandslos innerhalb der „fremden Umgebung“ angezeigt. Aber auch den Agents, die einen Referrer senden, kann das Bild auf der fremden Seite angezeigt werden. Nämlich dann, wenn der User von der Ergebnisseite einer Suchmaschine kommend das Bild bereits im Cache hat.
…
Hi Mario,
perfekt ist die Hotlinking-Lösung natürlich nicht. Sie soll ja auch nur verhindern, dass man Deine Bilder direkt mit Deinen Bildlinks einbindet.
Andreas, bitte nicht als (schlecht gemeinte) Kritik auffassen – Dein Artikel hier sollte für 99,9 Prozent der Webseitenbetreiber als Pflichtlektüre gelten.
Datenklau ist seit den Urzeiten des Web ein Thema und wird es (leider) immer bleiben. Ich denke, Sir Tim (Berners-Lee) hat schlicht nicht mit dem Menschen an sich und seinen guten und weniger guten Eigenschaften gerechnet.
Freue mich auf weitere spannende Beiträge!
Hi Mario,
ich hatte Deinen Kommentar auch nicht als Kritik, sondern als Nachfrage aufgefasst:-)
Hallo Andreas,
ich habe deine tolle .htaccess-Vorlage eingebunden. Da ich momentan noch an der Seite arbeite, ist diese mittels Passwortabfrage gesichert. Allerdings wird seit der Nutzung der 6G Firewall-Regeln kein Passwort mehr abgefragt und die Seite ist direkt zugänglich.
Das Problem sind die Zeilen, wo ein Anführungszeichen \“ enthalten ist (Nr.: 207, 230, 231). Laut PhpStorm sind diese Zeilen angeblich fehlerhaft (illegal/unsupported escape sequence), obwohl ein Backslash davor steht.
Hast du evtl. eine Idee wie dieses Problem behoben werden kann?
Gruß
Alex
Hi Alex,
hast Du die Firewall aus dem Gist genutzt? Ich empfehle immer die komplette .htaccess aus dem Gist ganz unten zu nutzen, weil diese Datei völlig fehlerfrei ist.
Hallo Andreas,
danke für die tolle Vorlage.
Ich wollt mal fragen, ob die Zeilen 162 – 166 überflüssig sind, da die Dateiendungen (js|css|xml|gz) ebenfalls in der FilesMatch Abfrage in Zeile 181 – 185 (js|css|xml|gz|html|woff|woff2|ttf) enthalten sind und es sonst keine weitere Unterschiede gibt.
Hi Alex,
nein, da ist nichts überflüssig. Die Datei ist genauso, wie sie ist perfekt. Änderungen wären eine Verschlimmbesserung.
Hi,
sorry, noch etwas, was ich eben vergessen habe:
Oftmals greifen ja bei WordPress verschieden Tools auf die /wp-admin/admin-ajax.php zu. Wenn ich also die /wp-admin/ komplett blocke, kommt der Passwort-Dialog dann auch manchmal im normalen Frontend hoch.
Meine Fragen nun;
1. Muss ich zwei .htaccess-Dateien erzeugen (eine im root, eine im /wp-admin/ für den Schutz der /wp-admin/ oder reicht eine?
2. Sollte man die Ausnahme der ajax-datei in den Passwortschutz integrieren, oder davor bzw. darunter separat einfügen?
VG
Hi Mike,
die /wp-admin/ nicht blocken! und die Ajax erst recht nicht. Wenn Du noch keine Probleme hast, mit dem Blocken bekommst Du sie garantiert. Dann integriere lieber die Blockliste unverändert in die .htaccess.
Sorry ich meinte auch eigentlich den Passwortschutz für die wp-login.php… da hat mir mal jemand gesagt, daß das immer nur in Verbindung mit der Freigabe der Ajax ginge, aber vielleicht war das falsch…
Hi,
danke für diese tolle Zusammenstellung!
Bin da nicht ganz so tief drin, daher meine Frage:
Macht es Sinn ab Zeile 265 noch folgende Listen zu implementieren?
http://www.wizcrafts.net/htaccess-blocklists.html (http://www.wizcrafts.net/htaccess-blocklists.html) (unten auf der Seite)
https://pastebin.com/BPRv4TDd (https://pastebin.com/BPRv4TDd) (davon Zeile 36-47)
oder wäre das über das Ziel hinaus geschossen?
Bzw. gibt es evtl. eine „bessere“ Blockliste die hier geigneter wäre?
Zweck ist eigentlich so viele Bots wie möglich (jedoch nicht Google/Bing) aus zu schließen.
VG
Hi Mike,
würde ich nicht in die .htaccess aufnehmen. Das wird irgendwann zu unübersichtlich. Ich löse das mit dem folgenden, sehr guten Plugin: https://de.wordpress.org/plugins/blackhole-bad-bots/ (https://de.wordpress.org/plugins/blackhole-bad-bots/)
Hi Andreas,
danke für die Antwort.
Nur wenn ich es als Plugin nutze, habe ich doch immer das Problem, daß der Bot schon deutlich mehr Last (durch z.B. Aufruf von WordPress, dann Abarbeitung von PHP und SQL, usw.) auf dem Server erzeugt hat, als wenn die .htaccess sofort den Zutritt verweigert…
Das war quasi der Hintergrund meiner Anfrage…
VG
Hallo Andreas,
erst einmal vielen Dank dafür, dass du die Früchte deiner .htacces-Arbeit hier veröffentlichst. So in dieser praxisorientierten Art habe ich das vorher noch nicht gesehen, und ich habe es auf meiner eigenen Website mit Erfolg umgesetzt (siehe https://pmueller.de/sicherer-und-schnellerer/ (https://pmueller.de/sicherer-und-schnellerer/)).
Insgesamt läuft alles supergut, aber in Abschnitt 9 hat der HSTS-Header Probleme verursacht:
Header set Strict-Transport-Security „max-age=15552000; includeSubDomains; preload“
Ich habe unverschlüsselte Subdomains im Einsatz, und der Parameter includeSubDomains hat bewirkt, dass man nach einem Aufruf der verschlüsselten Hauptdomain die unverschlüsselten Subdomains nicht mehr aufrufen konnte. Die Browser haben versucht, HTTPS zu erzwingen und als das nicht klappte, die Subdomains als unsicher geblockt.
Sicherlich ein Edge Case, aber nach einer Entfernung von includeSubDomains funktioniert alles wieder. Fange ich mir dadurch andere Nachteile ein? Gibt’s vielleicht noch eine elegantere Lösung?
Hallo Peter,
danke Dir für den Hinweis, da muss ich die Datei noch mal überarbeiten. Wenn Du aus der Zeile »Header set Strict-Transport-Security „max-age=15552000; includeSubDomains; preload“« die folgende machst: Header set Strict-Transport-Security „max-age=15552000“ – dann sollte es ohne Nachteile funktionieren.
Denn damit hast Du ja nur die Subdomains entfernt. Ich fürchte, dass es keine elegantere Lösung gibt, doch ich forsche mehrmals im Jahr nach neuen, besseren Lösungen. Sollte ich eine gefunden haben, maile ich Dich an.
Done. Funktioniert.
Vielleicht reicht bei deiner Überarbeitung ja ein Hinweis, dass man bei unverschlüsselten Subdomains den Parameter includeSubdomains entfernen sollte.
preload könnte man doch lassen. Das hat doch mit den Subdomains nichts zu tun, oder?
(siehe
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security))
Danke Dir für den Hinweis!
Ich überarbeite die .htaccess dann noch dementsprechend. Preload muss drin bleiben, weil es ein Sicherheits-Feature von Google ist.
Siehe: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#Preloading_Strict_Transport_Security (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security#Preloading_Strict_Transport_Security)
Hi Andreas,
vielen Dank für deine tolle Arbeit. Würde es nicht auch Sinn machen die Zugriffe auf die author Abfrage zu blocken. Habe hier immer wieder sehr viele logs.
RewriteCond %{QUERY_STRING} .*author=(.+.?) [NC]
RewriteRule (.*) /blog/?author= [NC,L,R=301]
Gruss
Christian
Hi Christian,
bei einem Mehr-Autoren-Blog ergibt das mit Sicherheit Sinn. Wenn nur ein einziger Autor vorhanden ist, dann lassen sich mit Yoast SEO die Autoren-Archive abschalten. SEO => Darstellung in Suchergebnissen => Autorenarchive deaktivieren. Dann erfolgt bei Aufruf der Autoren-ID eine 301-Weiterleitung auf die Startseite.
Hi Andreas,
ich habe den Code aus dem Gist zu entnommen und der .htaccess hinzugefügt. Allerdings sagt GTmetrix und Google Pagespeed keinen Unterschied. Es ist quasi alles beim alten. Hast du einen Tipp?
Gruß Benni
Hi Benni,
nutze jetzt mal Autoptimize (https://de.wordpress.org/plugins/autoptimize/) und Cache Enabler (https://de.wordpress.org/plugins/cache-enabler/) dazu, dann wirst Du einen riesigen Unterschied feststellen.
Hey Andreas, danke für den Tipp. Das hat schon mal sehr geholfen. Leider zeigen mir gtmetrix, wegpagetest.org und pagespeed immer noch an, dass mein gzip nicht aktiviert ist? Was kann ich hier noch tun? Viele Grüße
Kann nicht sein. Der zweite Test muss schneller sein, weil die Dateien dann im Cache sind.
Hilfe. Hallo Andreas ich bin es schon wieder.
Ich möchte gern Ultimate hotlink protection aktivieren komme aber mit der Eingabe der Domain nicht zurecht. Habe alle möglichen Versionen probiert, entweder werden keine Bilder im Blog angezeigt oder man kann sie wie bisher kopieren.
Könntest Du mir freundlicherweise hier !^https?://([^.]+\.)?domain\. [NC] eine normale domain ohne www eintragen?
Für deine Mühe bedanke ich mich im Voraus
Gruß Helmut
Unter der Überschrift »6 – Hotlink Protection gegen Bildklau« im Artikel steht doch genau, was Du tun musst.
Hi Andreas,
echt klasse Sache, dass du hier eine sichere und gut durchdachte .htaccess bereitstellst.
Nach Übernahme deiner Vorlage und entsprechenden Anpassungen (Domain, auch die Permalink Struktur Anpassung) funktionieren leider meine Bilder nicht mehr, also all die *.jpg, *.png,…werden nicht angezeigt.
So wie ich das sehe, versucht der Server nun, diese auch „gesichert“ also per https zu übertragen, was scheinbar nicht funktioniert.
Kannst Du mir ggf. weiterhelfen? Vielen Dank im Voraus!
Grüße
Alex
Hi Alex,
das kann meiner Meinung nach nur mit dem Block »Ultimate Hotlink Protection« zu tun haben. Kommentiere den einfach mal aus und schau, was passiert. Wenn es funktioniert, muss im Code https gegen http ausgetauscht werden. Und bitte: nimm den Code nur aus dem Gist, mein Plugin scheint etwas bei der Anzeige des Codes zu ändern.
Hi Andreas,
danke für den Hinweis mit dem Block, das war der richtige Anstoß.
Der Fehler lag allerdings auf meiner Seite, ich hatte aus Gewohnheit die Domain mit TLD Qualifier eingetragen und dann hat es nicht geklappt, ohne dann schon 😉
Nun klappt der Aufruf der Seite super schnell und dazu noch gut gesichert, klasse, vielen Dank und weiter so!!!
Hi Alex,
schön, dass es noch geklappt hat!
Hallo Andreas, leider funktioniert noch immer nicht alles. Wenn ich einen der letzten Beiträge anklicke, kommt Error 404 Datei oder Verzeichnis nicht gefunden. The requested URL was not found.
Auf zwei meiner Seiten passiert das. Bin Sicher das Du weißt an was das liegen könnte.
Gruß Helmut
Hi,
also erstens: die .htaccess aus dem Gist unten verwenden, nicht aus den Code-Snippets. Zweitens: keine anderen Teile in der .htaccess verwenden außer denen, die drin sind. Und zwar solange, bis es funktioniert. Drittens: Gehe zu »Einstellungen => Permalinks« und speichere Deine Permalinks so wie sie sind nochmals ab. <= WICHTIG! Funktioniert es immer noch nicht, stimmt mit der Serverkonfiguration etwas nicht. Die .htaccess läuft problemlos auf über hundert Websites.
Hallo Andreas,
vielen Dank für deine Mühe und Geduld. Das ich immer so spät antworte liegt an der Zeitverschiebung, ich lebe in Thailand. Jetzt funktioniert es, vielleicht hat das Speicher der Permalinks geholfen, es kann aber sein das der Provider gerade an dem Server was gemacht hat. Ich habe von Anfang an die htaccess aus dem Gist benutzt und auch nichts anderes eingefügt.
Gruß Helmut
@ Adreas
[…] Dann solltest Du meinen Tipp mit SecSign mal ausprobieren. […]
Danke. Gibt es denn als Abhilfe kein code-snippet? Dazu hatte ich bisher die ursprünglich von Sergej Müller entwickelte Zwei-Faktor-Authentifizierung „2-Step-Verification-master“ verwendet, welche ohne einem Smartphone auskommt und ein fünf Minuten gültiges PW an die bei der Registrierung hinterlegte E-Mailadresse sendet.
LG, Bildermann
Tipp: „2-Step-Verification-master“ liegt auf GitHub zum Herunterladen…
Hallo Andreas,
vor kurzem habe ich mir den Adminbereich mittels HTTP-Veriegelung per .htaccess und .htpasswd geschützt. Es funktioniert bestens, nur können aber meine „normalen“ Besucher PW-geschützte Seiten nicht mehr betreten, weil sie jetzt auch das vorgeschaltene Eingabeformular für die HTTP-Veriegelung sehen. Habe ich etwas vergessen?
Im voraud danke für die schnelle AW.
LG, Bildermann
Hallo!
Wenn Du wie in meiner .htaccess nur die wp-login.php mit einem HTTP-Schutz versiehst, dann sollten normale User auf Passwortgeschützte Bereiche zugreifen können. Wenn nicht, schau Dir mal das SecSign ID Plugin (https://de.wordpress.org/plugins/secsign/) näher an.
@ Andreas
Danke für die schnelle AW.
[…] …sollten normale User auf Passwortgeschützte Bereiche zugreifen können […]
Leider ist das nicht der Fall, sondern wie von mir oben beschrieben. Könnte es eventuell an der Serverkonfiguration meines Providers liegen?
Hier mal probehalber eine mit dem „supersicherem“ PW
Test
gesicherte Testseite zur Illustration: https://bildermann.de/test/ (https://bildermann.de/test/)
LG, Bildermann
Okay,
der Passwortgeschützte Bereich ruft also auch die wp-login.php auf. Dann solltest Du meinen Tipp mit SecSign mal ausprobieren.
Hallo Andreas,
eine ganz tolle Arbeit. Habe alles übernommen nur
Protect your WordPress Login with HTTP Authentification und
Ultimate hotlink protection auskommentiert, letzeres weil ich nicht weiß wie ich die Webadresse eingeben muss 🙁
Es funktioniert alles wunderbar, nur die Google Reklame die ich im Header und Footer untergebracht habe werden nicht angezeigt.
Vielleicht kannst Du mir sagen an was es liegen könnte.
Gruß Helmut
Hallo Helmut,
die Hotlink-Protection ist einfach. In Zeile 6 findest Du das Wort »domain«, das tauscht Du aus gegen Deine Domain. Ich hatte das dort genau beschrieben, was da bei mir steht. Die Google-Reklame könnte entweder an CORS oder an den Security Headern liegen. Kommentiere es einfach nach und nach mal aus…
Hallo Andreas,
vielen Dank für die schnelle Antwort. Habe die htaccess in drei Blogs eingebaut und war ganz happy.
Inzwischen hat sich ein Problem eingestellt. Meinen Blog schreibe ich mit Blogdesk. Heute konnte ich den letzten Bericht nich hochladen, es wurde ein 403 Fehler gemeldet.
Hatte die komplette htaccess übernommen, nur Ultimate hotlink protection war deaktiviert.
Jetzt habe ich nur noch The original WordPress Rewrite Rules in Betrieb und das Hochladen funktioniert wieder. Es wäre schön wenn Du mir einen Tip geben könntest an was es liegen könnte.
Gruß Helmut
Hallo Helmut,
das wird am dem Bereich »XML-RPC« liegen. Da das ein Sicherheitsrisiko ist, funktionieren die Anwendungen dieser Art nicht mehr. Schreibe also die Artikel entweder direkt in WordPress oder kommentiere den Bereich aus.
Hallo Andreas,
vielen Dank für die schnelle Antwort, das war es. Habe XML-RPC auskommentiert.
Mit WordPress direkt schreiben ist so eine Sache, bin halt Blogdesk gewöhnt. In meinem Blog sind immer sehr viele Bilder und ich bilde mir ein das ich das mit Blogdesk besser erledigen kann. Werde aber wieder einmal einen Versuch mit WordPress machen.
Vielen Dank für deine Mühe
Helmut
Schön, dass ich helfen konnte…
Bei mir werden Hintergrundbilder und teilweise die CSS nicht mehr dargestellt (https://www.naturfotografie-kruse.de (https://www.naturfotografie-kruse.de)), wenn ich Deine Datei verwende. Leider kenne ich mich zu wenig aus, um nun jeden einzelnen blog durchzugehen, der evtl- den Fehler beheben könnte 🙁
Hallo Helmut,
wenn Du das Gist am Ende des Artikels verwendest, dann muss es funktionieren. Die .htaccess ist auf Hunderten von Websites ohne jedes Problem online.
Die Zeile ‚RedirectMatch 403 (?i)/(\$(\&)?|\*|\“|\.|,|&|&?)/?$‘ aus dem Bereich Request Strings der Firewall sorgt bei mir für ein ‚Forbidden You don’t have permission to access / on this server.‘
Woran kann das liegen? Und wie – außer dem Auskommentieren – könnte man das evtl. beheben?
Hast Du die Zeile aus dem Gist kopiert oder aus meinem Code?
Die habe ich hier aus dem Code kopiert
Wenn ich das aus dem Gist kopiere, funktioniert es
Hi Marcus,
das ist eine gute Nachricht. Dann stimmt irgendetwas nicht mit meinem Code-Plugin.
Irre guter Artikel. Ich werde die htaccess ausprobieren.
Eine Frage aber dennoch: Warum haben deine Artikel keine „sprechende URL“, sondern eine Nummer?
Hallo Ralf,
danke für die Blumen. Ich hatte mir Ranking-Vorteile von der Permalink-ID versprochen, da Google inzwischen auch fast nur noch IDs nutzt. Allerdings sind die Vorteile nicht wirklich groß.
Hallo,
vielen Dank für die Arbeit und das Teilen.
Allerdings fehlt mir ein wichtiger Hinweis zu Punkt 4, der 6G-Firewall.
Da diese mir den Zugriff auf den WP Login verweigerte, habe ich etwas recherchiert und herausgefunden, dass der Code angeblich vor den WordPress eigenen Anweisungen (# BEGINN WORDPRESS … # END WORDPRESS) einzufügen ist.
Doch auch dies brachte mir den Login nicht wieder, weshalb ich folgenden Code verwendet habe:
https://lars-mielke.de/6067/umfassender-webseitenschutz-mit-der-6g-firewall-fuer-htaccess/ (https://lars-mielke.de/6067/umfassender-webseitenschutz-mit-der-6g-firewall-fuer-htaccess/)
Damit lief dann wieder alles.
Lieben Gruß,
-Björn
Edit:
Sorry, mein Fehler, ich meinte direkt von perishablepress:
https://perishablepress.com/6g/ (https://perishablepress.com/6g/)
Hi Björn,
danke für Deinen Kommentar. Dieser Fehler ist mir bisher nicht untergekommen. Ich habe die
.htaccessauf Dutzenden von Websites ohne Probleme im Einsatz.Aber dank Deines Kommentars habe ich die 6G-Firewall jetzt auf die 2018er Version aktualisiert.
Hallo Andreas,
also nachdem ich deine htaccess komplett 1zu1 übernommen habe, in der Hoffnung keine Plugins mehr fürs Caching und Security zu benötigen, war weder mein Back, noch mein Frontend erreichbar..?!
Es hieß dann immer „Umleitungsfehler“…
Grüße,
Daniel
Update: Ich habe alle Bereiche einzeln hinzugefügt und es liegt tatsächlich an Punkt 1 und Punkt 4.
Füge ich die garantierte Umleitung hinzu, sagt er mir „unendliche Umleitung“.
Füge ich die 6g Firewall hinzu, sagt er mir „no permission“
Hi Daniel,
danke für Deine wichtige Info! Die Umleitung läuft mit allen Servern, allerdings nur, wenn keine andere Umleitung der Domain aktiv ist. Das Problem hatte ich auch vor kurzem. Ich werde also die .htaccess etwas überarbeiten und einen Kommentar hinzufügen. Das die 6G-Firewall nicht funktioniert, höre ich jedoch zum ersten Mal. Da ist dann eine Direktive des Hosters aktiv, denn für die Firewall sagt er Dir einfach nur: Keine Berechtigung.
Der ist echt gut! Anstatt den WordPress mit Plugins zu versauen! Bringt garantiert super Page Speed. Danke dir!
Hallo Andreas,
ich danke für die Neuerungen der perfekten .htaccess für WordPress. Schon vorher habe ich deine Snippets verwendet, die auf Dr.Web publiziert wurden. Was ich bisher nicht in der .htaccess hatte, waren die CORS, XML-RPC und die HTTP Security Header. Gerade habe ich die .htaccess angepasst und alles läuft einwandfrei. Dann auch noch ein dickes DANKE für dein E-Book WordPress Performance. Das habe ich im April gekauft, aber leider konnte ich aus Zeitmangel noch nicht alles umsetzen/testen.
Viele Grüße
Guido
Hi Guido,
gern geschehen. Ich freue mich immer, wenn ich helfen kann.