Einführung

Sicherheit ist ein kritischer Aspekt jeder modernen Cloud-Infrastruktur. Bei matzka.cloud betreiben wir elf verschiedene Dienste mit Authentifizierungsendpunkten, die potentiell anfällig für Brute-Force-Angriffe sind.

Die Anforderung war klar: Ein umfassendes Schutzsystem implementieren, das Angreifer erkennt und blockiert, ohne legitime Benutzer zu behindern.

Die Herausforderung

Ausgangslage

Vor dieser Implementierung hatten wir:

• ✅ Fail2ban für SSH-Schutz
• ✅ Wazuh SIEM für Sicherheitsüberwachung
• ✅ Traefik als Reverse Proxy
• ❌ Keine Web-Service Brute-Force Protection
• ❌ Keine Koordination zwischen Systemen
• ❌ Keine automatische IP-Blockierung für Web-Services

Anforderungen

1. Multi-Layer Defence: Angreifer auf mehreren Ebenen blockieren
2. Automatisierung: Keine manuellen Eingriffe nötig
3. Transparenz: Email-Benachrichtigungen für alle Blöcke
4. Keine False Positives: Legitime Benutzer nicht behindern
5. SSO-Kompatibilität: OAuth/OIDC-Flows müssen funktionieren

Architektur: Drei Schichten

Das System arbeitet auf drei verschiedenen Ebenen:

Wie es funktioniert

1. Request kommt an → Traefik Rate Limiter überprüft
2. Rate Limit überschritten? → HTTP 429 (zu viele Anfragen)
3. Failed Login Attempt → Traefik loggt in access.log (JSON)
4. Fail2ban liest Log → Erkennt fehlgeschlagene Logins
5. 5 Versuche in 10 Min? → IP wird blockiert (iptables)
6. Wazuh erkennt Muster → Zusätzliches firewall-drop Command
7. IP-Blockade → 1-2 Stunden (je nach Service)
8. Email-Alert → Admin wird benachrichtigt

Schicht 1: Fail2ban

JSON-basierte Log-Analyse

Traefik gibt Logs im JSON-Format aus. Dies erforderte eine spezielle Regex:

# Filter: /etc/fail2ban/filter.d/matzka-bruteforce.conf
[Definition]
failregex = "ClientAddr":"(<HOST>[^"]+)".+?"DownstreamStatus":(401|403)
ignoreregex = "/api/live|/ping|/metrics|/health"

10 Aktive Jails

Schicht 2: Wazuh IPS

Automatische Firewall-Blockierung

<!-- In /var/ossec/etc/ossec.conf -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <disabled>no</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>80702,5503,5504,5505</rules_id>
  <timeout>3600</timeout>
</active-response>

Schicht 3: Traefik Rate Limiting

Rate-Limiting Policies

ratelimit-sso:           30 req/min  # OAuth/OIDC Flows
ratelimit-login:         5 req/min   # Standard Login
ratelimit-admin:         3 req/min   # Admin Interfaces
ratelimit-api:          20 req/min   # API Endpoints

Kritisches Learning: SSO-Kompatibilität

OAuth/OIDC-Flows benötigen deutlich mehr Requests als normales "POST login":

• Initial auth request
• Redirect zu Authentik
• Token request
• Token validation
• Cookie/Session management

Probleme & Lösungen

Problem 1: SSO funktioniert nicht mehr

Route /auth/login/authentik doesn't exist
HTTP/2 404 Not Found

Diagnose

• Directus hat keine Authentik-Umgebungsvariablen
• .env file war unvollständig
• AUTH_AUTHENTIK_DRIVER= war leer

Lösung

1. Alle AUTH_AUTHENTIK_* Variablen zur .env hinzufügen
2. Echte CLIENT_SECRET aus Authentik-DB abrufen:

   docker exec postgres-authentik psql -U authentik -d authentik -c \
   "SELECT client_secret FROM authentik_providers_oauth2_oauth2provider \
   WHERE name ILIKE '%directus%';"

3. Directus neu starten mit korrekten Credentials

Problem 2: Rate-Limiting zu restriktiv für SSO

Ursache

5 req/min für `auth-login` ist zu restriktiv. OIDC Authorization Flow mit PKCE benötigt 8-12 Anfragen in schneller Folge.

Lösung

# Neue Policy für SSO
ratelimit-sso:
  rateLimit:
    average: 30 req/min
    burst: 60

# Verwendung in auth-login Chain
auth-login:
  chain:
    middlewares:
      - ratelimit-sso  # 30 req/min statt 5

Problem 3: Traefik Middleware YAML Syntax

Fehler

middleware "mailcow-headers,auth-login@file" does not exist

Ursache

# ❌ Falsch: Comma-separated String
middlewares: mailcow-headers,auth-login@file

# ✅ Richtig: YAML Liste
middlewares:
  - mailcow-headers
  - auth-login@file

Finale Konfiguration

Alle 11 geschützten Services

Lessons Learned

Technische Erkenntnisse

1. Layered Security funktioniert

• Eine Schicht allein reicht nicht
• Mehrere Schichten erschweren Angriffe exponentiell
• Redundanz ist wichtig: Bei Fehler in einer Schicht funktionieren andere noch

2. Network Isolation ist Double-Edged

• ✅ Gut für Sicherheit (Services können sich nicht beeinflussen)
• ❌ Schlecht für Konfiguration (komplexe DNS/Network-Setup)
• 💡 Zentrale Koordination (Prometheus) ist besser als dezentral

3. Log Format ist kritisch

• JSON-Logs sind strukturiert, aber komplexer zum Parsen
• Alte regex-based Tools brauchen Anpassungen
• Investition in JSON-aware Tools lohnt sich

4. OAuth/OIDC ist komplex

• Viel mehr Requests als normales "POST login"
• PKCE, State, Nonce, Token Refresh
• Rate Limits müssen "großzügig" für SSO sein

Prozess Erkenntnisse

1. Monitoring first, dann sperren: Zuerst Fail2ban mit Email, ohne zu blockieren
2. Dokumentation während Implementierung: Was funktioniert nicht? Warum? Wie gelöst?
3. Schritt für Schritt: Nicht alles auf einmal ändern. Eine Schicht nach der anderen.
4. Testing ist essential: Jede Konfigurationsänderung mit echten Clients testen

Empfehlungen für zukünftige Projekte

Fazit

Das Three-Layer Brute-Force Protection System für matzka.cloud ist nun produktiv im Betrieb:

Das System wurde unter realen Bedingungen getestet und alle identifizierten Probleme wurden gelöst. Die Infrastruktur ist nun deutlich resistenter gegen Brute-Force-Angriffe, während gleichzeitig Benutzerfreundlichkeit und SSO-Funktionalität erhalten bleiben.