.htaccess Schutz – WordPress absichern Teil4

1. Zugriffsschutz des Admin-Bereichshtaccess

Nur wenige Security Plugins für WordPress können zum Schutz der bekanntesten Blogging-Plattform beitragen. Viele dieser Plugins sind komplex und überfordern den Anwender mit unnötigen Funktionen – Schlimmer: Ihre Funktion ist oftmals nutzlos und ganz nebenbei lassen sie ein falsches Sicherheitsgefühl aufkeimen.

Doch es geht auch anders. Mit technischen Maßnahmen auf Serverebene lässt sich ein weitaus besserer Schutz von WordPress erreichen. Äußert effektiv ist der Zugriffsschutz des Admin-Bereichs mittels einer User- / Passwortabfrage – vielen bekannt unter dem Begriff .htaccess. Mit Konfigurationsbeispielen (Code-Snippets) für die Webserver Apache, nginx und Lighttpd zeige ich euch wie das funktioniert.

Das Sicherheitskonzept auf Serverebene besteht aus mehreren Komponenten. Heute beginnen wir mit einem sehr wichtigen Puzzelteil – dem Zugriffsschutz.

Dieser Beitrag ist Teil einer Artikelserie:

Update

März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert.

2. .htaccess bzw. Zugriffsschutz

.htaccess-Dateien sind Server-Konfigurationsdateien für Verzeichnisse auf Webservern. Ursprünglich entwickelt von der NCSA wird das Konzept heute vom weitverbreiteten Apache Webserver verwendet. Der Name .htaccess wird in weiten Kreisen des Internets als Synonym für Zugriffsschutz für Dateien oder Verzeichnisse auf Internetseiten bzw. Webservern benutzt. Doch .htaccess kann mehr als lediglich Daten mit einem Passwort zu schützen:

  • Weiterleitungen und Zugriffe auf Webseiten verwalten – sogenannte Redirects. Wird in Apache über das mod_rewrite Modul abgebildet
  • Steuern des Verzeichnisbrowsing bzw. Directory-Listing
  • Individuelle Fehlermeldungen gestalten
  • IP-Adressen, IP-Bereiche oder Namensadressen zulassen oder ausschließen
  • Auf selfhtml.org findet sich eine schöne Funktionsübersicht

Wir beschränken uns auf den Zugriffsschutz für den Administrationsbereich eurer WordPress-Installation. Dieser sollte unter keinen Umständen öffentlich für jedermann zugänglich sein. Der Zugriff auf das »Allerheiligste« obliegt einzig und allein dem Administrator und Autoren mit beschränkten Rechten.
Zugriffschutz

Der Kuketz-Blog ist spendenfinanziert!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.1 Besser als jedes Security Plugin

Gerne verwendet und immer wieder empfohlen werden Security Plugins wie Login LockDown oder Limit Login Attempts zur Absicherung des Admin-Bereichs gegen Brute-Force Angriffe. Nach einer gewissen Anzahl gescheiteter Loginversuche wird die anfragende IP-Adresse für die Dauer X ausgesperrt. Bereits im letzten Artikel habe ich aufgezeigt, dass der Nutzen solcher Plugins gegen null tendiert. Gegen professionelle Angriffswellen haben beide Plugins – sofern die Standardsettings nicht angepasst wurden – nichts entgegenzusetzen. Die meisten Anwender sind vom Schutz überzeugt und wiegen sich damit in falsche Sicherheit.

Doch warum soll es einem Bot oder Dritten überhaupt gestattet sein den Login-Bereich aufrufen zu können? Jeder Versuch den Anmeldebereich aufzurufen lässt sich mit einem Zugriffsschutz unterbinden. Nach Aufruf der bekannten »wp-login.php« erhält der Bot dann lediglich eine »401 Authorization Required« Rückmeldung. Im Logfile macht sich ein erfolgloser Aufruf dann folgendermaßen bemerkbar (Beispiel nginx):
No Auth
Neben Datum und Uhrzeit erkennt ihr im Ausschnitt die Meldung »no user/password was provided for basic authentication«. Zusätzlich wird die IP-Adresse und die URL protokolliert. Abhängig vom Bekanntheitsgrad des Blogs werden pro Tag tausende solcher Anfragen im Logfile aufgezeichnet.

Durch einen Zugriffsschutz ist der Bot überhaupt nicht in der Lage direkte Brute-Force Angriffe auf den WordPress Anmeldebereich durchzuführen. Stattdessen scheitert der Versuch bereits auf Serverebene. Und genau dieses Ziel verfolgen wir.

2.2 .htaccess für nginx oder Lighttpd?

Wie bereits erwähnt nutzt Apache das .htaccess Konzept. Sowohl nginx, als auch Lighttpd schlagen allerdings einen anderen Weg ein. Beide Webserver setzen eigene Varianten für den Zugriffsschutz ein, da .htaccess im Allgemeinen als Performance-Killer gilt. Wer den Wechsel zu nginx bzw. Lighttpd wagt muss sich an eine neue Bedienung gewöhnen, wird dann allerdings mit mehr Performance und weniger Ressourcenverbrauch (RAM) belohnt. Gerade im Hinblick auf das Thema SEO spielt die Geschwindigkeit der Seitenauslieferung eine wichtige Rolle.

WordPress auf Schwachstellen und Konfigurationsfehler prüfen

Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:
  • Scan Deiner WordPress-Installation auf Schwachstellen
  • Auswertung und Beurteilung der gefundenen Schwachstellen
  • Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung

Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.

Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen

3. Howto: Apache .htaccess

Hinweis

Damit das Code-Snippet funktioniert, muss euer Hoster die Verwendung von .htaccess Konfigurationsdateien erlaubt haben bzw. die AllowOverride-Direktive (AuthConfig) korrekt gesetzt haben. Funktioniert das Code-Snippet also nicht, dann fragt euren Provider, ob ihr Eingriffe über eine .htaccess vornehmen dürft. Sollte dies nicht der Fall sein, dann wäre ein Wechsel zu einem anderen Hoster angeraten.

Solltet ihr nicht über einen eigenen Server verfügen ist die Wahrscheinlichkeit hoch, dass euer Webhoster auf Apache zurückgreift. Mindestvoraussetzung für die Anleitung ist eine Hosting-Umgebung bei der Zugriff auf das Webverzeichnis besteht. Dann könnt ihr im Normalfall .htaccess Dateien verwenden, um diverse Schutzmaßnahmen zu implementieren. Für den Schutz des Login-Bereichs sind folgende Schritte notwendig:

  • Zunächst wird im Hauptverzeichnis eures Blogs eine Datei mit dem Namen ».htpasswd« angelegt.
  • Anschließend wird die ».htpasswd« Datei mit Inhalt gefüllt. Nutzt dazu den .htpasswd Generator. Wählt einen Usernamen und ein sicheres Passwort (bspw. 20 Zeichen). Als Hashing-Verfahren selektiert ihr »bcrypt« mit einer Cost von »11«. Die Ausgabe des Generators kopiert ihr anschließend in die eben angelegte ».htpasswd« und speichert die Datei ab.
  • Ebenfalls im Hauptverzeichnis legt ihr eine weitere Datei mit dem Namen ».htaccess« an (eventuell ist diese auch schon vorhanden, dann ergänzt ihr sie). Kopiert das untenstehende Code-Snippet und fügt es hinter »# END WordPress«  in die Datei ein.
  • Wichtig: Anschließend müsst ihr noch den genauen Pfad zur User- bzw. Passwortdatei ».htpasswd« unter AuthUserFile anpassen. Falls ihr damit Probleme habt könnt ihr den Pfad mit dem PHP-Schnipsel ermitteln. Wird der Pfad falsch gesetzt, kommt es bspw. zum Internal Server Error 500 oder ähnliches.

3.1 Apache Code-Snippet

Hinweis: Beachtet die Änderungen ab dem Apache 2.4.

# Bis einschließlich Apache 2.3
# Auth protect wp-login.php
<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user
</Files>
# Deny access to important files
<FilesMatch "(\.htaccess|\.htpasswd)">
   Order deny,allow
   Deny from all
</FilesMatch>

# Ab Apache 2.4
# Auth protect wp-login.php
<Files wp-login.php>
   AuthType Basic
   AuthName "Restricted Admin-Area"
   AuthUserFile /pfad/zur/.htpasswd
   Require valid-user
</Files>
# Deny access to important files
<FilesMatch "(\.htaccess|\.htpasswd)">
   Require all denied
</FilesMatch>

Code-Snippet kurz erklärt:

  • Files: Unter Files wird die zu schützende Datei definiert. Erst nach einer erfolgreichen Authentifizierung gegenüber dem Webserver kann die »wp-login.php« aufgerufen werden.
  • AuthType: Mit AuthType Basic wird die Authentifizierungsmethode gegenüber dem Webserver definiert. Bei dieser Methode wird der Username und Passwort unverschlüsselt übertragen – daher solltet ihr den Admin-Bereich immer über eine TLS-verschlüsselte Verbindung aufrufen. Ansonsten könnte jemand die Anmeldedaten mitschneiden. Im zweiten Teil der Artikelserie habe ich das bereits kurz erläutert.
  • AuthName: Der AuthName legt fest wie der geschützte Bereich heißen soll.
  • AuthUserFile: Unter AuthUserFile wird der Pfad zur ».htpasswd« festgelegt.
  • require: Jeder User (valid-user) der in der ».htpasswd« definiert wurde erhält nach Eingabe des korrekten Passworts Zugang zur »Restricted Admin-Area«.
  • FilesMatch: Unter FilesMatch verbieten wird jeglichen Zugriff von außen auf die soeben angelegten Dateien ».htaccess« und ».htpasswd«. Eine Vorsichtssmaßnahme, damit keiner deren Inhalt auslesen kann.

4. Howto: nginx HttpAuthBasicModule

Unter nginx könnt ihr keine .htaccess Dateien verwenden. Stattdessen steht dort mit dem HttpAuthBasicModule ein entsprechendes Pendant für die Benutzerauthentifizierung zur Verfügung.

  • Zunächst legt ihr eine htpasswd Datei an. Im Beispiel wähle ich den Standardpfad für die Konfigurationsdateien von nginx auf einem Debian GNU/Linux System, also »/etc/nginx/htpasswd«.
  • Anschließend wird die »htpasswd« Datei mit Inhalt gefüllt. Nutzt dazu den .htpasswd Generator. Wählt einen Usernamen und ein sicheres Passwort (bspw. 20 Zeichen). Als Hashing-Verfahren selektiert ihr »bcrypt« mit einer Cost von »11«. Die Ausgabe des Generators kopiert ihr anschließend in die eben angelegte »/etc/nginx/htpasswd« und speichert die Datei ab.
  • Kopiert das untenstehende Code-Snippet und fügt es in eure WordPress Server-Konfiguration ein.
  • Einen Restart von nginx nicht vergessen!

4.1 nginx Code-Snippet

# Auth protect wp-login.php
location = /wp-login.php {
   auth_basic "Restricted Admin-Area";
   auth_basic_user_file /etc/nginx/htpasswd;

   include /etc/nginx/conf.d/fastcgi.conf;
}

Hinweis: Das Passwort wird unverschlüsselt übertragen. Daher empfehle ich dringend den Admin-Bereich über eine TLS-verschlüsselte Verbindung aufzurufen. Ansonsten könnte jemand die Anmeldedaten mitschneiden. Im zweiten Teil der Artikelserie habe ich das bereits kurz erläutert.

5. Howto: Lighttpd ModAuth

Unter Lighttpd könnt ihr keine .htaccess Dateien verwenden. Stattdessen steht dort mit ModAuth ein entsprechendes Pendant für die Benutzerauthentifizierung zur Verfügung. Standardmäßig ist das Modul nicht geladen und muss zunächst aktiviert werden. Öffnet dazu die Konfigurationsdatei von Lighttpd »/etc/lighttpd/lighttpd.conf« und entfernt das Kommentarzeichen vor mod_auth.

  • Zunächst legt ihr eine htpasswd Datei an. Im Beispiel wähle ich den Standardpfad für die Konfigurationsdateien von Lighttpd auf einem Debian GNU/Linux System, also »/etc/lighttpd/htpasswd«.
  • Anschließend wird die »htpasswd« Datei mit Inhalt gefüllt. Nutzt dazu den .htpasswd Generator. Wählt einen Usernamen und ein sicheres Passwort (bspw. 20 Zeichen). Als Hashing-Verfahren selektiert ihr »bcrypt« mit einer Cost von »11«. Die Ausgabe des Generators kopiert ihr anschließend in die eben angelegte »/etc/lighttpd/htpasswd« und speichert die Datei ab.
  • Kopiert das untenstehende Code-Snippet und fügt es in eure WordPress Server-Konfiguration ein.
  • Einen Restart von Lighttpd nicht vergessen!

5.1 Lighttpd Code-Snippet

# Auth Config
auth.backend = "htpasswd" 
auth.backend.htpasswd.userfile   = "/etc/lighttpd/htpasswd"

# Auth protect wp-login.php 
$HTTP["url"] == "/wp-login.php" { 
auth.require = ( 
   "" => ( 
      "realm" => "Restricted Admin-Area", 
      "method" => "basic", 
      "require" => "valid-user" 
      ) 
   ) 
}

Hinweis: Das Passwort wird unverschlüsselt übertragen. Daher empfehle ich dringend den Admin-Bereich über eine TLS-verschlüsselte Verbindung aufzurufen. Ansonsten könnte jemand die Anmeldedaten mitschneiden. Im zweiten Teil der Artikelserie habe ich das bereits kurz erläutert.

6. Fazit

Der Zugriffsschutz auf Serverebene ist eine Art Türvorsteher, der ungebetene Gäste auf elegante Art zu verstehen gibt: »Du kommst hier nicht rein!«. Eine äußert praktikable Lösung – denn der Anmeldebereich zum Admin-Bereich stellt eine sensible und schützenswerte Schnittstelle dar.

Auf den ersten Blick wirkt die doppelte Absicherung umständlich, wo doch jetzt zwei Anmeldevorgänge notwendig sind. Einmal auf Serverebene und ein weiterer Anmeldevorgang im eigentlichen WordPress-Backend. Den Schritt zu mehr Sicherheit eurer WordPress-Installation bezahlt ihr mit einem Stück Bequemlichkeit – eine zu verschmerzende Einschränkung.

Mit dem Zugriffsschutz verringert ihr ein weiteres Mal die Wahrscheinlichkeit Opfer einer feindlichen Übernahme zu werden. Im kommenden Artikel werde ich euch weitere Code-Snippets, für die Absicherung eurer WordPress-Installation auf Serverebene, vorstellen.

Bildquellen:

Take a key: „#20617319“, https://de.fotolia.com/id/20617319

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

37 Ergänzungen zu “.htaccess Schutz – WordPress absichern Teil4”

  1. Comment Avatar René sagt:

    Hallo
    Hab versucht, auf dem Apache nach deinen Anweisungen die .htaccess Datei zu schützen. Ging nicht, hab ne Fehlermeldung bekommen. Vielleicht habe ich was nicht verstanden, ev. wie die Pfade aussehen müssen. Wenn ich die beiden Files am gleichen Ort hab, muss ich den Code Snippet noch ändern? Kannst du mir ein Beispiel geben, wie so ein Pfad aussehen könnte?
    Vielen Dank
    René
    ps. Dein Ausführungen sind sehr interessant, vielen Dank.

  2. Comment Avatar Peter sagt:

    Hallo Mike,

    man kann ja den Zugriffschutz auch Serverseitig einrichten. Sollte man zusätzlich zu dem was Du sehr gut beschreibst (danke) noch einen Zugriffschutz auf das Verzeichnis „wp-admin“ legen?

    Danke und Gruß, Peter

    • Comment Avatar Mike Kuketz sagt:

      Hallo Peter,

      es ist nicht ratsam den kompletten wp-admin Ordner mit einem Zugriffsschutz zu versehen. WordPress und einige Plugins greifen bswp. auf AJAX (/wp-admin/admin-ajax.php) zu, was wiederum im /wp-admin Ordner untergebracht ist. Ein Zugriffsschutz unterbindet den öffentlichen Zugriff auf diese Dateien – was bei einigen Plugins keine gute Idee ist.

      Im Prinzip genügt der Schutz der wp-login.php

      Anmerkung: Eventuell wird das WordPress-Team die AJAX-Schnittstelle demnächst aus dem /wp-admin Ordner auslagern. Jedenfalls wäre das wünschenswert.

  3. Comment Avatar David sagt:

    Danke für die umfangreichen Informationen. Was mir noch nicht klar ist, inwieweit das die Besucher einer Webseite beeinträchtigt. Wenn jemand sich auf der Internetseite zum kommentieren einloggen will, der ruft doch auch die wp-login auf.

    Den Besucher können wir aber nicht abweisen. weil der unser SecurityPW nicht kennt.
    Oder habe ich das falsch verstanden?

  4. Comment Avatar David sagt:

    Hallo Mike,

    danke für die Klärung.

    Viele Grüße

  5. Comment Avatar David sagt:

    Ich habe es jetzt getestet. Diese Lösung ist nur für Webseiten nutzbar, bei der sich Benutzer nicht anmelden müssen. Sobald Benutzer sich als Mitglied oder als WordPress-Nutzer anmelden müssen, weil sie zum Beispiel einen Beitrag kommentieren wollen, geht es nicht, da durch den htaccess Schutz, der komplette Login Bereich Passwortgeschützt ist.

    • Comment Avatar Mike Kuketz sagt:

      Danke für das Feedback David.
      Jetzt habe ich deine Problematik bzw. Frage auch verstanden.

      Für Multiuser-Sites ist .htaccess leider keine praktikable Lösung.

  6. Comment Avatar Olli Bartelt sagt:

    Hallo Mike,

    erst mal großes Lob für den Blog. Überhaupt die Nutzer für das Thema Sichergheit zu sensibilisieren ist ja ne wichtige Sache. Und Du hast das echt gut rübergebracht. Alles klar und verständlich, auch für einen Laien wie ich finde.
    Da meine Website selbst innerhalb von 6 Wochen 2x gehackt worden ist bin ich überhaupt auf Deinen Blog gekommen. Habe einiges davon für den Schutz nutzen können. Die Sache mit dem .htaccess klappt leider bei mir nicht. Weiß auch nicht genau woran es liegt. Meine Seite ist bei Strato gehostet. Wenn ich es so mache wie Du beschreibst bekomme ich nach dem FTP Upload die Fehlermeldung 500 Internal Server Error. Benenne ich die .htaccess in .htaccess_old um ist die Seite wieder da, aber natürlich funktioniert dann das Sichern des Admin Bereichs nicht mehr. Evtl. muß ja auch der php Schnipsel an eine bestimmte Stelle in die Datei? Glaub es zwar nicht, aber dazu hast du auch nichts geschrieben.
    Vielleicht hast du da noch nen Tipp.
    Lieben Gruß Olli

    • Comment Avatar Mike Kuketz sagt:

      Error 500 ein „Sammel-Statuscode“ für unerwartete Serverfehler. Kann also im Prinzip alles sein. ;)
      Ich würde mal direkt bei Strato anfragen, ob .htaccess unterstützt wird. Und wenn ja, ob es genügt diese mittels FTP in einem Verzeichnis abzulegen oder was genau zu tun ist.
      Zu Strato kann ich nichts sagen. Eventuell werden .htaccess Dateien über eine Adminstrationsoberfläche verwaltet.

  7. Comment Avatar Maik sagt:

    Hallo Mike,

    danke für den Artikel. Jetzt kann ich mir endlich ein Plugin sparen und bin etwas aufgeklärter.
    Bei dem User hier mit dem Error 500 kann ich mir schon denken, woran es liegt. Er hat wahrscheinlich den Pfad falsch eingetragen, was mir zuerst auch passiert ist.
    Das hättest du eventuell noch etwas ausführlicher erklären müssen. Denn ich habe nur den Namen .htpasswd aus deinem Adressbeispiel gelöscht, den / aber stehen gelassen und auch das Zeichen davor.
    Jetzt klappt es aber.

    Übrigens braucht man diesen PHP Schnipsel gar nicht unbedingt.
    In Filezilla klickt man einfach mit einem rechtsklick auf die Datei und speichert die URL in die Zwischenablage. Schon hat man den Pfad. ;)

    Viele Grüße

  8. Comment Avatar Hans sagt:

    Habe alles so gemacht wie beschrieben. Die Anmeldemaske erscheint, aber ich kann mich trotzdem nicht einloggen.
    Es erscheint immer wieder die Anmeldemaske „Authentifizierung erforderlich.“

    Beste Grüße

    • Comment Avatar Akwasi sagt:

      Erstmal vielen Dank für die hervorragende Artikelserie, auf die ich bei der Suche nach WP Security Plugins gestoßen bin. Gerade rechtzeitig bevor ich mir wahrscheinlich 5 Plugins installiert hätte, in der Annahme damit 5fach abgesichert zu sein :) Leider habe ich dasselbe Problem wie Hans und trotz 1000 facher korrekter Eingabe meiner Login Daten in der Anmeldemaske, lädt diese einfach immer wieder neu und fordert mich zur erneuten Eingabe der Daten auf. Mein Webhoster unterstützt vollen Zugriff auf htaccess. Ich habe auch schon ausprobiert einen neuen Code über den .htpasswd Generator zu erzeugen und in meine htpasswd Datei einzufügen, doch mit demselben Ergebnis. Kannst du mir sagen wo das Problem liegt?

      • Comment Avatar Mike Kuketz sagt:

        Also bisher ist mir Folgendes untergekommen:
        – Probleme mit Sonderzeichen (wie bspw. + # etc.). Versucht mal ein ganz einfaches Passwort zum Testen
        – Leerstellen beim kopieren des Hashwerts oder Probleme mit dem Zeichensatz
        – Ältere Browser Versionen oder bspw. hat auch der Midori Browser hin und wieder Probleme mit der Anmeldemaske über .htaccess. Da werden dann zwei Anmeldefenster geöffnet

  9. Comment Avatar Alexander Gasser sagt:

    Hi Mike,
    möchte mich als WP User mal ganz dick bei dir für die supertollen Tipps zu den mögl. Sicherheitsaktivitäten bedanken.

    Habe schon einiges umgesetzt und voll zufrieden,

    weiterhin viel Erfolg,
    Alexander

  10. Comment Avatar Ingo sagt:

    Hi Mike,

    ein großes Dankeschön für Deine Security-Tips! Sehr gut zu lesen und zu verstehen!

    Folgende Frage: 1und1 hosted meinen WP Blog auf einen Apache. Ich nutze das Plugin „Limit Login Attempts“ und konnte täglich 15 Attacken feststellen. Habe nun eine .htpasswd Hürde eingebaut – das funktioniert auch prima.

    Nur bekomme ich täglich immer noch täglich 1-2 Attacken via Plugin gemeldet. Trotz mehrfach geändertem 158bit Passwort in der .htpasswd. Wie kann das sein?

    Lieben Dank für Deine Info.

    Liebe Grüße
    Ingo

  11. Comment Avatar Michael sagt:

    Hallo Mike, Vielen dank für die Detaillierte Anleitung!
    Doch leider funktioniert diese Lösung bei Strato nicht.
    Eine Zugangsabfrage findet nicht statt, man gelangt direkt zum Admin Login.
    Eine Idee was man bei Strato verändern muss ?

    • Comment Avatar Mike Kuketz sagt:

      Direkt bei Strato anfragen. Eventuell wird dort die htaccess über ein Management-Interface oder dergleichen verwaltet. Möglicherweise bietet auch nicht jedes Web-Hosting Paket die Verwendung von htaccess Befehlen an.

  12. Comment Avatar Andre sagt:

    Hi,
    danke erstmal für die hilfreichen Tips!

    Ich habe auf meiner Seite per .htaccess die wp-login.php geschützt. Allerdings können meine Kunden nun ihren (durch WP Bordmittel) passwortgeschützten Beitrag nicht mehr ohne den Server-Login ansehen.

    Somit geht dieser Ansatz (für mich) zu weit. Was kann ich ändern, damit ich einerseits meinen Admin-Bereich schütze, meine Kunden aber (ohne eigenen User) mit Passwort „ihren“ Beitrag sehen können?

    Danke
    Andre

    • Comment Avatar Mike Kuketz sagt:

      Bei Multi-User bzw. mehreren Login-Accounts ist das keine praktikable Lösung.
      Option 1: Usern die Login-Daten für den .htaccess Schutz mitteilen
      Option 2: .htaccess Schutz wieder entfernen

  13. Comment Avatar Tanja sagt:

    Hallo Mike,
    ich habe jeden deiner Beiträge zum Schutz von WordPress intensiv durchgelesen. Viele nützliche Tipps waren dabei, wovon ich einiges übernehmen konnte und wofür ich sehr dankbar bin. Nur eines habe ich nicht hinbekommen, denn ich finde nicht heraus, wie ich den Quelltext verberge. Die Plugins sind verräterisch. Ich nutze ein komplett Paket über domainfactory und habe mir dort (nach meiner WP Installation) ein SSL Zertifikat installieren lassen, wobei ich dieses noch nicht aktiviert habe, da ich mir noch unsicher bin. Rufe ich meine Seite über https auf, dann wird mein css nicht übernommen, welche ich über den import vom Parent-Theme auf mein Child-Theme importiere. Die htacess müsste ich bestimmt ebenfalls anpassen. Ebenso wie die ganzen Verlinkungen und Tabellen. Wahrscheinlich muss es https. im Pfad heißen und nicht http. Nun überlege ich mit SSL lediglich einen weiteren Login Schutz einzurichten. Aber da weiß ich noch nicht wie…! Die htaccess habe ich drin. Das funktioniert alles super. Danke schön! Ein paar angesprochene Themen passen nicht in meinen Kommentar, aber vielleicht kannst du mir einen Tipp geben, was ich sonst noch beachten muss.

    Zu deinem Beitrag Security Plugins: da werde ich mir Snitch und ich glaube auch AntiVirus installieren. Limit Login Attemps habe ich ebenfalls installiert, scheint ja ein sehr beliebtes Plugin zu sein. SEO verunsichert mich, nachdem ich deine Zeilen gelesen habe. Zusätzlich habe ich die functions von Sergej M. übernommen. Um die Datenbank zu sichern habe ich BackWPup installiert. Nach jedem Auftrag muss ich allerdings ins FTP um das WpupBackUp zu löschen, nachdem ich sie geladen habe. Ist doch sicherer, oder? Insgesamt habe ich nur wenige Plugins installiert. Hmm, vielleicht bin ich zu Paranoid. :) … mehr aber ein wenig unerfahren. Technisch versiert, wenn es gut erklärt ist. Deine Beiträge sind sehr gut erklärt.

    LG,
    Tanja

  14. Comment Avatar forex sagt:

    Vielen dank für die Anleitung.

  15. Comment Avatar Rudolf Fiedler sagt:

    Vielen Dank für den ausgezeichneten Artikel mit viel Mehrwert.
    Ich habe bei meinen Kunden leider die Erfhrung gemacht, daß trotz korrekt eingestellter Dateiberechtigungen und aktuellen WordPressversionen die Angreifer immer öfter durchkommen und ihre Schadcodes auf der Seite deponieren und ausführen.
    Deswegen habe ich jetzt mal testweise bei einigen der Kunden direkt in der Apache-Konfiguration die Dateien abzusichern. (php-Files unterhalb wp-config und wp-includes, wp-admin-Bereich mit Passwortabsicherung. Bin gespannt, ob die Anzahl der erfolgreichen Angriffe jetzt abnimmt.

    Rudolf Fiedler

  16. Comment Avatar Dieter Olowson sagt:

    Hallo Mike,
    wenn ich meine Webseite (wp-admin) mit .htaccess absichere, habe ich eine Einschränkung in meiner WordPress Installation.
    Einzelne Seiten im WordPress können über „Sichtbarkeit“ mit einem Passwort abgesichert werden. Wenn ich dieses mache, kommt beim Seitenaufruf auch die .htaccess-Abfrage. Der Gast auf der Webseite soll aber nur das Passwort der einzelnen Seite eingeben müssen.
    Hast Du eine Lösung?
    Vielen Dank.
    Dieter

  17. Comment Avatar Werni sagt:

    Schöne Anleitung, vielen Dank.
    Eine Sache würde mich mal interessieren, wie kann sich jemand versuchen anzumelden wenn die wp-login nicht verfügbar ist?
    Ich habe schon seit längerem Limit Login Attemps installiert und bekomme ständig Mitteilungen über versuchte Logins, dabei habe ich u.a. die wp-login nicht nur zusätzlich umbenannt, sondern auch testweise entfernt. Die htacces funktioniert auch problemlos. Die Meldungen kommen aber trotzdem und werden auch im Log erfasst.
    Aber wie geht das ohne die wp-login?
    Viele Grüße!

  18. Comment Avatar Maik sagt:

    Auch wenn es mir bereits bekannt war: Danke für die Erinnerung. Ich erwische mich leider ab und zu den htaccess-Schutz aus Bequemlichkeit nicht zu implementieren. :/

    Den Pfad für die .htpasswd kann man lustigerweise bei den meisten Blogs auch herausfinden, indem man kurz in die „Angreiferrolle“ wechselt: Dank Full Path Disclosure. WP geht sehr großzügig mit Fehlermeldungen um, die den vollständigen Pfad enthalten (bspw. indem man die /wp-includes/rss.php im Browser aufruft). Ich weiß nicht, ob du das Verhindern von FPD in deiner Artikelserie erläuterst – es wäre jedenfalls eine Erwähnung wert.

    Super Blog übrigens. :)

  19. Comment Avatar Andy sagt:

    Eine schön einfache Beschreibung. Ich habe grade anhand Eurer Anleitung den Zugang zum Adminbereich abgesichert, weil ich potentielle Angreifer endlich von vorne herein aussperren möchte. In nur wenigen Tagen hatte ich mehr als 300 Angreifer, die sich mit dem (nicht vorhandenen) Benutzernamen „Admin“ einloggen wollten. Natürlich habe ich sichere Passworte, sowohl im Adminbereich, als auch um in diesen Bereich überhaupt hineingelassen zu werden, gewählt. So ist es dann zumindest den Scriptkiddies ein Stück schwerer gemacht, in Bereiche des Blogs einzudringen, die nicht für die Öffentlichkeit bestimmt sind.

  20. Comment Avatar dirk sagt:

    Ich habe bereits vor ein paar Monaten den Schutz mittels httacces eingebaut, musste aber feststellen, dass dann (mittels wordpress) per Kennwort geschützte Seiten nicht mehr erreichbar sind.
    Ich habe ein paar Artikel/Beiträge, die passwortgeschützt sind, wobei die entspr. Funktion von WordPress genutzt wird. Möchte man jetzt auch diese Seiten zugreifen, wird erst dieses Passwort abgefragt, anschließend Benutzername und Kennwort wie mittels htacces eingerichtet – letzteres ist natürlich nicht gewünscht.
    Warum ist das so? die entspr. Seiten/Beiträge liegen zum einen in anderen Ordnern und geschützt habe ich – wie im Beispiel angegeben – nur ~Files wp-login.php~

    Ist das das selbe Problem, wie hier schon mehrfach in den Kommentaren beschrieben? Habe ich keine andere Möglichkeite, als den Schutz wieder zu entfernen?

    • Comment Avatar Mike Kuketz sagt:

      Der WordPress Passwortschutz kollidiert mit der .htaccess Variante bzw. dem Schutz des Admin-Bereichs. WordPress nutzt für passwortgeschützte Seiten 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 eine Username / Passwortabfrage erscheint.

  21. Comment Avatar Tom sagt:

    Hallo Mike,

    danke für deine Anleitung, die es auch einem Nicht-Experten wie mir möglich machte, den Zugriffschschutz via htaccess einzurichten. Das habe ich vor etwa einem halben Jahr gemacht und seitdem fühlte ich mich etwas sicherer.
    Jetzt, seit gestern, zeigt mir mein Security-Plugin von WordPress wieder diverse Login-Versuche nach der BruteForce-Methode an. Derweil habe ich am Zugriffsschutz nichts geändert. Dass jemand meine htaccess-Zugangsdaten herausgefunden hat, halte ich für unwahrscheinlich. Hast du sonst noch eine Idee, woran das liegen könnte? Kann man sich vielleicht noch anders einloggen als über die wp-login.php?

    Danke!

  22. Comment Avatar Stephan sagt:

    Top Tutorial und für den „Otto-Normal-Wordpressler“ genau richtig. Um den htaccess Schutz für das Backend kommt man eigentlich heutzutage kaum noch rum. Spätestens mit dem ersten Blick ins access_log nach einem Angriff sollte bei den meisten klar werden, wie beliebt WordPressinstallationen für Angriffe geworden sind.

    Inzwischen werden sogar die Usernamen der Autoren vor dem Angriff ausgelesen (/?author=1 usw.) – der Loginname steht dann an letzter Stelle in der URL, damit hat der Angreifer schon mal 50% geschafft. Die ID wird wohl kaum jemand in der DB ändern.

  23. Comment Avatar Monika sagt:

    Hallo,
    also als WordPress Anfänger bin ich sehr dankbar über diese Artikelreihe! Klar, verständlich und seeeehr hilfreich. Vielen vielen Dank!
    Ich habe das Problem, dass ich durch Einsatz wpcerber erst auf die Angriffe aufmerksam wurde. Ein paar der Tipps hatte ich schon aus anderen Foren gelesen und berücksichtigt und aktuell ist noch keiner eingedrungen. Aber ich will natürlich verifizieren, dass ich als Anfänger noch etwas tun kann. Insbesondere Einsatz Plugins und htaccess haben mich jetzt aufgeschreckt.

    Ich hoste bei 1und1 ‚managed‘ (die sichern die Datenbank). Habe Kommentare global ausgeschaltet (über ein Plugin *schäm*), aber einen geschützten internen Bereich. Nutze ein umfangreiches Theme und ein paar Plugins, die es mir Anfänger einfacher gemacht haben. Und ich habe eine eigene Login-Seite gebaut, um diese dem Theme anzupassen.

    Bei mir gibt es die .htaccess schon (vermutlich vom Theme). Wie binde ich jetzt den Schutz für wp-admin ein? Bzw. brauche ich das noch?

    Vielen Dank für all die Mühe und Aufmerksamkeit!

    @Richard, leider kann ich als Anfänger nichts raten. Ich wünsche Dir aber Glück bei der Beseitigung!

  24. Comment Avatar Klaus sagt:

    Hallo,
    vielen Dank für den Artikel und den Code. Ich habe mehrere Blogs mit WordPress Installationen, ausnahmslos auf Apache Servern. Leider funktioniert der .htaccess Code auf einigen Servern nicht. Wenn man den Code in die .htacces hineinkopiert und hochläd, kann man sich bei WP weder abmelden, noch anmelden. Es erscheint auch keine Passwortabfrage.

    Hat jemand eine Idee, wo der Hase begraben liegt?
    Danke
    Gruß Klaus

    P.S.:
    Im Bezug auf meinen obigen Post habe ich eine Diskussion in einem Apache Forum eröffnet. Vielleicht interessiert sich jemand für die Thematik.
    https://community.apachefriends.org/f/viewtopic.php?f=5&t=72756

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.