Du kommst hier nicht rein!

In jüngs­ter Zeit gab es wie­der ver­mehrt Ver­su­che, das Blog zu hacken. Das ist zwar ziem­lich aus­sichts­los, da ein gutes, lan­ges, nicht errat­ba­res Pass­wort schon eine recht hohe Hür­de dar­stellt. Und wenn man das PW nicht kennt, nützt es dem Angrei­fer auch wenig, wenn er den User­na­men  des Admins raus­fin­det – was bei Word­Press erstaun­li­cher­wei­se immer noch ein Kin­der­spiel ist.

Wie auch immer – ich bin es leid, alle nase­lang zu sehen, wie sich da irgend­wer aus Sankt Peters­burg, Mos­kau, Minsk, Peking oder Pitts­burgh am unbe­fug­ten Ein­drin­gen ver­sucht, ent­we­der per­sön­lich oder per Script-Bot. Daher habe ich den Admin-Zugang nun mit einer zusätz­li­chen Schran­ke versehen.

Und das geht so.^[1]Für die­sen Post waren die­se bei­den Tuto­ri­als sehr hilf­reich: So schützt du dei­nen Word­Press-Log­in und Wie du den Word­Press Log­in schüt­zen kannst

Man erstellt zusätz­lich zur exis­tie­ren­den Datei .htaccess im Ord­ner der WP-Instal­la­ti­on eine neue Datei namens .htpasswd. Genau­er gesagt erstellt man sie zunächst lokal auf dem eige­nen Rech­ner, erstellt eine Sicher­heits­ko­pie, edi­tiert sie dort und lädt sie anschlie­ßend per FTP wie­der hoch.^[2]Da gibt es hau­fen­wei­se Mög­lich­kei­ten, das zu bewerk­stel­li­gen. Daher kann ich hier kei­nen Exkurs zum The­ma FTP anbie­ten. Aber mein Tipp – für Win­dows­nut­zer – lau­tet: Total Com­man­der. Das ist seit … Con­ti­nue rea­ding

Dann geht man auf die­se (ver­trau­ens­wür­di­ge) Sei­te: HTPass­word-Gene­ra­tor. Dort lässt man sich den Inhalt der .htpasswd erzeugen.

Dazu gibt man einen Namen ein (nicht iden­tisch mit dem Admin der WP-Instal­la­ti­on, die wir schüt­zen wol­len) und ein Pass­wort (eben­falls ein völ­lig neu­es). Ich las­se die­ses kryp­ti­sche Pass­wort von mei­nem Schlüs­sel­safe Kee­pass generieren.

Nach dem Druck auf den But­ton »Crea­te .htpass­word file« erhält man eine Zei­chen­ket­te, die in die lokal erstell­te Datei .htpasswd kopiert wird. Sieht so aus wie das hier: maxmuster:$apr1$YkuGOcIp$t6XNHNN8vZd4QRhqylfZA.

Spei­chern und hochladen.

Damit ist der ers­te Teil erledigt.

Nun muss Word­Press noch erfah­ren, dass es die­se Datei .htpasswd gibt und es sie benut­zen soll, um dem eigent­li­chen Log­in eine wei­te­re Pass­wort­ab­fra­ge vor­zu­schal­ten. Das ist ja der Sinn der Übung. Die­ser Schritt bedeu­tet zwar ein klit­ze­klei­nes biss­chen mehr Umstand, aber das ist ver­nach­läs­sig­bar. Außer­dem kann man ja auch die­sen neu­en Log­in wie­der in einem Pass­wort-Safe wie Kee­pass hin­ter­le­gen und per Tas­ten­druck (Glo­ba­les Auto-Type) in die ent­spre­chen­den Mas­ken ein­fü­gen las­sen. Wirk­lich sehr komfortabel.

Nun muss die Datei .htaccess mit einem Text­edi­tor – ich emp­feh­le note­pad++ – bear­bei­tet wer­den. Auch die­se Datei wird tem­po­rär per FTP her­un­ter­ge­la­den und lokal bearbeitet.

Wahr­schein­lich ste­hen dort schon eini­ge Ein­trä­ge drin – zum Bei­spiel von Cache-Plug­ins. Man fügt hinzu:

# Extra-Schutz wp-login.php
<Files wp-login.php>
AuthName "Protected Admin-Area"
AuthType Basic
AuthUserFile /der/genaue/pfad/zu/wp/.htpasswd
Require valid-user
</Files>

Bit­te nicht stumpf über­neh­men, denn in der dritt­letz­ten Zei­le muss ja der tat­säch­li­che Pfad der Word­Press-Instal­la­ti­on ein­ge­tra­gen wer­den. Wie man den fin­det, kann man zum Bei­spiel hier oder auch hier nach­le­sen. Da kommt dann sowas raus wie /home/www/domainname/wp/.

Nun soll­te das mit dem dop­pel­ten Log­in bei Word­Press klap­pen. Wenn nicht, ist sicher irgend­wo ein Tip­per pas­siert oder der abso­lu­te Pfad stimmt nicht. Not­falls las­sen sich auch alle Ände­run­gen leicht rück­gän­gig machen. Ent­we­der die Sicher­heits­ko­pie der .htaccess zurück­spie­len. Oder die .htpasswd löschen und die .htaccess auf dem Ser­ver direkt edi­tie­ren und in den vor­he­ri­gen Zustand bringen.

Zusätz­lich emp­fiehlt es sich, wich­ti­ge (sicher­heits­re­le­van­te) Datei­en der Word­Press-Instal­la­ti­on zu schützen.

Dazu fügt man in der Datei .htaccess die­sen drei­tei­li­gen Block ein:

# Zugriff verweigern
<FilesMatch "(\.htaccess|\.htpasswd)">
Order deny,allow
Deny from all
</FilesMatch>
# Konfigurationsdatei schützen
<files wp-config.php>
Order allow,deny
Deny from all
</files>
# Schnittstelle abstellen
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Mit dem letz­ten Ein­trag ab # Schnittstelle... wird Script-Bots der Zugang ver­wehrt. Nach­teil: Ping­backs gehen dann auch nicht mehr. Das ist aber mei­nes Erach­tens nach­ran­gig. Hier ist das Pro­blem schön beschrieben.

Es kann nicht scha­den, zusätz­lich ein Plug­in wie Limit Log­in Attempts Rel­oa­ded zu installieren.

Alles in allem: wenig Arbeit für viel mehr Sicher­heit. Ich fin­de, das ist ein guter Deal.

Update 21. Mai

Zwei Wochen später.

Alles klar? 😉