Ich hatte gehofft, dass Discourse fehlgeschlagene Anmeldeversuche in eine Datei protokollieren kann, auch wenn dies eine Konfiguration erfordert. Dann könnte ich eine benutzerdefinierte Filter- und Jail-Konfiguration für Discourse erstellen.
Ich verwende einen zentralen Fail2Ban-Server. Die Funktionsweise ist folgende: Alle meine Container, Docker-Images und VMs haben eine benutzerdefinierte Sperraktion.
In Fail2Ban legen Sie in Ihrem Jail die auszuführende Aktion fest, zum Beispiel: action = iptables-allports
Anschließend müssen Sie nur noch diese Aktion bearbeiten: sudo nano /etc/fail2ban/action.d/iptables-allports.conf
Mit dieser Einrichtung wird ein Angreifer zwar lokal im Container/Docker/VM von Fail2Ban gesperrt, aber diese Information wird auch an Ihren zentralen Fail2Ban-Server weitergeleitet. Der zentrale Server kann zudem alle gesammelten IP-Adressen als eine banlist im Textformat bereitstellen, beispielsweise unter: https://fail2ban.IhreDomain.com/banned.txt
Anschließend können Ihre pfSense-Firewall diese Sperrliste abonnieren, und Sie können die Liste sogar mit anderen pfSense-Routern teilen. Auf diese Weise werden Angreifer, die versuchen, sich in eine Anwendung einzuklinken, automatisch für alle Dienste gesperrt. Diese Lösung funktioniert bei mir seit Jahren hervorragend.
Alles, was ich benötige, um dies für Discourse umzusetzen, ist, dass Discourse bei einem fehlgeschlagenen Anmeldeversuch einen Eintrag in eine Protokolldatei schreibt
Die NGINX-Logs
Gelegentlich können die NGINX-Logs zusätzliche Hinweise enthalten. Sie befinden sich unter:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
Dort finden Sie die Dateien access.log und error.log sowie eine Reihe rotierter, komprimierter Dateien. Der Befehl less access.log.2.gz dekomprimiert und zeigt das Logfile automatisch für Sie an.
Dieses Verzeichnis ist auch auf dem Host unter /var/discourse/shared/standalone/log/var-log/nginx verfügbar.
Leider protokollieren die Dateien nginx error.log und access.log keine fehlgeschlagenen Anmeldeversuche.
Hallo @Falco, danke für die Antwort. Ich habe gerade die Protokolle überprüft. Ein Versuch mit korrektem Passwort und ein Versuch mit falschem Passwort sehen für mich gleich aus (200er Antwort):
(Ich habe die IP-Adresse und die Domain bereinigt, der Rest ist unverändert)
Da beide eine 200er-Antwort zurückgeben, können Sie dies nicht für fail2ban verwenden. Sie würden alle Benutzer mit gutem oder schlechtem Passwort sperren.
Twitter verwendet 400 für falsches Passwort, aber Facebook, LinkedIn, Google und Amazon geben 200 zurück. Meiner Meinung nach klingt 200 falsch, aber es scheint die „normale“ Sache zu sein?
Vielleicht können Sie mit einem Plugin beginnen, das sich in diese Methode hier einklinkt
Großartig, danke für die Antwort! Sobald ich etwas Zeit habe, werde ich versuchen, ein Plugin zu erstellen, um diese Informationen zu generieren! (Ich brauche nur die IP-Adresse, die in eine Datei protokolliert wird, wenn jemand versucht, sich mit einem falschen Passwort anzumelden, z. B. ungültiger Anmeldeversuch von IP 10.111.222.33)
Ich schreibe über die Rollen von selbstgemachten Webmastern und reinen Endbenutzern, aber…
Ungültige Anmeldungen sind per Definition ein Fehler 200. Sicher, es kann und sollte ein interner Fehler einer App sein und irgendwann etwas anderes generieren, wie z. B. Fehler 403 plus etwas anderes, wie das Senden eines Wiederherstellungslinks, aber das sollte oder kann nicht sofort passieren.
Fail2ban ist ein schönes Werkzeug, aber wirklich überbewertet. Vergessen wir Docker, weil es alles schwieriger macht, aber allein die Tatsache, dass es die iptables eines VPS umgehen kann, ist für mich wirklich verwirrend. Aber Bots neigen dazu, die IP nach jedem dritten Versuch zu ändern, und das macht Fail2ban bei reinen Brute-Force-Angriffen über die Anmeldung ziemlich zahnlos.
Script-Kiddies sind natürlich eine andere Geschichte. Sie kopieren und fügen alles ein, was sie finden, drehen es und spielen nicht mit IPs herum. Dann kann Fail2ban sie stoppen, auch wenn sie selten etwas Schaden anrichten können, aber die Last erhöhen. Das eigentliche Problem ist die Menge an Script-Kiddies, wenn es eine sofortige Flut gibt.
Aber solange ein VPS eine solche Situation bewältigen kann, spielt es keine Rolle. Jetzt ist 2023 und meistens klopfen diese Arschlöcher an alte Schwachstellen von WordPress auf Discourse-Seiten
Aber wir sollten eine Logik haben, um ständige Anmeldungen zu stoppen, auch wenn es keine alltägliche Bedrohung ist, denke ich.
