6
Fail2Ban Moodle mit AD-Usern
Moin,
ich habe auf unserem Moodle-Server (Ubuntu 16.04) fail2ban installiert.
SSH-Attacken kann ich damit auch blocken, das möchte ich jetzt mit HTTPS auch tun. Problem dabei: Der Moodle-Server ist an unser Active Directory angebunden, die Apache-Logabfragen laufen also ins Leere. Hat das von Euch jemand konfiguriert, so dass es funktioniert?
Gruß
ich habe auf unserem Moodle-Server (Ubuntu 16.04) fail2ban installiert.
SSH-Attacken kann ich damit auch blocken, das möchte ich jetzt mit HTTPS auch tun. Problem dabei: Der Moodle-Server ist an unser Active Directory angebunden, die Apache-Logabfragen laufen also ins Leere. Hat das von Euch jemand konfiguriert, so dass es funktioniert?
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 358652
Url: https://administrator.de/contentid/358652
Printed on: April 19, 2024 at 06:04 o'clock
6 Comments
Latest comment
Hallo @Coreknabe,
Ich verstehe nicht ganz, was nun nicht funktioniert. Könntest du das nochmal etwas tiefer beleuchten?
Was spricht dagegen, dein AD zu whitelisten? Siehe: Whitelist - Fail2ban
Gruß,
@Snowman25
Ich verstehe nicht ganz, was nun nicht funktioniert. Könntest du das nochmal etwas tiefer beleuchten?
Was spricht dagegen, dein AD zu whitelisten? Siehe: Whitelist - Fail2ban
Gruß,
@Snowman25
Hi Snowman,
danke für Deine Antwort.
OK, etwas ausführlicher...
Ich editiere die Datei /etc/fail2ban/jail.local folgendermaßen:
Jetzt produziere ich absichtlich einen fehlerhaften Login, gebe also ein falsches Passwort für User X ein. Alle User sind AD-User. Das wird im Apache-Log aber nicht eingetragen, weil die User-Abfrage ja über unser AD erfolgt. Da kann fail2ban also auch nix machen, weil der Moodle-Server die Antwort vom AD erhält. So weit meine Deutung des Sachverhalts...
Die Frage ist also, bringt mir fail2ban in diesem Fall überhaupt etwas? Bzw. kann ich es so konfigurieren, dass es mir etwas bringt?
Gruß
danke für Deine Antwort.
OK, etwas ausführlicher...
Ich editiere die Datei /etc/fail2ban/jail.local folgendermaßen:
[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6Jetzt produziere ich absichtlich einen fehlerhaften Login, gebe also ein falsches Passwort für User X ein. Alle User sind AD-User. Das wird im Apache-Log aber nicht eingetragen, weil die User-Abfrage ja über unser AD erfolgt. Da kann fail2ban also auch nix machen, weil der Moodle-Server die Antwort vom AD erhält. So weit meine Deutung des Sachverhalts...
Die Frage ist also, bringt mir fail2ban in diesem Fall überhaupt etwas? Bzw. kann ich es so konfigurieren, dass es mir etwas bringt?
Gruß
Hi,
Was möchtest du den protokollieren, wer versucht mit fehlerhaften Anmeldedaten gegen das AD sich zu authentifizieren ?
Dann musst du eine AD Überwachung einrichten.
Mit freundlichen Grüßen
Was möchtest du den protokollieren, wer versucht mit fehlerhaften Anmeldedaten gegen das AD sich zu authentifizieren ?
Dann musst du eine AD Überwachung einrichten.
Mit freundlichen Grüßen
Servus,
Moodle loggt nach MySQL, dort wird bei falschem Login eine passende Meldung hinteregt:
"Login failed for the username 'xxxxx' for the reason with id 'x'." In dem Datensatz findest du auch die Quell-IP.
Du müsstest fail2ban irgendwie beibringen, in MySQL nachzuschauen.
Oder du kannst dir eine Benachtichtigung bei mehreren falschen Logins mailen lassen:
Website-Administration ► Sicherheit ► Systemmitteilungen
Grüße, Stefan
Moodle loggt nach MySQL, dort wird bei falschem Login eine passende Meldung hinteregt:
"Login failed for the username 'xxxxx' for the reason with id 'x'." In dem Datensatz findest du auch die Quell-IP.
Du müsstest fail2ban irgendwie beibringen, in MySQL nachzuschauen.
Oder du kannst dir eine Benachtichtigung bei mehreren falschen Logins mailen lassen:
Website-Administration ► Sicherheit ► Systemmitteilungen
Grüße, Stefan
@7Gizmo7
Ich will gar nix protokollieren, ich will nur etwas gegen Bruteforce-Attacken tun.
@stefaan
Das hilft mir schon mal weiter, wenn auch nicht in Hinsicht auf fail2ban.
Ich glaube, es hakt an dem fehlenden Filter in fail2ban, in meinem Beispiel oben steht der ja auf "apache-auth". Einen passenden AD-Filter gibt es meines Wissens nicht.
Danke für den Hinweis mit dem SQL-Logging. Wir setzen PRTG ein, damit müsste ich mir eigentlich einen passenden Sensor basteln können. Muss ich mir mal ansehen.
Ich will gar nix protokollieren, ich will nur etwas gegen Bruteforce-Attacken tun.
@stefaan
Das hilft mir schon mal weiter, wenn auch nicht in Hinsicht auf fail2ban.
Ich glaube, es hakt an dem fehlenden Filter in fail2ban, in meinem Beispiel oben steht der ja auf "apache-auth". Einen passenden AD-Filter gibt es meines Wissens nicht.
Danke für den Hinweis mit dem SQL-Logging. Wir setzen PRTG ein, damit müsste ich mir eigentlich einen passenden Sensor basteln können. Muss ich mir mal ansehen.
Hi Stefan,
mit Deiner Lösung kann ich gut leben, Benachrichtigung erfolgt per Mail inkl. Source-IP. Wenn auch kein automatischer Ban erfolgt, hilft mir das doch weiter, so kann ich wenigstens Auffälligkeiten sehen.
Danke und schon mal schöne Weihnachtstage / einen guten Rutsch!
mit Deiner Lösung kann ich gut leben, Benachrichtigung erfolgt per Mail inkl. Source-IP. Wenn auch kein automatischer Ban erfolgt, hilft mir das doch weiter, so kann ich wenigstens Auffälligkeiten sehen.
Danke und schon mal schöne Weihnachtstage / einen guten Rutsch!
