Auf einer kleinen WordPress-Website ist Sicherheit kein Projekt: Sie ist eine Basis, die man einmal sauber legt und danach nicht mehr anfasst. Drei Bausteine, ein halber Arbeitstag Einrichtung, und nahezu alle automatisierten Angriffe verpuffen. Hier ist diese Basis, in der Reihenfolge der Umsetzung.
Warum eine minimale Basis und keine Festung
Das meiste, was eine kleine WordPress-Installation trifft, ist automatisiertes Rauschen: Bots, die wp-login.php aufrufen, Scans nach bekannten Schwachstellen, Versuche der Nutzerenumeration über die REST-API. Keiner dieser Angriffe zielt auf eine bestimmte Website — sie durchkämmen das gesamte Web. Die folgende Basis schneidet dieses Volumen ab. Der Rest — gezielter Angriff, unbekannte Lücke in einer bestimmten Erweiterung — lässt sich nicht mit drei Konfigurationszeilen lösen und betrifft eine Visitenkarten-Website praktisch nie.
Die beste Härtung ist nicht die, die alles blockiert: Es ist die, die sechs Monate später noch steht und gepflegt wird.
Baustein 1 — Wordfence, die Anwendungsebene
Wordfence schützt mehr als fünf Millionen Websites, und die kostenlose Version deckt das Wesentliche ab: Application Firewall, Malware-Scanner, der Kerndateien mit dem offiziellen Repository abgleicht, Ratenbegrenzung, Brute-Force-Schutz und Zwei-Faktor-Authentifizierung.
Minimale Einstellungen nach der Installation:
- Die Firewall in den Modus Extended Protection versetzen, der vor PHP läuft und nicht als einfaches Plug-in.
- Zwei-Faktor-Authentifizierung für alle Administratorkonten aktivieren.
- Blockade der Nutzerenumeration aktivieren und die WordPress-Version verbergen.
- E-Mail-Benachrichtigungen auf kritische Meldungen beschränken: Ein Dauerstrom an Hinweisen wird irgendwann nicht mehr gelesen.
Baustein 2 — Fail2ban, die Netzwerkebene
Wordfence wirkt auf PHP-Ebene. Fail2ban wirkt davor, auf Serverebene: Es liest die Nginx-Logs und sperrt die IP-Adresse in der System-Firewall, sobald sich ein Angriffsmuster wiederholt. Der Angreifer verbraucht dann keine PHP-Ressourcen mehr.
# /etc/fail2ban/filter.d/wp-login.conf
[Definition]
failregex = ^<HOST> -.*"POST /wp-login.php
^<HOST> -.*"POST /xmlrpc.php
ignoreregex =# /etc/fail2ban/jail.d/wordpress.conf
[wp-login]
enabled = true
filter = wp-login
logpath = /home/*/logs/nginx/access.log
port = http,https
maxretry = 3
findtime = 3600
bantime = 3600CF-Connecting-IP über das RealIP-Modul) muss vor dem Scharfschalten geprüft werden.Der Filter wird stets vor der Aktivierung getestet:
fail2ban-regex /home/meineseite/logs/nginx/access.log
/etc/fail2ban/filter.d/wp-login.confBaustein 3 — Anwendungspasswörter
Anwendungspasswörter, in WordPress nativ vorhanden, geben einem Skript, einer Integration oder einer automatisierten Routine eine widerrufbare Kennung, getrennt vom Hauptpasswort des Kontos. Jede Integration erhält ihre eigene; ihr Widerruf betrifft keine andere.
Daraus folgen zwei Betriebsregeln: Ein Anwendungspasswort nie für mehrere Integrationen wiederverwenden, und prüfen, dass keine Sicherheitserweiterung sie global deaktiviert — Wordfence bietet diese Einstellung an, und ihre Aktivierung kappt still alle REST-Integrationen der Website.
Ergänzungen ohne Kosten
| Maßnahme | Wirkung |
|---|---|
Sicherheits-Header (X-Content-Type-Options, Referrer-Policy, Permissions-Policy) | Kleinere Angriffsfläche im Browser |
| Dateibearbeitung im Backend deaktivieren | Verhindert Codeänderungen aus einem kompromittierten Konto |
| Namentliche Administratorkonten, kein Benutzer „admin“ | Entfernt das Standardziel von Brute-Force-Angriffen |
| Verschlüsselte Sicherungen außerhalb des Produktivservers | Die einzige Maßnahme, die nach einem Vorfall wirklich repariert |
Was bleibt
Drei Bausteine decken nahezu das gesamte reale Risiko einer kleinen Website ab: eine Anwendungsebene, eine Netzwerkebene und widerrufbare Kennungen für Integrationen. Jede weitere Maßnahme misst sich an einer einzigen Frage: Wird sie in sechs Monaten noch gepflegt?
Diese Basis rolle ich auf den rund dreißig Websites aus, die ich selbst hoste, hinter CloudPanel und Cloudflare. Der Vorfall, der mich am meisten gekostet hat, war kein Einbruch: Es war die Wordfence-Einstellung, die Anwendungspasswörter deaktiviert und ohne jede Warnung alle meine REST-Routinen gekappt hat. — Simon Janvier
