lukas/nixos-config
Archived
1
0
Fork 1
Code Issues Pull requests Releases Wiki Activity
This repository has been archived on 2026-09-17. You can view files and clone it, but you cannot make any changes to its state, such as pushing and creating new issues, pull requests or comments.
nixos-config/docs/intent/lldap-fail2ban-protection.md

2.6 KiB
Raw Permalink Blame History

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.