Ein einfacher Tipp für mehr Sicherheit und Robustheit von WordPress

Oder: von einem der auszog, um WordPress-Installationen gegenüber Brute Force Attacken ein wenig robuster zu machen.

In meinen beiden Blogposts Spamschutz für WordPress auf  Serverebene und Spamschutz für WordPress mit Fail2Ban habe ich bereits einige Features hierfür vorgestellt.
Um die dort beschriebenen Dinge umsetzen zu können,  muss man zumindest einen „Managed Server“, am besten einen eigenen „Root Server“ betreiben.

Heute möchte ich gerne alle ansprechen, die eine WordPress-Installation betreuen. Egal ob bei einem Webhoster, oder auf einem Root Server.

Neben einer kurzen Aufzählung von „üblichen“ Tipps möchte ich etwas zum Thema „weniger ist mehr“ berichten und am Ende auch auf einen Stolperstein – aus dem Leben gegriffen – in Bezug auf eine Datei namens admin-ajax.php hinweisen.

Achtung … provokant! 🙂

Was sind die „üblichen“ Sicherheits-Tipps für WordPress?

• scheue  den User „admin“ wie der Teufel das Weihwasser. Auf jeden Fall !
• gib bei der Installation von WordPress immer einen uniquen/random Tabellenpräfix für die MySQL Datenbank an. Zum Warum: klick!
• nutze auf jeden Fall  WordPress Secret Keys und salze diese hiermit. Ein Muss!
• halte Deine Plugins und Deine WordPress-Installation stets aktuell. Der Klassiker!
• nutze eine Zwei-Faktor Authentifizierung für Deinen Admin Bereich. Nett,  man benötigt aber immer ein „Zusatzgerät“, daher nice to have.
• benutze ein Plugin um mehrfach falsche Loginversuche im Admin Bereich zu protokollieren und zu sperren. 
• benutze ein starkes Passwort. Einfach aber wirkungsvoll.
• benutze für jeden Login ein eigenes Passwort. Generell zu empfehlen.
• nutze Sicheheitsplugins. Ok, Acunetix WP Security und Wordfence Security sind zu empfehlen
• etc.
• schütze Deine wp-login.php Datei, mit einfachen Webserver Bordmitteln. What ?

Was sind einfache Webserver Bordmittel und warum sollte „weniger mehr sein“ ?

Oder: warum all diese „limit-login*/limit-lockdown*/ich sperr dich nach 3 Fehlversuchen aus“ Plugins meiner Meinung nach unnütz sind.
Antwort:  es geht einfacher und vor allem „billiger“! Billiger aus IT- und monetärer Sicht.
Auf den Apache-Webserver bezogen spreche ich von .htaccess und .htpasswd.

„Ja, ist ja nett, aber ein alter Hut.“ werdet ihr nun denken. Mag sein, aber alte Hüte haben manchmal wirklich  ihre Vorzüge.
ScriptKiddies und Botnetze, den Begriff des „Hackers“ möchte ich hier absichtlich außen vor lassen, sind in erster Linie darauf erpicht, Webseiteninhalte oder Dienste in ihrem Sinne zu mißbrauchen oder zu manipulieren.
Neben der Ausnutzung von bekannten Exploids von Betriebssystemen, Webservern, PHP, WordPress oder WordPress-Plugins werden oftmals Brute-Force Attacken auf  die wp-login.php gefahren, um administrativen Zugriff zu erhalten, oder den Webserver mittels Überlast bis hin zu einer Fehlfunktion zu penetrieren.

Fakt ist nunmal: bleibt ein Bot oder eine BruteForce Attacke erst bei einem WordPress Plugin hängen, hat der Webserver, WordPress, der PHP-Interpreter und auch die MySQL Datenbank bereits einiges an Arbeit geleistet und wertvolle Ressourcen verbraucht; Ressourcen, die sicher besser in die Auslieferung von Webinhalten investiert gewesen wären.

Bei einem aktiven „.htaccess / .htpasswd Schutz“ der wp-login.php  bleiben solche „Angriffe“ bereits auf Webserverebene – und nur dort – hängen. Das Spart bei den anderen, oben genannten Ressourcen einiges ein.
Wie im realen Leben, sind auch digitale Ressourcen endlich; das gilt insbesondere für Shared Hosting Umgebungen.
Um bei der Realität zu bleiben: so sieht meine .htaccess dafür aus

Obacht, Stolperstein beim Schutz des wp-admin Ordners 🙂

Ein Beispie: vor nicht all zu langer Zeit erreichte mich eine Mail, mit der Bitte um Hilfe. Beim Aufruf bestimmter  Seiten auf einem Webportal kam es reproduzierbar immer wieder zu einer Passwortabfrage. Mit Firebug war das Problem jedoch schnell eingegrenzt.
Grund der Problematik: der komplette wp-admin Ordner war mittels .htaccess und .htpasswd geschützt.  Auf den ersten Blick  sicherlich nichts verwerfliches, im Grunde jedoch nur die zweitbeste von zwei Ideen. Ich möchte auch begründen warum.

Erstens: Ruft man die  URL  „http://deine-domain.de/wp-admin“ auf, dann wird man per Redirect über die wp-login.php zum Anmeldeformular geleitet. Wir erinnern uns: die wp-login.php hatten wir schon per Filedirektive geschützt. Den Ordner wp-admin nochmals zu schützen wäre also doppelt gemoppelt.

Zweitens: Im Ordner wp-admin befindet sich eine Datei Namens admin-ajax.php. Diese wurde von den WordPress Entwicklern irgendwann einmal eingeführt, um so banale Dinge wie Hooks und Script-Registierungen im Backend  zu handeln. Inzwischen scheint die Funktionalität dieser Datei gewachsen zu sein. Offensichtlich bietet sie viele Ajax-Funktionalitäten an. Diese haben wohl bei einigen Plugin-Entwicklern den Spieltrieb geweckt: warum Ajax-Funktionalitäten in das eigene Plugin einbauen, wenn WordPress so etwas schon frei Haus liefert?
Eine schlechte Idee; schlecht von „beiden Seiten“: ein Plugin sollte keine Dateien / API  in einem administrativen Backend-Ordner aufrufen, eine zentrale Ajax Datei / API sollte vielleicht nicht in einem administrativen Backend-Ordner implementiert sein.

Was passierte nun in obigem Beispiel, mit dem komplett geschützten  wp-admin Ordner ?

Nun, der gemeine User hat mit dem Passwortschutz des wp-admin Ordners eigentlich nichts am Hut, er möchte einfach nur eine Webseite absurfen. Blöd nur, wenn ein Plugin der besuchten Webseite die Ajax-Funktionalität der admin-ajax.php Datei nutzt. Damit wird Webseiten Besucher zu eine User- Passworteingabe genötigt; wovon dieser natürlich keine Ahnung hat und völlig verschreckt das Weite sucht. Mist, schon wieder ein Besucher weniger,

Möchte man das vermeiden, entfernt man den .htaccess / .htpasswd Schutz aus dem wp-admin Ordner und benutzt besser die obige wp-login.phpFiledirektive.
Alternativ kann man die .htaccess Datei im wp-admin Ordner auch wie folgt pimpen, um diesen Fehler zu beheben: