28 lines
2.6 KiB
Markdown
28 lines
2.6 KiB
Markdown
# Intent: Fail2ban-Schutz für öffentliches lldap-Interface
|
|
|
|
## Ziel
|
|
Das öffentlich erreichbare lldap-Webinterface (Selfservice-Passwort-UI) soll gegen wiederholte Fehlversuche per Fail2ban geschützt werden, ohne die öffentliche Erreichbarkeit einzuschränken.
|
|
|
|
## Umfang
|
|
- Inspiziere zunächst reale lldap-Log-Ausgaben (z.B. via `journalctl -u lldap.service`) auf dem laufenden System, um das tatsächliche Format fehlgeschlagener Login-Versuche zu ermitteln -- nicht raten.
|
|
- Aktiviere in `hosts/blunix/localServices/fail2ban.nix` eine jail für lldap (die Datei enthält bereits einen auskommentierten Entwurf als Ausgangspunkt) mit `maxretry = 5` und einer Bantime nach normaler Fail2ban-Konvention (z.B. analog zum vorhandenen traefik-auth-Beispiel in derselben Datei, das bantime/findtime bereits vorgibt).
|
|
- Falls kein eingebauter Fail2ban-Filter für lldap existiert, definiere einen passenden Custom-Filter (`filters.<name>.definition`) mit einer failregex, die auf die tatsächlich beobachteten Log-Zeilen passt (Backend `systemd`, `journalmatch` auf `_SYSTEMD_UNIT=lldap.service`).
|
|
|
|
## Explizit ausgeschlossen
|
|
- Keine Auth-Middleware oder sonstige Zugriffsbeschränkung vor lldap (hosts/blunix/localServices/traefik/routes-external.nix bleibt unverändert, das Interface bleibt öffentlich).
|
|
- Kein Schwächen der legitimen Zugriffsmöglichkeit.
|
|
- Keine Änderung an services.lldap selbst (hosts/blunix/localServices/lldap.nix), außer falls dort explizit zusätzliches Logging aktiviert werden muss, um Fehlversuche überhaupt sichtbar zu machen -- dann minimal und nur dafür.
|
|
|
|
## Annahmen
|
|
- lldap loggt fehlgeschlagene Login-Versuche über journald in einem erkennbaren, parsbaren Format; falls nicht, muss das gegebenenfalls durch eine minimale Logging-Konfiguration in lldap.nix ergänzt werden.
|
|
- Der vorhandene auskommentierte lldap-jail-Entwurf in fail2ban.nix ist ein grober Ausgangspunkt, dessen Filter-Namen/-Regeln vor Aktivierung gegen die echten Logzeilen verifiziert werden müssen.
|
|
|
|
## Risiken
|
|
- Ein falsch konstruierter Filter kann entweder gar nicht matchen (kein Schutz) oder legitime Logins fälschlich als Fehlversuche werten (versehentliches Aussperren) -- deshalb ist die Log-Inspektion vor Filtererstellung Pflicht, und Tests dürfen keine echte Admin-IP dauerhaft aussperren.
|
|
|
|
## Erfolgskriterien
|
|
- lldap bleibt öffentlich erreichbar.
|
|
- Fehlgeschlagene Logins erzeugen Logeinträge, die vom Filter erfasst werden.
|
|
- 5 Fehlversuche von einer IP lösen den Ban aus.
|
|
- Ein legitimer Login bleibt weiterhin möglich.
|
|
- Der Schutz übersteht einen Rebuild/Reboot, da rein deklarativ konfiguriert.
|