WordPress – absichern mit CrowdSec

WordPress ist das beliebteste Ziel für automatisierte Angriffe im Netz, weshalb ein ungeschütztes System oft schon nach wenigen Minuten von Bots gescannt wird. Anstatt das CMS jedoch mit ressourcenhungrigen Security-Plugins zu belasten, wehren wir Angreifer mit CrowdSec direkt an der Haustür unseres Traefik-Proxys ab. Dafür etablieren wir einen zweigleisigen Schutz: Die klassische Log-Analyse sperrt IPs automatisch aus, sobald sie Brute-Force-Attacken auf den Login versuchen. Gleichzeitig analysiert die AppSec-Komponente (WAF) jeden HTTP-Request in Echtzeit und blockiert gezielte Exploits, wie manipulierte PHP-Uploads, zuverlässig durch Virtual Patching. In diesem Beitrag zeige ich euch, wie schnell sich dieser doppelte Schutz in unser bestehendes Docker-Setup integrieren lässt.

Datum	Änderung
11.08.2022	Erstellung dieser Anleitung
05.03.2023	Kapitel 2 wurde hinzufügt
29.05.2023	Anpassung an neue Traefik Anleitung, Kapitel 4 hinzugefügt
26.11.2023	Kapitel 6 hinzugefügt
05.01.2024	Anpassungen an Traefik v3
04.03.2026	Komplette Überarbeitung, AppSec hinzugefügt

Inhaltsverzeichnis

1. Voraussetzung

Diese Anleitung basiert auf folgenden Anleitungen

2. Arten der Absicherung

Es gibt 2 Arten WordPress abzusichern
Klassische Art: liest Logs aus und blockiert beispielsweise Bruteforce Angriffe
AppSec: Analysiert den Datenverkehr in Echtzeit und blockiert Exploits etc.

Wir werden hier beide Arten installieren.

Bei diesem Inhalt handelt es sich um exklusiven Content für Community Plus Mitglieder und Supporter.

Bitte logge dich mit deinem Account ein um den Inhalt zu sehen.

5. Überprüfen

Nun überprüfen wir, ob alles korrekt geklappt hat. Dazu gebt ihr folgendes ein:

docker exec crowdsec cscli collections listCode-Sprache: PHP (php)

Die Ausgabe sollte in etwa so aussehen. Man sieht, dass “crowdsecurity/appsec-wordpress” und “crowdsecurity/wordpress” (klassische Art) geladen sind.

-------------------------------------------------------------------------------------------------------------------------------------------------
 COLLECTIONS
-------------------------------------------------------------------------------------------------------------------------------------------------
 Name                                                 📦 Status    Version  Local Path
-------------------------------------------------------------------------------------------------------------------------------------------------
 crowdsecurity/apache2                                ✔️  enabled  0.1      /etc/crowdsec/collections/apache2.yaml
 crowdsecurity/appsec-crs                             ✔️  enabled  0.7      /etc/crowdsec/collections/appsec-crs.yaml
 crowdsecurity/appsec-crs-exclusion-plugin-wordpress  ✔️  enabled  0.1      /etc/crowdsec/collections/appsec-crs-exclusion-plugin-wordpress.yaml
 crowdsecurity/appsec-generic-rules                   ✔️  enabled  1.0      /etc/crowdsec/collections/appsec-generic-rules.yaml
 crowdsecurity/appsec-virtual-patching                ✔️  enabled  13.6     /etc/crowdsec/collections/appsec-virtual-patching.yaml
 crowdsecurity/appsec-wordpress                       ✔️  enabled  0.6      /etc/crowdsec/collections/appsec-wordpress.yaml
 crowdsecurity/base-http-scenarios                    ✔️  enabled  1.2      /etc/crowdsec/collections/base-http-scenarios.yaml
 crowdsecurity/http-cve                               ✔️  enabled  2.9      /etc/crowdsec/collections/http-cve.yaml
 crowdsecurity/linux                                  ✔️  enabled  0.3      /etc/crowdsec/collections/linux.yaml
 crowdsecurity/sshd                                   ✔️  enabled  0.8      /etc/crowdsec/collections/sshd.yaml
 crowdsecurity/traefik                                ✔️  enabled  0.1      /etc/crowdsec/collections/traefik.yaml
 crowdsecurity/whitelist-good-actors                  ✔️  enabled  0.2      /etc/crowdsec/collections/whitelist-good-actors.yaml
 crowdsecurity/wordpress                              ✔️  enabled  0.5      /etc/crowdsec/collections/wordpress.yaml
-------------------------------------------------------------------------------------------------------------------------------------------------

Autor

Christian

Während meines Studiums bin ich auf das Thema "Linux Server" gestoßen.

Viele der Anleitungen im Internet waren jedoch nicht sonderlich hilfreich, da sie veraltet waren.

Dies war die Geburt des Projekts goneuland, welches nun seit 2016 online ist und stetig um neue Anleitungen erweitert wird.

Da es sich um ein Community Projekt handelt, kann jeder ein aktiver Teil von goneuland sein und selbst Anregungen sowie eigene Anleitungen beitragen.

Alle Beiträge ansehen

Das könnte dich auch interessieren:

24 Kommentare

Neueste

Älteste Am besten besten Bewertet

Inline Feedbacks

View all comments

hothey(@hothey)

1 Jahr zuvor

#5691

Hallo,
ich bin ja mega begeistert, von euren Anleitungen. Hab auch meine WP Seiten mit Redis und Traefik und Crowdsec verheiratet und es läuft wie ne EINS 🙂

DANKE!!!!!

Und: Wie kann ich denn jetzt noch das Login (wp-admin und wp-login.php) durch ein Sicherheitslayer schützen? Ich stelle mir da ein zentrales Login vor, dass abgefragt wird, sobald jemand auf definierte Pfade zugreifen will. (am besten mit 2FA. Nur eben so, dass ich es ein mal eingebe und danach auf allen WP-Instanzen auf die gesicherten Bereiche zugreifen kann – und wenn jemand mist eingibt, -> ab auf die Crowdsec Liste)

Ist das mit einfachen Schritte zu erreichen? Ich bin doch sicherlich nicht der Erste, der sich da noch einen erweiterten Schutz wünscht und keinen Bock mehr auf .htaccess Basic Auth hat 😉

Die Anleitung zur Absicherung mit Authelia habe ich gefunden (https://goneuland.de/authelia-zweifaktor-authentifizierung-mittels-docker-compose-und-traefik-installieren/) aber noch nicht verstanden, wie und ob ich damit nur Domains oder auch Pfade absichern könnte…

Und die nächste Ergänzungsfrage wäre dann: Lässt sich Authelia auch mit der WP Auth verheiraten, dass das Login bei Authelia reicht und kein zweites Login in WP mehr benötigt wird?

Liebe Grüße – Holger.

Last edited 1 Jahr zuvor by hothey

Antworten anzeigen (1)

hardy(@hardy)

2 Jahre zuvor

#3925

Hallo Leute,

Verständnisfrage: Wenn alles nach dieser Anleitung fehlerfrei funktioniert, dann müsste doch jemand, der mehrmals versucht sich auf meiner WordPresseite einzuloggen, gebannt werden oder nicht? Sonst macht doch Crowdsec keinen Sinn mit WordPress.

Ein Freund von mir hat zum testen versucht sich mit falschen Zugangsdaten einzuloggen, wurde aber nicht gebannt!

VG Hardy

Antworten anzeigen (4)

Phoenyx(@phoenyx)

3 Jahre zuvor

#2913

Hallo,

erstmal danke für die Anleitung, doch egal was ich mache sie funktioniert nicht.

Wenn ich das Plugin aktiviere und wie oben angegeben: http://crowdsec:8080 angebe bekomme ich einen Fehler angezeigt: Unexpected HTTP call Failure

Wenn ich anstatt crowdsec die IP des Containers angebe ( in meinem fall befinden sich die Crowdsec Container in einem eigenen Netz also 172.31.0.2:8080 ) werde ich komplett ausgesperrt.

Bedeutet das zwar die domain.tld/wp-admin noch geht aber die Webseite schmeißt einen 524 von Cloudflare.

Sobald ich es deaktiviere geht es wieder.

Ich habe unter den Erweiterten Einstellungen auch mal den Redis Cache aktiviert, da mein WP mit Redis Object Cache läuft. Dann ändert sich auch nichts.

Ich frage mich nun was habe ich Falsch gemacht? Liegt es an Cloudflare oder an meiner Docker Config.

Wer möchte kann sich das ganze ja mal anschauen ich habe sie auf Pastebin gestellt:

Crowdsec: https://pastebin.com/RLQxxawD
Wordpress: https://pastebin.com/dNw7UCid

Antworten anzeigen (3)

hardy(@hardy)

3 Jahre zuvor

#2902

Ich bekomme beim Testen: Technical error while testing bouncer connection: Unexpected HTTP call failure.

Klappt also nicht. Haat jemand n Tipp?

LG Hardy

Antworten anzeigen (7)

MyAir(@myair)

3 Jahre zuvor

#2195

Ich hab jetzt deine Anleitung durchgeackert und bin beim testen des Bouncing gescheitert.

Nach mehreren Fehlversuchen hat es mit der LAPI URL http://crowdsec:8080 und dem API Key dann geklappt “Test Bouncing” auszuführen ohne Fehler.
Ich bekomme zwar eine grüne OK Bestätigung aber der “Result is: bypass.” Auf die Webseite komme ich danach uneingeschränkt ohne Capcha.
Das Bouncing Level habe ich auf “Normal Bouncing” eingestellt also hätte ich erwartet dass das Result “captcha” sein müsste.
Ein Test mit “cscli decisions add -i 1.2.3.4 –duration 15m –type captcha” aktiviert das captcha und geht auch mit “cscli decisions remove -i 1.2.3.4” wieder weg.

Ich hab in den COLLECTIONS vom crowdsec docker-compose.yml noch “crowdsecurity/linux crowdsecurity/sshd crowdsecurity/nextcloud crowdsecurity/wordpress ” hinzugefügt für meine WordPress und Nextcloud instanzen wie auch dem “crowdsec-firewall-bouncer-iptables” den ich lokal auf dem VPS installiert habe. Brauch ich die wirklich oder geht das auch ohne? EDIT: Mittlerweile läuft es ohne “crowdsecurity/wordpress” in den COLLECTIONS aber macht keinen Unterschied.

Scheint soweit alles zu klappen aber ich verstehe noch nicht wirklich wie die das alles zusammenhängt mit diesen Bouncern. Ich hatte einen “wordpress-bouncer” mit API Key eingerichtet und verwendet. Dieser erschien auch in “cscli metrics list” nach dem Bouncing Test. Bin aber nicht sicher ob ich den brauche. Wenn ich den API Key vom Traefik Bouncer verwende ist das Endresultat das gleiche. Es erscheint zwar kein wordpress-bouncer mehr in “cscli metrics list” aber das Test Ergebnis bleibt OK mit “Result is: bypass.” und ohne Blocking. Unter “cscli decisions list” finde ich auch kein Hinweis dass die IP geblockt ist.

Also entweder versteh ich diesen Blocking Tests komplett falsch und jage einem Phantom nach oder der Test kommt zwar OK zurück aber die getestete IP wird nicht geblockt.
Wo könnte da der Fehler liegen?

Ich wäre froh um ein paar Hinweise.

Danke und Gruss
Thomas

p.s. Warum ist eigentlich der Screenshot vor dem “Test Bouncing” in der Anleitung nur für Community Plus Mitglieder?

Antworten anzeigen (4)