Ungültige Anmeldeversuche für Fail2ban und Upstream-Server-Aktion protokollieren

Merkmal
1

I was hoping Discourse could log invalid login attempts to file, even if it is something you have to configure to do so. Then I could create a custom filter and jail for discourse

I use a centralized fail2ban server. the way it works is all my Containers, Docker images, VMs have a custom ban action:

in fail2ban you specify the action to take in your jail, such as:
action = iptables-allports

then all you have to do is edit that action:
sudo nano /etc/fail2ban/action.d/iptables-allports.conf

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
      curl -s "https://fail2ban.YourDomain.com:35553/fail2ban.php?token=D2f3Ydy45f6y5FRTfyeFrtYErt&action=add&source=TEST_HOST&reason=TEST_FILTER&ip=111.222.333.444"

With this setup your container/docker/vm will fail2ban them locally, but it will also relay this information to your central fail2ban server. The central server can also take all collected IPs and make them available as txt banlist such as: https://fail2ban.YourDomain.com/banned.txt

Then you can have your pfsense firewall subscribe to this banlist, and you can even share the list with other pfsense routers. This way if they try breaking in on one application, they get banned from everything. This has worked great for me for years.

And all that I need to implement this for discourse is for discourse to write an entry to a log file when there is an invalid login attempt :slight_smile:

1 „Gefällt mir“
2

did you figure out how to hook or log this?

Thanks

1 „Gefällt mir“
3

Bump. This seems like a very good idea!

Where does Discourse store and show logs?

The NGINX logs
Occasionally NGINX logs may contain some extra tips, they are located at:

cd /var/discourse
./launcher enter app
cd /var/log/nginx
The files access.log and error.log will be there as well as a bunch of rotated compressed files. Running less access.log.2.gz will automatically decompress and display the logfile for you.

This directory is also available on the host at /var/discourse/shared/standalone/log/var-log/nginx .

Unfortunately, the nginx error.log and access.log files do not log any invalid login attempts.

Can anyone suggest another avenue?

Thank you.

1 „Gefällt mir“
4

Agree. It would be great to hook into a fail2ban kind of automated exponential backoff.

1 „Gefällt mir“
5

neugierig - Wird diese Funktionsanfrage bereits verfolgt oder geplant? Es wäre ein gutes Sicherheitsmerkmal.

Protokollieren (oder Hook für) fehlgeschlagene Anmeldeversuche nach IP-Adresse

Danke!

1 „Gefällt mir“
6

Die nginx access.log-Datei sollte Zeilen mit 403-Antworten für die Login-Route enthalten, die Sie dafür benötigen. Haben Sie die Protokolle überprüft?

1 „Gefällt mir“
7

Ahhh, danke! Ich frage mich, wie ich von außerhalb des Docker-Images/Containers darauf zugreifen kann.

9

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)

schlechtes Passwort:

[20/Dez/2021:08:07:31 -0800] "community.example.com" 10.111.222.33 "GET /session/csrf HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/csrf" 200 1185 "https://community.example.com/" 0.016 0.017 "-"
[20/Dez/2021:08:07:32 -0800] "community.example.com" 10.111.222.33 "POST /session HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/create" 200 1111 "https://community.example.com/" 0.552 0.550 "-"

gutes Passwort:

[20/Dez/2021:08:24:50 -0800] "community.example.com" 10.111.222.33 "GET /session/csrf HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/csrf" 200 1185 "https://community.example.com/" 0.020 0.020 "-"
[20/Dez/2021:08:24:51 -0800] "community.example.com" 10.111.222.33 "POST /session HTTP/1.1" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0" "session/create" 200 2251 "https://community.example.com/" 1.216 1.216 "-"

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.

2 „Gefällt mir“
10

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

Und das tut, was Sie brauchen?

3 „Gefällt mir“
Failed login returns 200 Ok
11

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)

3 „Gefällt mir“
12

Danke! Ich hoffe, ich kann dieses Plugin verwenden. Lassen Sie mich wissen, ob Sie es verfügbar machen können.

13

Konnten Sie das jemals zum Laufen bringen? Ich bin sehr daran interessiert, fail2ban auch mit meiner Discourse-Instanz zu verwenden.

14

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 :wink:

Aber wir sollten eine Logik haben, um ständige Anmeldungen zu stoppen, auch wenn es keine alltägliche Bedrohung ist, denke ich.