# 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.