.htaccess-Tricks und Tipps Beitragsbild.
·

.htaccess: Tricks & Regeln für ihre Website

Die Webserver-Konfigurationsdatei .htaccess ist eine der wichtigsten Dateien ihrer Website-Installation. Viel kann diese oftmals noch unterschätzte Datei leisten. Sie kann zu einem wahren Performance-Schub einer Website ebenso beitragen, wie zu erhöhter Sicherheit. Immer wieder werden WordPress-Websites gehackt, weil kein Augenmerk auf die Sicherheit der Website gelegt wird. In diesem Artikel stelle ich meine eigene .htaccess-Datei vor, die ich im Laufe der Zeit immer weiter verfeinert und optimiert habe.

Antworten auf Fragen zu .htaccess-Dateien, die wir häufig gestellt bekommen (FAQ)

RewriteCond ist eine Bedingung (Condition) in der .htaccess-Datei, die genutzt wird, um zusätzliche Anforderungen für das Ausführen einer RewriteRule festzulegen. Während RewriteRule die URL-Umschreibung definiert, wird mit RewriteCond überprüft, ob bestimmte Bedingungen erfüllt sind, bevor die Regel angewendet wird.

RewriteCond wird zusammen mit mod_rewrite verwendet, einem Modul auf Apache-Webservern, das URL-Umschreibungen ermöglicht.

Wie funktioniert RewriteCond?

RewriteCond überprüft, ob eine bestimmte Bedingung erfüllt ist, bevor eine RewriteRule ausgeführt wird. Du kannst damit z. B. steuern, dass nur Benutzer von bestimmten IP-Adressen, Referrer-Seiten oder Domains weitergeleitet werden, oder dass bestimmte Aktionen nur unter spezifischen Umständen stattfinden.

Syntax:

RewriteCond TestString VergleichsOperator Bedingung
  • TestString: Hier wird ein Wert geprüft, z. B. eine Umgebungsvariable wie %{HTTP_USER_AGENT} oder %{REQUEST_URI}.
  • VergleichsOperator: Ein Operator, der angibt, wie der TestString mit der Bedingung verglichen wird (z. B. = für gleich, -d für Verzeichnisse).
  • Bedingung: Der Wert oder die Variable, die du prüfen möchtest, z. B. eine bestimmte IP-Adresse oder URL.

Wichtige Umgebungsvariablen für RewriteCond:

  • %{HTTP_HOST}: Prüft den Hostnamen (z. B. www.example.com).
  • %{REQUEST_URI}: Prüft die angeforderte URL (Pfad und Query-String).
  • %{HTTP_REFERER}: Prüft die Referrer-URL (die Seite, von der der Nutzer kam).
  • %{HTTP_USER_AGENT}: Prüft den User-Agent (Browser des Nutzers).

Beispiel: Nur eine bestimmte Domain umleiten

Angenommen, du möchtest nur Nutzer, die von der Domain example.com kommen, auf eine bestimmte Seite weiterleiten. In diesem Fall würdest du eine RewriteCond verwenden, die den HTTP_REFERER überprüft, bevor die RewriteRule angewendet wird.

Code-Beispiel:

RewriteEngine On

# Bedingung: Wenn der Nutzer von example.com kommt
RewriteCond %{HTTP_REFERER} ^https?://(www\.)?example\.com [NC]

# Regel: Leite auf neue-seite.html um, wenn die Bedingung erfüllt ist
RewriteRule ^.*$ /neue-seite.html [R=302,L]

Erklärung:

  • RewriteCond %{HTTP_REFERER} ^https?://(www.)?example.com [NC]: Diese Zeile prüft, ob der Referrer (die vorherige Seite, von der der Nutzer kam) example.com ist. Das ^ gibt den Anfang der URL an, und (www\.)? macht das „www.“ optional. Der Parameter [NC] bedeutet, dass der Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung erfolgt (case-insensitive).
  • RewriteRule ^.*$ /neue-seite.html [R=302,L]: Diese Regel leitet alle Anfragen (^.*$ bedeutet „jede URL“) auf neue-seite.html um. Der Statuscode 302 zeigt eine temporäre Umleitung an, und [L] bedeutet, dass dies die letzte Regel ist, die in der .htaccess-Datei ausgeführt wird, wenn die Bedingung zutrifft.

Weitere Anwendungsbeispiele für RewriteCond:

IP-Adresse blockieren:

RewriteEngine On

# Bedingung: Wenn die IP-Adresse 123.456.789.000 ist
RewriteCond %{REMOTE_ADDR} ^123\.456\.789\.000$

# Regel: Zeige eine Fehlermeldung
RewriteRule ^ - [F]

Hier blockierst du alle Zugriffe von der IP-Adresse 123.456.789.000 und zeigst einen 403 Forbidden-Fehler an.

SSL erzwingen (HTTP zu HTTPS umleiten):

RewriteEngine On

# Bedingung: Wenn der Aufruf nicht über HTTPS erfolgt
RewriteCond %{HTTPS} !=on

# Regel: Leite auf die HTTPS-Version der Seite um
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
  1. Wenn eine Seite ohne SSL (HTTPS) aufgerufen wird, wird der Besucher automatisch auf die sichere Version umgeleitet.

Nützliche Vergleichsoperatoren:

  • -d: Prüft, ob der angegebene Pfad ein Verzeichnis ist.
RewriteCond %{REQUEST_FILENAME} -d

(Diese Bedingung prüft, ob die angeforderte URL zu einem Verzeichnis gehört.)

-f: Prüft, ob die angegebene Datei existiert.

RewriteCond %{REQUEST_FILENAME} -f

(Diese Bedingung prüft, ob die angeforderte Datei existiert.)

!=: Prüft, ob zwei Werte ungleich sind.

RewriteCond %{HTTPS} !=on
  • (Diese Bedingung prüft, ob der HTTPS-Status „off“ ist.)

Tipps für RewriteCond:

  • Verwende RewriteCond, wenn du Bedingungen für URL-Umschreibungen festlegen musst, um spezifische Anfragen zu bearbeiten.
  • Vergiss nicht, dass RewriteCond immer vor der zugehörigen RewriteRule stehen muss, da sie die Bedingungen für die nachfolgende Regel festlegt.

Was ist eine .htaccess-Firewall?

Eine Firewall ist in der Regel ein System, das den Datenverkehr überwacht und kontrolliert, um unerwünschten Zugriff auf eine Website oder ein Netzwerk zu verhindern. Mit einer .htaccess-Firewall kannst du grundlegende Firewall-Funktionen wie das Sperren oder Zulassen bestimmter IP-Adressen oder IP-Bereiche direkt auf deinem Apache-Webserver umsetzen.

Dies ist besonders nützlich, um bösartigen Traffic zu blockieren oder den Zugriff auf sensible Bereiche deiner Website nur für bestimmte IP-Adressen zu erlauben.

Wie funktioniert eine htaccess-basierte Firewall?

Mit der .htaccess-Datei kannst du Anfragen von bestimmten IP-Adressen sperren, indem du die Direktiven allow und deny verwendest. Außerdem kannst du Regeln definieren, die basierend auf anderen HTTP-Headern wie dem User-Agent oder der Referrer-URL arbeiten.

Beispiel: IP-Adressen blockieren

Wenn du verdächtigen Traffic von einer bestimmten IP-Adresse siehst, kannst du diese Adresse blockieren, sodass die betreffende Person oder Bot keinen Zugriff mehr auf deine Website hat.

Code-Beispiel:

Order Allow,Deny
Deny from 123.45.67.89
Allow from all

Erklärung:

  • Order Allow,Deny: Gibt die Reihenfolge an, in der die Zugriffskontrollen angewendet werden. Zuerst wird „Allow“ (erlauben) auf alle angewendet, dann „Deny“ (verweigern) für die spezifischen IP-Adressen.
  • Deny from 123.45.67.89: Diese Anweisung blockiert alle Anfragen von der IP-Adresse 123.45.67.89.
  • Allow from all: Dies erlaubt allen anderen Zugriff auf die Website.

Beispiel: Bestimmte IP-Adressen erlauben und alle anderen blockieren

In diesem Beispiel wird nur der Zugriff von bestimmten IP-Adressen erlaubt. Alle anderen Besucher erhalten einen 403 Forbidden-Fehler.

Code-Beispiel:

Order Deny,Allow
Deny from all
Allow from 203.0.113.0
Allow from 198.51.100.0

Erklärung:

  • Order Deny,Allow: Diese Reihenfolge bedeutet, dass standardmäßig der Zugriff verweigert wird, es sei denn, eine IP-Adresse wird explizit erlaubt.
  • Deny from all: Alle IP-Adressen werden standardmäßig blockiert.
  • Allow from 203.0.113.0 und 198.51.100.0: Nur diese beiden IP-Adressen haben Zugriff.

Beispiel: Einen gesamten IP-Bereich blockieren

Wenn du einen ganzen IP-Bereich blockieren möchtest, kannst du dies ebenfalls mit .htaccess tun. Dies ist besonders nützlich, wenn du bösartigen Traffic von einem bestimmten Netzwerk blockieren willst.

Code-Beispiel:

Order Allow,Deny
Deny from 123.45.67.0/24
Allow from all

Erklärung:

  • Deny from 123.45.67.0/24: Blockiert alle IP-Adressen im Bereich von 123.45.67.0 bis 123.45.67.255.
  • Allow from all: Erlaubt allen anderen IPs weiterhin den Zugriff.

Beispiel: Bestimmte Länder blockieren

Es ist auch möglich, den Zugriff auf deine Website basierend auf dem Herkunftsland der IP-Adresse zu blockieren. Dies wird allerdings nicht direkt von .htaccess unterstützt, sondern erfordert die Verwendung von GeoIP-Datenbanken. Du kannst GeoIP-basierte Anweisungen in deine .htaccess-Datei einfügen, um bestimmte Länder zu blockieren.

Voraussetzung: Die GeoIP-Datenbank muss auf dem Server installiert sein.

Code-Beispiel:

SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

Erklärung:

  • SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry: Blockiert alle Anfragen aus China.
  • SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry: Blockiert alle Anfragen aus Russland.
  • Deny from env=BlockCountry: Verweigert den Zugriff für alle Anfragen, die der Umgebung BlockCountry entsprechen.

Weitere Sicherheitstipps mit .htaccess-Firewall-Regeln

  1. Zugriff auf sensible Dateien verhindern: Um den Zugriff auf wichtige Dateien wie .htaccess, .htpasswd oder Konfigurationsdateien zu verhindern, kannst du eine Regel hinzufügen, die diese Dateien für die Öffentlichkeit unzugänglich macht.

Beispiel:

<FilesMatch "^\.ht">
Order Allow,Deny
Deny from all
</FilesMatch>

Dies verhindert den Zugriff auf alle Dateien, die mit einem Punkt (.) beginnen, wie .htaccess und .htpasswd.

Schutz vor Brute-Force-Angriffen: Du kannst eine .htaccess-Firewall verwenden, um Brute-Force-Angriffe auf Seiten wie /wp-login.php (WordPress-Anmeldebildschirm) zu verhindern, indem du nur bestimmte IP-Adressen den Zugriff erlaubst.

Beispiel:

<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from 123.45.67.89
Allow from 203.0.113.0
</Files>

Nur die IP-Adressen 123.45.67.89 und 203.0.113.0 haben hier Zugriff auf die Anmeldeseite.

    Ein htaccess-Tester ist ein Tool, das verwendet wird, um die Funktionalität und Syntax einer .htaccess-Datei zu überprüfen, bevor sie auf einem Webserver eingesetzt wird. Da Fehler in der .htaccess-Datei leicht zu einem 500 Internal Server Error führen können, ist es sinnvoll, die Datei vorab auf Fehler zu testen.

    Mit einem htaccess-Tester kannst du:

    • Prüfen, ob deine Rewrite-Regeln korrekt funktionieren.
    • Sicherstellen, dass deine Syntax keine Fehler enthält.
    • Überprüfen, ob Zugriffssteuerungen (z. B. das Blockieren von IP-Adressen) wie gewünscht funktionieren.
    • Fehler schnell erkennen und beheben, bevor du die Datei auf den Server hochlädst.

    Warum solltest du einen htaccess-Tester verwenden?

    Die .htaccess-Datei beeinflusst direkt das Verhalten deines Webservers, und ein kleiner Syntaxfehler kann dazu führen, dass deine gesamte Website nicht mehr erreichbar ist. Ein htaccess-Tester hilft dir, diese Probleme zu vermeiden, indem du die Regeln vorab simulierst und so mögliche Fehlerquellen erkennst, ohne die Datei auf dem Live-Server anzuwenden.

    So testest du deine .htaccess-Datei online:

    Es gibt mehrere kostenlose Online-Tools, mit denen du deine .htaccess-Datei testen kannst. Diese Tools bieten dir die Möglichkeit, deine RewriteRules, RewriteCond und andere Regeln in einer sicheren Testumgebung auszuprobieren.

    Ein Beispiel für einen htaccess-Tester ist htaccess.madewithlove.com. So kannst du ihn verwenden:

    1. Gehe auf die Seite: htaccess.madewithlove.com
    2. Füge deinen Code ein: Kopiere deine .htaccess-Regeln in das Textfeld des Testers.
    3. Teste den Code: Drücke den „Testen“-Button, um die Ausführung deiner Regeln zu simulieren.

    Das Tool zeigt dir an, ob Fehler vorliegen, und gibt dir Hinweise darauf, wie du sie beheben kannst.

    Beispiel für eine fehlerhafte .htaccess-Datei:

    RewriteEngine On
    RewriteRule ^test\.html$ /testseite.html [R=301,L]

    Fehler: Wenn du in diesem Beispiel einen Tippfehler in der Regel hast, wie etwa ein fehlendes Zeichen, kann dies zu einem Serverfehler führen.

    Korrektur:

    RewriteEngine On
    RewriteRule ^test\.html$ /testseite.html [R=301,L]

    Das Tool erkennt solche Fehler und zeigt dir die richtige Syntax an.

    Manuelles Testen auf deinem Server:

    Neben Online-Tools kannst du auch manuell auf deinem Server testen, ob deine .htaccess-Datei funktioniert. Der einfachste Weg ist, die Datei schrittweise zu testen:

    1. Backup erstellen: Erstelle immer ein Backup deiner aktuellen .htaccess-Datei, bevor du Änderungen vornimmst.
    2. Teständerung anwenden: Füge eine Änderung in der .htaccess hinzu und lade die Datei auf deinen Server hoch.
    3. Test durchführen: Lade die betroffene Seite in deinem Browser und prüfe, ob die Regeln wie erwartet funktionieren.
    4. Fehler beheben: Falls du einen 500 Internal Server Error erhältst, überprüfe die Logs deines Servers. Die meisten Webserver (insbesondere Apache) protokollieren htaccess-Fehler in den error logs. Diese Logs findest du normalerweise unter /var/log/apache2/error.log oder in der Verwaltungsoberfläche deines Webhosters.

    Fehlerquellen in der .htaccess-Datei:

    Die häufigsten Fehler, die bei der Arbeit mit .htaccess auftreten, sind:

    • Syntaxfehler: Falsche Syntax wie vergessene Klammern, fehlende Leerzeichen oder falsche Befehle.
    • Regelkonflikte: Widersprüchliche Regeln oder Bedingungen, die gleichzeitig ausgeführt werden.
    • Serverfehler: Der Webserver unterstützt möglicherweise nicht alle Befehle in der .htaccess-Datei (z. B. wenn bestimmte Module nicht aktiviert sind).

    Beispiel: Typische RewriteRule, die getestet werden kann

    Nehmen wir an, du möchtest eine Weiterleitung von /alte-seite.html auf /neue-seite.html einrichten und sicherstellen, dass die Regel korrekt funktioniert.

    RewriteEngine On
    RewriteRule ^alte-seite\.html$ /neue-seite.html [R=301,L]

    Du kannst diese Regel mit einem htaccess-Tester überprüfen, um sicherzustellen, dass die Syntax korrekt ist und die Umleitung wie erwartet funktioniert.

    Weitere Online-Tools zum Testen von .htaccess:

    • htaccess.madewithlove.com – Ein einfacher und leicht verständlicher htaccess-Tester.
    • htaccess.tester.io – Ein weiteres praktisches Tool, um Rewrite-Regeln zu testen.
    • htaccess-check.com – Ein Tool, das Syntaxfehler in deiner .htaccess-Datei aufdeckt.

    Tipps für das Testen der .htaccess-Datei:

    1. Immer Schritt für Schritt vorgehen: Teste nach jeder Änderung, ob die Website noch wie erwartet funktioniert.
    2. Nutze die Error Logs deines Servers: Viele Probleme werden in den error logs deines Servers protokolliert, was dir dabei hilft, den genauen Fehler zu identifizieren.
    3. Backup erstellen: Bevor du große Änderungen vornimmst, speichere immer eine Kopie der aktuellen .htaccess-Datei.

    In WordPress wird die .htaccess-Datei vor allem für die Verwaltung von Permalinks und für grundlegende serverseitige Funktionen genutzt. Die Datei befindet sich normalerweise im Root-Verzeichnis deiner WordPress-Installation und steuert, wie URLs behandelt und Umleitungen ausgeführt werden.

    Standardmäßig wird die .htaccess-Datei von WordPress erstellt und verwaltet, wenn du die Permalink-Struktur änderst. Allerdings kannst du die Datei manuell bearbeiten, um zusätzliche Funktionen hinzuzufügen, z. B. für:

    • Sicherheitsmaßnahmen
    • Caching
    • URL-Weiterleitungen

    Hier ist das Standard-Layout der .htaccess-Datei, das WordPress erstellt:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    Diese Regeln sorgen dafür, dass alle Anfragen, die keine existierenden Dateien oder Verzeichnisse betreffen, auf index.php umgeleitet werden. So kann WordPress die Anfragen verarbeiten und die entsprechenden Seiten, Beiträge oder Archivinhalte anzeigen.

    Häufige Anpassungen der WordPress .htaccess-Datei

    Während WordPress die .htaccess-Datei automatisch für dich generiert, gibt es einige häufige Anpassungen, die du vornehmen kannst, um zusätzliche Funktionen zu aktivieren.

    Beispiel 1: Sicherheitsregeln in der WordPress-htaccess

    Sicherheit ist ein wichtiger Aspekt jeder Website, und mit .htaccess kannst du grundlegende Sicherheitsmaßnahmen hinzufügen, um deine WordPress-Installation zu schützen.

    Blockieren des Zugriffs auf die wp-config.php:

    Die wp-config.php-Datei enthält sensible Informationen wie Datenbankzugangsdaten. Mit der folgenden Regel kannst du den Zugriff auf diese Datei für die Öffentlichkeit sperren:

    <files wp-config.php>
    order allow,deny
    deny from all
    </files>

    Verhindern des Zugriffs auf die .htaccess-Datei selbst:

    Da die .htaccess-Datei kritische Anweisungen für den Server enthält, solltest du sie ebenfalls vor unberechtigtem Zugriff schützen:

    <files .htaccess>
    order allow,deny
    deny from all
    </files>

    Beispiel 2: Browser-Caching aktivieren

    Browser-Caching kann die Ladezeit deiner WordPress-Seite erheblich verbessern. Mit den folgenden Regeln kannst du steuern, wie lange bestimmte Dateitypen im Browser-Cache gespeichert werden sollen:

    # BEGIN Caching
    <IfModule mod_expires.c>
        ExpiresActive On
        ExpiresByType image/jpg "access 1 year"
        ExpiresByType image/jpeg "access 1 year"
        ExpiresByType image/gif "access 1 year"
        ExpiresByType image/png "access 1 year"
        ExpiresByType text/css "access 1 month"
        ExpiresByType application/pdf "access 1 month"
        ExpiresByType text/x-javascript "access 1 month"
        ExpiresByType application/x-shockwave-flash "access 1 month"
        ExpiresByType image/x-icon "access 1 year"
        ExpiresDefault "access 2 days"
    </IfModule>
    # END Caching

    Diese Regeln bewirken, dass bestimmte Dateitypen wie Bilder, CSS-Dateien und JavaScript-Dateien für einen bestimmten Zeitraum (z. B. 1 Jahr für Bilder) im Browser des Nutzers zwischengespeichert werden, was die Ladezeiten verbessert.

    Falls deine .htaccess-Datei fehlt oder du sie gelöscht hast, kannst du eine neue erstellen:

    Erstelle eine neue Datei: Öffne einen Texteditor wie Notepad oder Sublime Text und erstelle eine neue Datei.

    Füge den Standard-WordPress-Code ein:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress
    • Speichere die Datei als .htaccess (ohne Dateiendung).
    • Lade die Datei in das Root-Verzeichnis deiner WordPress-Installation hoch.

    Alternativ kannst du auch die Permalink-Einstellungen in deinem WordPress-Dashboard ändern (oder einfach auf „Speichern“ klicken). Dadurch generiert WordPress automatisch eine neue .htaccess-Datei.

    Sicherheit ist ein wichtiger Aspekt jeder Website, und mit .htaccess kannst du grundlegende Sicherheitsmaßnahmen hinzufügen, um deine WordPress-Installation zu schützen.

    Blockieren des Zugriffs auf die wp-config.php:

    Die wp-config.php-Datei enthält sensible Informationen wie Datenbankzugangsdaten. Mit der folgenden Regel kannst du den Zugriff auf diese Datei für die Öffentlichkeit sperren:

    <files wp-config.php>
    order allow,deny
    deny from all
    </files>

    Verhindern des Zugriffs auf die .htaccess-Datei selbst:

    Da die .htaccess-Datei kritische Anweisungen für den Server enthält, solltest du sie ebenfalls vor unberechtigtem Zugriff schützen:

    <files .htaccess>
    order allow,deny
    deny from all
    </files>

    Browser-Caching kann die Ladezeit deiner WordPress-Seite erheblich verbessern. Mit den folgenden Regeln kannst du steuern, wie lange bestimmte Dateitypen im Browser-Cache gespeichert werden sollen:

    # BEGIN Caching
    <IfModule mod_expires.c>
        ExpiresActive On
        ExpiresByType image/jpg "access 1 year"
        ExpiresByType image/jpeg "access 1 year"
        ExpiresByType image/gif "access 1 year"
        ExpiresByType image/png "access 1 year"
        ExpiresByType text/css "access 1 month"
        ExpiresByType application/pdf "access 1 month"
        ExpiresByType text/x-javascript "access 1 month"
        ExpiresByType application/x-shockwave-flash "access 1 month"
        ExpiresByType image/x-icon "access 1 year"
        ExpiresDefault "access 2 days"
    </IfModule>
    # END Caching

    Diese Regeln bewirken, dass bestimmte Dateitypen wie Bilder, CSS-Dateien und JavaScript-Dateien für einen bestimmten Zeitraum (z. B. 1 Jahr für Bilder) im Browser des Nutzers zwischengespeichert werden, was die Ladezeiten verbessert.

    Wenn du SSL auf deiner WordPress-Seite aktiviert hast, kannst du die .htaccess-Datei so anpassen, dass alle HTTP-Anfragen automatisch auf HTTPS umgeleitet werden.

    Code-Beispiel:

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    Erklärung:

    R=301 sorgt dafür, dass es sich um eine permanente Weiterleitung handelt, was für SEO wichtig ist.

    Diese Regeln überprüfen, ob die Seite über HTTPS aufgerufen wird. Falls nicht, wird die Anfrage auf die HTTPS-Version der Seite umgeleitet.

    Hotlinking tritt auf, wenn andere Websites deine Bilder direkt einbinden, wodurch deine Bandbreite belastet wird. Mit der folgenden .htaccess-Regel kannst du Hotlinking verhindern und sicherstellen, dass deine Bilder nur auf deiner eigenen Website angezeigt werden.

    Code-Beispiel:

    RewriteEngine On
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?deine-domain\.com [NC]
    RewriteRule \.(jpg|jpeg|png|gif)$ - [F,NC,L]
    • Diese Regeln verhindern, dass andere Websites direkt auf deine Bilddateien (JPG, PNG, GIF) zugreifen.
    • Besucher, die versuchen, deine Bilder von anderen Domains zu laden, sehen stattdessen einen 403 Forbidden-Fehler.

    Falls du schädlichen Traffic von bestimmten IP-Adressen feststellst, kannst du diese blockieren, um den Zugriff auf deine WordPress-Seite zu verhindern.

    Code-Beispiel:

    <Limit GET POST>
    order allow,deny
    deny from 123.45.67.89
    allow from all
    </Limit>
    • Die IP-Adresse 123.45.67.89 wird blockiert und erhält keinen Zugriff mehr auf die Seite.
    • Allow from all stellt sicher, dass alle anderen Nutzer Zugriff haben.
    • Allow from all stellt sicher, dass alle anderen Nutzer Zugriff haben.

    Die Tricks

    Die Vorbereitung

    Zuerst einmal muss die Datei gefunden werden. Der folgende Screenshot zeigt, wo die Datei liegt. Regelmäßig sollte sie sich im Hauptverzeichnis ihrer WordPress-Installation finden lassen, also dort, wo die Ordner wp-content, wp-admin usw. liegen.

    Der Speicherort der .htaccess-Datei

    Ganz wichtig ist es, vor dem Bearbeiten der .htaccess Datei ein Backup selbiger zu erstellen. Dazu kopiere die Datei einfach in einen neuen/anderen Ordner.

    Ja, ich möchte professionellen Support für meine WordPress-Website

    Das brauche ich

    Eine Besonderheit unter Mac OS X: Der Mac sieht alle Dateien mit einem Punkt vor dem Dateinamen als Systemdateien an, also auch die .htaccess. Das bedeutet, dass er sie ausblendet, sobald man sie etwa auf den Desktop gezogen hat. Abhilfe schafft hier das kleine Dashboard Widget Hidden Files, mit dem man nach Belieben die versteckten Dateien ein- und wieder ausblenden kann.

    Nach jeder Änderung an der .htaccess-Datei muss ein Refresh des Browsers durchgeführt werden, um feststellen zu können, ob die Webseite noch erreichbar ist. Schon bei nur einem fehlerhaften Zeichen wird die betreffende Webseite nicht mehr angezeigt werden. Die .htaccess ist sehr empfindlich. Sollte ihre Webseite also nicht mehr darstellbar sein, lade bitte die Backup-Version wieder hoch. Das behebt den Fehler zumeist augenblicklich.

    Die nun folgenden Code-Schnipsel füge bitte einfach an das Ende der .htaccess an.

    Teil 1: Browser-Caching aktivieren

    Kaum eine andere Tuning-Maßnahme bringt mit so wenig Aufwand so viel Ergebnis. Viele der größten Dateien ihrer Webseite ändern sich im Grunde genommen nie. Deshalb ist es eine gute Idee, diese für eine lange Zeit in den Browser-Cache zu befördern. Dateien, wie zum Beispiel das CSS oder das JavaScript einer Webseite, werden dann nur beim ersten Besuch einmal vom Browser geladen. Bei jedem weiteren Besuch (oder aber auch beim Aufruf weiterer Seiten beim ersten Besuch) muss der Browser diese Dateien nicht mehr laden. Dementsprechend wird die Webseite viel schneller angezeigt.

    Dateien, die sich im Allgemeinen eher selten ändern, zum Beispiel JavaScripts, bekommen einen weit in der Zukunft definierten Cache-Header. Feeds hingegen werden nur eine Stunde gecached, fast alle anderen Dateien hingegen einen Monat. Zu beachten ist, dass in der Datei statische HTML-Seiten für eine schnellere Auslieferung für eine Stunde (3.600 Sekunden) in den Speicher befördert werden. Wer das nicht möchte, setzt stattdessen ein access plus seconds“ ein.

    Wichtig zu erwähnen ist, dass ein keep-alive-Header gesendet wird. Das erlaubt dem Browser das gleichzeitige Laden mehrerer Dateien und sorgt für einen weiteren Performance-Schub.

    Bitte beachten: Da auch das CSS zwischengespeichert wird, sollte man, wenn man öfter etwas daran ändert, entweder die Datei nach einer Änderung umbenennen, oder eine Versionierung implementieren. Ich bevorzuge die zweite Lösung, die ein Teil eines zukünftigen Artikels sein wird.

    # ----------------------------------------------------------------
    # Belässt die Dateien, die sich selten oder gar nicht ändern, für eine bestimmte Zeit im Browser-Cache
    # ----------------------------------------------------------------
    ## EXPIRES CACHING ##
    <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpg "access 1 year"
    ExpiresByType image/jpeg "access 1 year"
    ExpiresByType image/gif "access 1 year"
    ExpiresByType image/png "access 1 year"
    ExpiresByType text/css "access 1 month"
    ExpiresByType text/html "access 1 month"
    ExpiresByType application/pdf "access 1 month"
    ExpiresByType text/x-javascript "access 1 month"
    ExpiresByType application/x-shockwave-flash "access 1 month"
    ExpiresByType image/x-icon "access 1 year"
    ExpiresDefault "access 1 month"
    </IfModule>
    ## EXPIRES CACHING ##

    Teil 2: Die komprimierte Auslieferung der Dateien

    Viele Vorschläge für .htaccess Dateien, die im Netz zu finden sind, sind nur rudimentär und unvollständig. Alle denkbaren und wichtigen Datei-Formate werden durch meine .htaccess komprimiert ausgeliefert, damit ein wirklicher Geschwindigkeitsvorteil entsteht.

     ----------------------------------------------------------------
    # Komprimierung
    # ----------------------------------------------------------------
    <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/x-web-app-manifest+json
    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|css|gif|png|jpg|jpeg|txt)$">
    Header set Cache-Control "max-age=2592000, public"
    </FilesMatch>
    </IfModule>
    <IfModule mod_headers.c>
      <FilesMatch "\.(js|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>

    Teil 3: Allgemeine Sicherheitseinstellungen

    Der Grand­sei­g­neur des Webdesigns – Jeff Starr von Perishable Press – feilt bereits seit Jahren an seiner Blockliste für die .htaccess. Die neueste Version seiner Firewall, die 7G, ist ein Manifest der Sicherheit und wird gerne durch einige WordPress-Security-Plugins kopiert, weil sie so effektiv ist. Sie schützt unter anderem vor Cross-Site-Scripting und Schadcode-Implementierung über die Erweiterungen von URLs. Hackversuche werden trotz des minimalen Codes wirkungsvoll unterbunden und der Code arbeitet sehr effektiv.

    # 7G FIREWALL v1.6 20230206
    # @ https://perishablepress.com/7g-firewall/

    # 7G:[CORE]
    ServerSignature Off
    Options -Indexes
    RewriteEngine On
    RewriteBase /

    # 7G:[QUERY STRING]
    <IfModule mod_rewrite.c>

    RewriteCond %{QUERY_STRING} ([a-z0-9]{2000,}) [NC,OR]
    RewriteCond %{QUERY_STRING} (/|%2f)(:|%3a)(/|%2f) [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} (ckfinder|fckeditor|fullclick) [NC,OR]
    RewriteCond %{QUERY_STRING} (`|<|>|\^|\|\\|0x00|%00|%0d%0a) [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|char|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|(c99|php)shell|curl(_exec|test)|disable_functions?|document_root|elastix|encodeuricom|exploit|fclose|fgets|file_put_contents|fputs|fsbuff|fsockopen|gethostbyname|grablogin|hmei7|input_file|open_basedir|outfile|passthru|phpinfo|popen|proc_open|quickbrute|remoteview|root_path|safe_mode|shell_exec|site((.){0,2})copier|sux0r|trojan|user_func_array|wget|xertive) [NC,OR]
    RewriteCond %{QUERY_STRING} (;|<|>|\'|\"|\)|%0a|%0d|%22|%27|%3c|%3e|%00)(.*)(/\*|alter|base64|benchmark|cast|concat|convert|create|encode|declare|delete|drop|insert|md5|request|script|select|set|union|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,L]

    # RewriteRule .* /7G_log.php?log [END,NE,E=7G_QUERY_STRING:%1___%2___%3]

    </IfModule>

    # 7G:[REQUEST URI]
    <IfModule mod_rewrite.c>

    RewriteCond %{REQUEST_URI} (\^|`|<|>|\\|\|) [NC,OR]
    RewriteCond %{REQUEST_URI} ([a-z0-9]{2000,}) [NC,OR]
    RewriteCond %{REQUEST_URI} (=?\\(\'|%27)/?)(\.) [NC,OR]
    RewriteCond %{REQUEST_URI} (/)(\*|\"|\'|\.|,|&|&amp;?)/?$ [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]
    RewriteCond %{REQUEST_URI} (\.(s?ftp-?)config|(s?ftp-?)config\.) [NC,OR]
    RewriteCond %{REQUEST_URI} (\{0\}|\"?0\"?=\"?0|\(/\(|\.\.\.|\+\+\+|\\\") [NC,OR]
    RewriteCond %{REQUEST_URI} (thumbs?(_editor|open)?|tim(thumbs?)?)(\.php) [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} (/%7e)(root|ftp|bin|nobody|named|guest|logs|sshd)(/) [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|localhost|makefile|pingserver|wwwroot)(/)? [NC,OR]
    RewriteCond %{REQUEST_URI} (\(null\)|\{\$itemURL\}|cAsT\(0x|echo(.*)kae|etc/passwd|eval\(|self/environ|\+union\+all\+select) [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} (/)(awstats|(c99|php|web)shell|document_root|error_log|listinfo|muieblack|remoteview|site((.){0,2})copier|sqlpatch|sux0r) [NC,OR]
    RewriteCond %{REQUEST_URI} (/)((php|web)?shell|crossdomain|fileditor|locus7|nstview|php(get|remoteview|writer)|r57|remview|sshphp|storm7|webadmin)(.*)(\.|\() [NC,OR]
    RewriteCond %{REQUEST_URI} (/)(author-panel|class|database|(db|mysql)-?admin|filemanager|htdocs|httpdocs|https?|mailman|mailto|msoffice|_?php-my-admin(.*)|tmp|undefined|usage|var|vhosts|webmaster|www)(/) [NC,OR]
    RewriteCond %{REQUEST_URI} (base64_(en|de)code|benchmark|child_terminate|curl_exec|e?chr|eval|function|fwrite|(f|p)open|html|leak|passthru|p?fsockopen|phpinfo|posix_(kill|mkfifo|setpgid|setsid|setuid)|proc_(close|get_status|nice|open|terminate)|(shell_)?exec|system)(.*)(\()(.*)(\)) [NC,OR]
    RewriteCond %{REQUEST_URI} (/)(^$|00.temp00|0day|3index|3xp|70bex?|admin_events|bkht|(php|web)?shell|c99|config(\.)?bak|curltest|db|dompdf|filenetworks|hmei7|index\.php/index\.php/index|jahat|kcrew|keywordspy|libsoft|marg|mobiquo|mysql|nessus|php-?info|racrew|sql|vuln|(web-?|wp-)?(conf\b|config(uration)?)|xertive)(\.php) [NC,OR]
    RewriteCond %{REQUEST_URI} (\.)(7z|ab4|ace|afm|ashx|aspx?|bash|ba?k?|bin|bz2|cfg|cfml?|cgi|conf\b|config|ctl|dat|db|dist|dll|eml|engine|env|et2|exe|fec|fla|git|hg|inc|ini|inv|jsp|log|lqd|make|mbf|mdb|mmw|mny|module|old|one|orig|out|passwd|pdb|phtml|pl|profile|psd|pst|ptdb|pwd|py|qbb|qdf|rar|rdf|save|sdb|sql|sh|soa|svn|swf|swl|swo|swp|stx|tar|tax|tgz|theme|tls|tmd|wow|xtmpl|ya?ml|zlib)$ [NC]

    RewriteRule .* - [F,L]

    # RewriteRule .* /7G_log.php?log [END,NE,E=7G_REQUEST_URI:%1___%2___%3]

    </IfModule>

    # 7G:[USER AGENT]
    <IfModule mod_rewrite.c>

    RewriteCond %{HTTP_USER_AGENT} ([a-z0-9]{2000,}) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (&lt;|%0a|%0d|%27|%3c|%3e|%00|0x00) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (ahrefs|alexibot|majestic|mj12bot|rogerbot) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ((c99|php|web)shell|remoteview|site((.){0,2})copier) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (econtext|eolasbot|eventures|liebaofast|nominet|oppo\sa33) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (base64_decode|bin/bash|disconnect|eval|lwp-download|unserialize|\\\x22) [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} (acapbot|acoonbot|asterias|attackbot|backdorbot|becomebot|binlar|blackwidow|blekkobot|blexbot|blowfish|bullseye|bunnys|butterfly|careerbot|casper|checkpriv|cheesebot|cherrypick|chinaclaw|choppy|clshttp|cmsworld|copernic|copyrightcheck|cosmos|crescent|cy_cho|datacha|demon|diavol|discobot|dittospyder|dotbot|dotnetdotcom|dumbot|emailcollector|emailsiphon|emailwolf|extract|eyenetie|feedfinder|flaming|flashget|flicky|foobot|g00g1e|getright|gigabot|go-ahead-got|gozilla|grabnet|grafula|harvest|heritrix|httrack|icarus6j|jetbot|jetcar|jikespider|kmccrew|leechftp|libweb|linkextractor|linkscan|linkwalker|loader|masscan|miner|mechanize|morfeus|moveoverbot|netmechanic|netspider|nicerspro|nikto|ninja|nutch|octopus|pagegrabber|petalbot|planetwork|postrank|proximic|purebot|pycurl|python|queryn|queryseeker|radian6|radiation|realdownload|scooter|seekerspider|semalt|siclab|sindice|sistrix|sitebot|siteexplorer|sitesnagger|skygrid|smartdownload|snoopy|sosospider|spankbot|spbot|sqlmap|stackrambler|stripper|sucker|surftbot|sux0r|suzukacz|suzuran|takeout|teleport|telesoft|true_robots|turingos|turnit|vampire|vikspider|voideye|webleacher|webreaper|webstripper|webvac|webviewer|webwhacker|winhttp|wwwoffle|woxbot|xaldon|xxxyy|yamanalab|yioopbot|youda|zeus|zmeu|zune|zyborg) [NC]

    RewriteRule .* - [F,L]

    # RewriteRule .* /7G_log.php?log [END,NE,E=7G_USER_AGENT:%1]

    </IfModule>

    # 7G:[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,L]

    # RewriteRule .* /7G_log.php?log [END,NE,E=7G_REMOTE_HOST:%1]

    </IfModule>

    # 7G:[HTTP REFERRER]
    <IfModule mod_rewrite.c>

    RewriteCond %{HTTP_REFERER} (semalt\.com|todaperfeita) [NC,OR]
    RewriteCond %{HTTP_REFERER} (order(\s|%20)by(\s|%20)1--) [NC,OR]
    RewriteCond %{HTTP_REFERER} (blue\spill|cocaine|ejaculat|erectile|erections|hoodia|huronriveracres|impotence|levitra|libido|lipitor|phentermin|pro[sz]ac|sandyauer|tramadol|troyhamby|ultram|unicauca|valium|viagra|vicodin|xanax|ypxaieo) [NC]

    RewriteRule .* - [F,L]

    # RewriteRule .* /7G_log.php?log [END,NE,E=7G_HTTP_REFERRER:%1]

    </IfModule>

    # 7G:[REQUEST METHOD]
    <IfModule mod_rewrite.c>

    RewriteCond %{REQUEST_METHOD} ^(connect|debug|move|trace|track) [NC]

    RewriteRule .* - [F,L]

    # RewriteRule .* /7G_log.php?log [END,NE,E=7G_REQUEST_METHOD:%1]

    </IfModule>

    Teil 4: Wichtige Sicherheitseinstellungen für WordPress

    Die allgemeine Beliebtheit des Content-Management-Systems WordPress ist leider der Grund dafür, dass es sich immer öfter den Hackversuchen böswilliger Mitmenschen ausgesetzt sieht. Mit einigen Zeilen Code in der .htaccess kann man dem vorbeugen. Kommt dann noch eine Absicherung des Administrator-Zugangs der Website hinzu, kann man die Site als sicher ansehen, wenn man die Basics wie das rechtzeitige Update von WordPress, Theme und Plugins beherrscht.

    a) Schutz des Administrator-Bereichs

    Wie man den Admin-Zugang einer WordPress-Website per .htaccess und .htpasswd wirkungsvoll absichert, haben wir bereits beschrieben. Ebenfalls wird die potenziell unsichere XML-RPC-Schnittstelle von WordPress mit diesem Code völlig abgeschaltet. Wer die Schnittstelle nutzen möchte, weil er zum Beispiel mit der neuen WordPress-Desktop-App arbeitet, muss den Bereich des Codes auskommentieren. Das geschieht mit einer vorgesetzten Raute (#) pro Code-Zeile. Die Absicherung des Adminbereichs ist bereits vorbereitet, wenn man diese Form der Sicherheit nicht nutzen möchte, dann kommentieren Sie diesen Bereich aus.

     ----------------------------------------------------------------
    # Schutz des Administrator-Bereichs. Wenn der .htaccess/.htpasswd Schutz genutzt werden soll, auskommentieren UND PFAD ANPASSEN
    # ----------------------------------------------------------------
    #<Files wp-login.php>
    #AuthName "Admin-Bereich"
    #AuthType Basic
    #AuthUserFile ihr/pfad/zur/.htpasswd
    #require valid-user
    #</Files>

    b) Zugriff von außen auf .htaccess Datei verbieten

    Damit die wichtige Serversteuerungs-Datei .htaccess keinesfalls von außerhalb des (S)FTP Zugangs erreichbar und damit verändert werden kann, verbieten wir als erstes den Zugriff darauf.

    # Zugriff auf .htaccess und .htpasswd verbieten, falls in Benutzung
    <FilesMatch "(\.htaccess)">
      Order deny,allow
      Deny from all
    </FilesMatch>

    c) Bild-Hotlinking verbieten

    Das sogenannte Hotlinking von Bildern kann zum echten Problem werden. Hierbei laden andere Menschen die Bilder aus ihrer Webseite nicht herunter, um sie dann anschliessend zu verlinken, sondern es wird nur der Pfad zu ihrem Bild angegeben. Dies kann ihre Webseite verlangsamen und wichtige Bandbreite stehlen. Die externe Verlinkung der Bilder kann man mit dem folgenden Code jedoch ganz leicht verhindern.

    Der Platzhalter ihrewebseite.com muss durch die URL ihrer Webseite ersetzt werden. Ganz unten ist der Pfad zu einer Grafik zu finden, die anstatt des verlinkten Bildes angezeigt wird. Diese Grafik kann durch jede andere ersetzt werden.

    RewriteEngine on
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ihrewebseite.com [NC]
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ihrewebseite.com [NC]
    RewriteRule \.(jpg|jpeg|png|gif)$ http://i.imgur.com/g7ptdBB.png [NC,R,L]

    Bitte beachten: Sollte man einen externen Feedanbieter, wie zum Beispiel Feedburner, benutzen, könnte es sein, dass keine Bilder im Feed landen.

    d) IP-Adressen dauerhaft bannen

    Es kann schon mal vorkommen, dass man spezielle IP-Adressen einfach bannen möchte. Sei es, weil derjenige versucht hat, den Administrationsbereich zu hacken, oder aber, weil er vielleicht nur böswillige (Spam) Kommentare hinterlässt. Wenn man die IP-Adresse desjenigen herausgefunden hat, nutze folgenden Code um ihn für immer, zumindest unter dieser IP-Adresse, auszusperren.

    <Limit GET POST>
    order allow,deny
    deny from 123.456.78.9
    deny from 987.654.32.1
    allow from all
    </Limit>

    Bitte beachten: Die IP-Adressen im obigen Code müssen natürlich noch angepasst werden. Diese Änderung gehörte einstmals zum Standard-Repertoire, ist jedoch mit Inkrafttreten der DSGVO deutlich schwieriger umzusetzen, da man IP-Adressen nicht mehr standardmäßig erfassen darf.

    e) Include-Only-Dateien blocken

    Etliche, wirklich wichtige Dateien sollten niemals zugänglich sein, außer von WordPress selbst. Auch davor kann man sich mit folgendem Code schützen.

    Bitte beachten: Für eine WordPress-Multisite-Installation funktioniert der Code nicht.

    # Block the include-only files.<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>

    f) Separate Htaccess schützt den Wp-Content-Ordner

    Der WordPress Ordner wp-content ist der wichtigste Ordner, da er ihre Themes, die Plugins und Bilder, gecachte Dateien usw. enthält. Für Hacker ist dieser Ordner das Hauptangriffsziel, deshalb sollte er gut geschützt sein.

    Erstelle eine separate .htaccess Datei, füge den folgenden Code hinein und lade die Datei in den wp-content Ordner hoch (www.einewebseite/wp-content/).

    Order deny,allow
     Deny from all
     <Files ~ ".(xml|css|jpe?g|png|gif|js)$">
     Allow from all
     </Files>

    g) Die XML-RPC Schnittstelle abschalten

    Die XML-RPC Schnittstelle in WordPress dient dazu, WordPress mit externen Programmen verwalten zu können; zum Beispiel, um Artikel zu veröffentlichen oder Kommentare zu bearbeiten. Zu den Programmen gehören unter anderem die mobilen Anwendungen für iOS, Android und Co, aber auch die WordPress-Desktopanwendung.

    Die Schnittstelle kann aber auch für DDoS-Angriffe genutzt werden, die dafür sorgen, dass ihre Webseite lahm gelegt wird. Mit einem kurzen Eintrag in die .htaccess schaltet man die Schnittstelle komplett ab:

    <Files xmlrpc.php>
      Order Deny,Allow
      Deny from all
    </Files>

    Diesen Eintrag sollte man allerdings nur verwenden, wenn ihre Webseite keine Blog-Funktionalität hat, da auch keine Trackbacks mehr durch gelassen werden. Sollten Sie einen Blog betreiben oder ihr WordPress mit mobilen Anwendungen betreiben wollen, nutze den folgenden Code, um die Schnittstelle abzusichern:

    <IfModule mod_setenvif.c>
      <Files xmlrpc.php>
        BrowserMatch "Poster" allowed
        BrowserMatch "WordPress" allowed
        BrowserMatch "wp-iphone" allowed
        BrowserMatch "wp-android" allowed
        Order Deny,Allow
        Deny from All
        Allow from env=allowed
      </Files>
    </IfModule>

    Im Beispiel-Code sind Zeile für Zeile folgende Clients freigegeben:

    • Poster
    • WordPress-Blogs
    • WordPress for iOS
    • WordPress for Android

    Nicht benötigte Freigaben gehören zeilenweise entfernt. Neue User-Agents können hinzugefügt und somit freigeschaltet werden.

    Teil 5. PHP – Fehlermeldungen unterdrücken

    Dies ist ein ganz wichtiger Punkt, denn sobald PHP eine Fehlermeldung heraus gibt, wird damit auch der Dateipfad sichtbar. Sergej Müller schreibt zu diesem Problem:

    In WordPress-Blogs ist es recht simpel, einen PHP-Fehler (indirekt) zu erzeugen, um an die Fehler-Ausgabe inklusive Pfad heran zu kommen. Dafür muss man weder Administrator noch Experte sein. Durch einen direkten Aufruf bestimmter WordPress-Core- wie Plugins-Dateien in der Adresszeile des Browsers werden PHP-Fatal-Fehler generiert (weil notwendige und referenzierte WordPress-Funktionen fehlen).Erlauben Server- bzw. PHP-Einstellungen die Darstellung von Fehlern, erscheinen Fehler der Anwendung im Browser. Kaum jemand kann etwas mit der Fehlerausgabe anfangen, für Angreifer ist es jedoch eine sehr wertvolle Information, um nach Hintertüren zu suchen und diese auszunutzen.

    Mit einem simplen Eintrag in der .htaccess Datei löst man das Problem:

    php_flag display_errors Off

    Download der kompletten .htaccess Datei

    Die komplette .htaccess Datei runtergeladen (ZIP, 4kB)

    Fazit

    Mit dieser .htaccess Datei sind wir schon ziemlich nahe am Optimum. Die Datei ist eine hervorragende Grundlage, in der nur noch einige kleine, seitenspezifische Details ergänzt werden müssen (vermutlich). Mir und meiner Website leistet diese Datei sehr gute Dienste, und, ich hoffe stark, dir auch. Die Datei ist zudem so aufgebaut, dass es keine nervigen Probleme mehr bei Google Page Speed Insights gibt.


    .htaccess-Tester prüft Rewrite-Regeln auf ihre Richtigkeit

    Das Werkeln an der .htaccess ist nicht jedermanns Sache. Besonders das Umschreiben von URLs mit mod_rewrite bringt oft nicht auf Anhieb das gewünschte Ergebnis. Um die Rewrite-Rules nicht direkt am eigenen Server ausprobieren zu müssen, gibt es den .htaccess-Tester. Über einige wenige Eingabefelder lassen sich Regeln schnell und unkompliziert überprüfen.

    Umleitung: Eine der Aufgaben der .htaccess (Bildquelle: Hartmut910 / pixelio.de)

    Schnelles Testen von Regeln über eine simple UI

    Der spartanischen Oberfläche des .htaccess-Testers reichen drei Eingabefelder. Ins erste Eingabefeld kommt die URL, die getestet werden soll. Ins zweite Feld schreibt man die Regeln, die überprüft werden sollen. Ins dritte Feld gibt man optional einen HTTP-Referer ein.

    Oberfläche des .htaccess-Testers

    Als Beispiel soll per Umschreibungsregel die Eingabe von robots.txt an eine PHP-Datei weitergeleitet werden. Ins erste Feld schreibe ich also die zu prüfende URL:

    http://www.drweb.de/robots.txt

    Ins zweite Eingabefeld kommt die zu prüfende Regel, erforderlichenfalls auch mehrere. Bis auf wenige Ausnahmen ist der .htaccess-Tester in der Lage, alle Regeln zu überprüfen. Nur mit Eingaben wie „%{REQUEST_FILENAME}“ kann der Tester noch nicht umgehen. Es wird laut Angaben der Entwickler aber daran gearbeitet, auch solche Problemstellungen in Zukunft abarbeiten zu können. Die Regel unseres Beispiels lautet:

    RewriteEngine On
    RewriteRule ^robots\.txt$ /robots.php

    Der Tester gibt nun die per mod_rewrite umgeschriebene URL aus. In diesem Fall also:

    http://www.drweb.de/robots.php

    Zusätzlich zur Ausgabe-URL gibt es eine Debugging-Info, die auf Fehler in den Regeln aufmerksam macht oder Hinweise zum Verhalten des Testers gibt. Setzt man beispielsweise das Flag [L], welches dafür sorgt, dass nach dieser Regel keine weiteren Regeln mehr ausgeführt werden, so gibt der Tester einen entsprechenden Hinweis. Denn auch ein falsch gesetztes Flag kann schon mal der Grund dafür sein, dass eine Umschreibung nicht so läuft, wie sie soll.

    Fazit: Mit dem .htaccess-Tester lassen sich Umschreibungsregeln sehr schnell und einfach prüfen. Außerdem hilft die Debugging-Info Fehler zu finden. Kenntnisse im richtigen Umgang mit mod_rewrite sind natürlich vorausgesetzt. Denn eine Hilfe zur Erstellung von Regeln bietet der Tester nicht.


    PHP und .htaccess: Lesbare URLs mit variablen Verzeichnisnamen

    Bei dynamischen Websites, die zum Beispiel mit PHP realisiert werden, wird oftmals eine komplette Website über eine einzige PHP-Datei gesteuert. Dabei werden Variablen als URL-Parameter übergeben und Seiten mit unterschiedlichen Inhalten generiert. So entstehen in der Regel unschöne URLs, die zum einen sehr lang und zum anderen weder für Menschen noch für Suchmaschinen verständlich sind. Mit ein bisschen PHP-Code lässt sich das ändern.

    Mit ein paar Zeilen in der .htaccess-Datei lassen sich kurze und prägnante URLs generieren, bei denen Variablen nicht mehr über URL-Parameter sondern als Verzeichnisnamen übertragen werden. Aus

    http://www.example.com/index.php?rubrik=leistungen&seite=beratung

    wird dann

    http://www.example.com/leistungen/beratung/

    und suggeriert, dass es sich tatsächlich um Verzeichnisse handelt, in denen die Inhalte der Seite liegen.

    Vorteile

    Der Vorteil ist zum einen, dass die URLs deutlich kürzer werden. Gerade wenn man URLs beziehungsweise Links per Mail versendet oder gar in gedruckter Form veröffentlicht, ist eine kurze und einprägsame Adresse von großer Bedeutung. Ein weiterer Grund, auf URL-Parameter zu verzichten, liefern Suchmaschinen wie Google selbst. Sie raten davon ab, zu lange URLs zu verwenden, da solche Seiten deutlich schlechter bewertet und demzufolge auch nachrangig berücksichtigt werden bei der Anzeige von Suchergebnissen.

    Laut Googles Starter Guide für die Suchmaschinenoptimierung sollten URLs

    1. kurz sein, auf URL-Parameter sowie Session-IDs weitestgehend verzichten,
    2. konkrete Bezeichnungen haben anstatt allgemeiner („leistungen“ statt „seite2“) und
    3. nicht zu viele Unterverzeichnisse besitzen.

    Außerdem kann man mit der oben genannten Methode verschleiern, dass eine Website mit PHP programmiert ist. So erschwert man es Hackern, Sicherheitslücken eines Servers bzw. einer serverseitigen Programmiersprache auszunutzen, da die verwendete Programmiersprache nicht ersichtlich ist.

    Drei Zeilen in die .htaccess-Datei

    Um die Variablenübergabe über Verzeichnisnamen zu steuern, reichen drei Zeilen in der .htaccess-Datei aus:

    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule .* /index.php

    Die erste Zeile startet die „Rewrite Engine“ von Apache. In der zweiten Zeile wird die Bedingung für die in der dritten Zeile folgende Regel angegeben. Die Bedingung prüft, ob es sich bei der angeforderten Datei tatsächlich um eine existierende Datei handelt.

    Achtung: Dies ist jedoch nur möglich wenn im Apache Server das Modul: modrewrite aktiviert ist. Andernfalls verursacht der soeben eingefügte Code einen Fehler und Ihre Webseite bleibt weiß.

    Die Bedingung ist erfüllt, wenn es sich nicht um eine Datei handelt. Die Flag „-f“ prüft, ob es sich um eine Datei handelt, „!-f“ prüft – so wie es in dem Beispiel gebraucht wird –, ob es sich nicht um eine Datei handelt:

    RewriteCond %{REQUEST_FILENAME} -f # Bedingung erfüllt, wenn es eine Datei ist
    RewriteCond %{REQUEST_FILENAME} !-f # Bedingung erfüllt, wenn es keine Datei ist

    Die Regel in der dritten Zeile leitet alle Anfragen („.*“), die nicht auf eine existierende Datei verweisen, an die Datei „/index.php“ weiter. Handelt es sich um eine exisitierende Datei (z. B. eine Grafik oder ein PDF-Dokument), so wird diese ganz normal aufgerufen, dargestellt bzw. zum Download angeboten.

    Über die PHP-Datei lässt sich dann die URL auslesen und weiterverarbeiten. Alternativ lässt sich die Übergabe der URL-Parameter an die PHP-Datei auch direkt über den Eintrag in die .htaccess-Datei realisieren. Dazu die letzte Zeile der .htaccess-Datei austauschen:

    RewriteRule ^([\w]+)/?([\w]+)? /index.php?rubrik=$1&seite=$2

    Über die regulären Ausdrücke „([\w]+)“ werden Zeichenketten bestehend aus Buchstaben und Zahlen, die durch einen Schrägstrich getrennt sind, als Variable an die PHP-Datei übergeben. Das Fragezeichen hinter dem Schrägstrich und dem zweiten Ausdruck signalisiert, dass diese Werte optional sind. Das heißt, es kann auch nur ein Wert übergeben werden, und zwar für den Parameter „rubrik“.

    Variablen auslesen mit PHP

    Wer die erste Variante von „RewriteRule“ nutzt, muss die Variablen „rubrik“ und „seite“ per PHP aus der URL auslesen. Damit die „index.php“ die Variablen aus der URL auslesen kann, wird die URL an eine PHP-Variable übergeben:

    $url = $_SERVER["REQUEST_URI"];

    Die vorderfinierte Variable „$_SERVER[„REQUEST_URI“]“ enthält die URL, über die die PHP-Datei aufgerufen wurde. Im aktuellen Beispiel ist das „/leistungen/beratung/“.

    Mit der Funktion „explode()“ wird die URL in ihre Bestandteile zerlegt und als Array weiterverarbeitet:

    $url = explode("/", $url);

    Da die Zeichenkette „/leistungen/beratung/“ anhand des Schrägstrichs zerlegt wird, werden dem Array in diesem Fall vier Werte übergeben, wobei der erste und der letzte Wert jeweils eine leere Zeichenkette sind, da vor dem ersten und nach dem letzten Schrägstrich keine Zeichen stehen.

    Die eigentlichen Werte „leistungen“ und „beratung“ befinden sich an Position zwei und drei des Arrays. Sie werden jeweils einer Variablen zugeordnet:

    $rubrik = $url[1];
    $seite = $url[2];

    In der zweiten Variante des „RewriteRule“-Eintrags in der .htaccess-Datei können die URL-Parameter direkt über „$_GET“ ausgelesen werden, ihne die Werte aus der URL zu extrahieren:

    $rubrik = $_GET["rubrik"];
    $seite = $_GET["seite"];

    Wird nur ein Verzeichnis angeben (z. B. „/leistungen/“), so bleibt die Variable „$seite“ leer. Was nicht funktioniert, ist die Übergabe eines Wertes nur für die Variable „$seite“, da der erste Verzeichnisname immer der Variablen „$rubrik“ zugewiesen wird.

    Ausnahmen festlegen

    Möglicherweise will man nicht alle URL-Anfragen an die index.php weiterleiten. Das Verzeichnis „downloads“ soll z. B. nicht von der Datei „index.php“ sondern von „downloads.php“ verarbeitet werden. In diesem Fall fügt man nach der ersten Zeile der .htaccess-Datei folgende Zeile ein:

    RewriteRule ^downloads$ /downloads.php

    Jetzt wird die URL „/downloads/“ an die Datei „downloads.php“ verwiesen und kann von dort verarbeitet werden.

    Fazit

    Die hier vorgestellte Methode, um URL-Paramter zu übertragen, wird insbesondere von Content-Management-Systemen eingesetzt. Bei TYPO3 sorgt zum Beispiel die Erweiterung RealURL für solche kurzen und suchmaschinenfreundlichen URLs.

    Vom Prinzip her arbeitet RealURL genau so wie die hier beschriebene Methode.

    Dieser Beitrag wurde zuletzt am 21. Oktober 2024 aktualisiert: Update auf 7g-Firewall.

    Wie hilfreich fanden Sie diese Seite?

    Durchschnittliche Bewertung 1.2 / 5. Anzahl Bewertungen: 142

    Ähnliche Beiträge

    48 Kommentare

      1. Hallo Selda,

        richtig, in Shopify hast du keinen direkten Zugriff auf die .htaccess-Datei, wie du es z.B. bei WordPress oder anderen selbstgehosteten Plattformen gewohnt bist. Shopify ist eine gehostete E-Commerce-Plattform, und viele serverseitige Konfigurationsdateien wie .htaccess sind nicht zugänglich.

        Was du stattdessen tun kannst:

        URL-Weiterleitungen kannst du über die Shopify-Admin-Oberfläche einrichten:
        Online-Shop > Navigation > URL-Weiterleitungen.
        Für andere Anpassungen wie Sicherheitskonfigurationen oder Caching musst du die integrierten Shopify-Einstellungen nutzen oder Drittanbieter-Apps verwenden.
        Falls du tiefgreifendere Anpassungen brauchst, wäre ein eigenes Hosting oder ein Headless-Setup mit Shopify als Backend erforderlich.
        Möchtest du eine spezielle Funktion umsetzen, die normalerweise über .htaccess geregelt wird? Dann finden wir gemeinsam eine Alternative in Shopify.

    1. Ich finde es cool, dass man z.B. beim Plugin Yoast SEO über Werkzeuge die HTACCESS und robots.txt in WordPress bearbeiten kann. So muss man nicht via FTP auf den Server drauf. Bei vielen WordPress Installationen ist das wirklich super praktisch 🙂 nur als Tipp, falls es jemand noch nicht weiß

    2. Zeilenumbrüche in den Beispielen würden das Lesen erheblich vereinfachen.
      Mir ist schleierhaft, warum jemand, der als Dr. Web auftritt, nicht selbst schon auf die Idee gekommen ist.

    3. Kann man mit htaccess verhindern, das die Seite auf Google Fonts Benutzung oder auf irgend welche Weiterleitungen gescannt werden kann und es verbieten?
      Ich benutze zwar kein WordPress sondern RapidWeaver für unsere Schulhomepages aber für die „htaccess“ Datei sollte es egal sein 😉

    4. Vielen Dank für die ausführliche Anleitung. Man kann es definitiv als eine Art Check-Liste benutzen um bei der Konfiguration die wichtigsten Sachen im Kopf zu behalten.

    5. Vielen Dank für diesen sehr ausführlichen und informative Beitrag. Da waren sehr vielversprechende Tipps für mich drin. Mein Lob und meine Anerkennung für diese Arbeit.

    6. Hallo zusammen, wow, ich bin begeistert über die zahlreichen Tipps was die htaccess Datei betrifft. Bisher hatte ich nur die Standard Sachen drinnen stehen was WordPress hergab, jetzt konnte ich meine htaccess Datei um einiges erweitern. Besten Dank, Rainer

    7. Vielen Dank für diesen hilfreichen Beitrag. Einiges hatte ich bereits vorher schon gewusst, doch die Tipps die ich hier noch bekommen habe haben meine Sicherheit erweitert 🙂 Viele Grüße, Nick Freund

    8. Hallo! Danke für die Zusammenfassung.
      Eine Frage dazu, die Firewall 7G ist auf der Webseite die oben verlinkt ist bereits aktualisiert worden und ist in der Textdatei die es zum Download gibt um einiges umfangreicher. Sollte man die ganze Firewall einsetzen oder nur den oberen Teil wie es hier beschrieben wurde?
      Wenn nur den oberen, warum?
      Danke & Gruß
      Rolf

    9. Das ist bis jetzt die ausführlichste und verständlichste Zusammenfassung, die ich bis jetzt gefunden habe. Vielen Dank dafür! Vor allem waren mir einige Sicherheitsfeatures neu bzw. dass man das einfach über die htaccess lösen kann.
      Macht das eigentlich nicht die ganzen Plugins wie WP-Optimze, WPFastest Cache, Smush usw. überflüssig, schließlich machen die Plugins ja nichts anderes als in die htaccess zu schreiben? Klar, bieten die noch andere Features aber ob man die braucht steht auf einem anderen Blatt. Ich bin ja ein Fan davon nicht jeden „Mist“ mit einem Plugin lösen zu wollen. Was nicht da ist, kann auch nicht angegriffen bzw. zum Sicherheitsproblem werden…
      Würde mich freuen, wenn die Authoren oder Kommentatoren ihre Sicht darlegen könnten, herzlichen Dank.

    10. Hallo ich habe versucht das hier beschriebene umzusetzt aber bin gescheitert
      ich wollte /example.php?example= zu /example= umschreiben.
      Kann mir jemand helfen?

      LG
      gerd

    11. Wow! Direkt unter meinen wertvollsten Lesezeichen gespeichert. Eine Frage hätte ich allerdings. Was ist, wenn man die Datei bereits aktiviert wurde und nachträglich Änderungen erwünscht sind? FTP über den Server? Das finde ich ich weniger optimal. Denn man müsste zunächst schauen, wo diese sich befindet. Falls Ihr hier einen Tipp hättet wäre ich Euch sehr dank bar. Danke noch mal für den Tollen Beitrag!

    12. Hallo und vielen Dank! Habe 7 Tipps davon erfolgreich umgesetzt.
      Leider erhalte ich bei
      # PHP – Fehlermeldungen unterdrücken
      php_flag display_errors Off
      einen 500 internal server error.
      Sobald ich die Zeile in der .htaccess auskommentiere, funktioniert alles. (Zumindest habe ich bisher keine weiteren Fehler entdeckt ..)
      Feli

      1. @Feli: Bei mir war’s das Gleiche. Ich würde den Support des Webhosts kontaktieren und die beste Methode erfragen, um die PHP-Fehlermeldung zu deaktivieren. Bei meinem Host, DomainFactory, lässt sich das z. B. erreichen, indem man im Kundenmenü die Konfigurationsdatei php.ini erstellt und darin die Fehlermeldung abschaltet. Eine Sache von fünf Minuten. Die lohnen sich – ich habe auf einer meiner WP-Sites tatsächlich schon mitbekommen, dass ein Schnüffler mittels PHP-Fehlermeldung den Pfad herausgefunden hat.

    13. Oft ist es sinnvoll, statt einer einzelnen IP besser gleich die gesamte IP-Range eines Providers zu sperren (auf „Besuch“ aus Russland oder der Ukraine können die Meisten wohl verzichten).
      In diesem Fall erweist sich das Sperren über CIDR (Classless Inter Domain Routing) als nützlich, z.B.:
      deny from 188.143.128.0/17 #Russian Federation
      deny from 94.154.192.0/18 #Ukraine

    14. „Separate Htaccess schützt den Wp-Content-Ordner“
      Nach hinzufügen dieser Datei in meinen Content Ordner, wurden einige Icons und die Schriftarten auf meiner Webseite nicht mehr geladen.
      Habe deshalb diese .htacces wieder entfernt

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert