Doku aktualisiert.

README.md

@@ -22,6 +22,7 @@ Wenn ein Client eine bestimmte Domain zu oft anfragt (z.B. >30x pro Minute), wir
 ## Features
 
 - Automatische Erkennung und Sperre bei Rate-Limit-Verstößen
+- **Subdomain-Flood-Erkennung** — erkennt Random-Subdomain-Attacken (z.B. `abc123.microsoft.com`, `xyz456.microsoft.com`, ...)
 - **Progressive Sperren (Recidive)** — Wiederholungstäter werden stufenweise länger gesperrt (wie bei fail2ban)
 - Unterstützt **alle DNS-Protokolle**: DNS (53), DoH (443), DoT (853), DoQ (784/853/8853)
 - **IPv4 + IPv6**

doc/architektur.md

@@ -29,6 +29,8 @@
 
 ## Ablauf einer Sperre
 
+### Rate-Limit-Sperre
+
 1. Client `192.168.1.50` fragt `microsoft.com` 45x in 60 Sekunden an
 2. Monitor fragt die AdGuard Home API alle 10 Sekunden ab (`/control/querylog`)
 3. Die Anfragen werden pro Client+Domain-Kombination gezählt
@@ -42,6 +44,18 @@
 11. Log-Eintrag + optionale Webhook-Benachrichtigung
 12. Nach Ablauf der (progressiven) Sperrdauer: automatische Entsperrung + History-Eintrag
 
+### Subdomain-Flood-Sperre (Random Subdomain Attack)
+
+1. Client `10.0.0.99` fragt `abc123.microsoft.com`, `xyz456.microsoft.com`, ... ab
+2. Monitor extrahiert die **Basisdomain** (`microsoft.com`) aus jeder Anfrage
+3. Pro Client wird gezählt, wie viele **eindeutige Subdomains** einer Basisdomain im Zeitfenster abgefragt wurden
+4. Monitor erkennt: 63 eindeutige Subdomains > 50 (Schwellwert überschritten)
+5. Prüfung: Ist der Client auf der Whitelist? → Nein
+6. Sperre wird ausgeführt mit Domain `*.microsoft.com` und Grund `subdomain-flood`
+7. Progressive Sperren greifen auch hier — Wiederholungstäter werden stufenweise länger gesperrt
+
+> **Hinweis:** Die Subdomain-Flood-Erkennung hat ein eigenes Zeitfenster (`SUBDOMAIN_FLOOD_WINDOW`) und einen eigenen Schwellwert (`SUBDOMAIN_FLOOD_MAX_UNIQUE`), unabhängig von den Rate-Limit-Einstellungen.
+
 ## iptables Strategie
 
 Das Tool erstellt eine eigene Chain `ADGUARD_SHIELD`:
@@ -87,6 +101,7 @@ BAN_UNTIL=2026-03-03 15:30:00
 BAN_DURATION=3600
 OFFENSE_LEVEL=1
 IS_PERMANENT=false
+REASON=rate-limit
 ```
 
 Zusätzlich wird für jede IP ein Offense-Tracker gespeichert:
@@ -185,7 +200,9 @@ ZEITSTEMPEL         | AKTION | CLIENT-IP                               | DOMAIN
 | Grund | Bedeutung |
 |-------|----------|
 | `rate-limit` | Automatische Sperre wegen Limit-Überschreitung |
+| `subdomain-flood` | Sperre wegen zu vieler eindeutiger Subdomains einer Basisdomain |
 | `dry-run` | Im Dry-Run erkannt (nicht wirklich gesperrt) |
+| `dry-run (subdomain-flood)` | Subdomain-Flood im Dry-Run erkannt |
 | `expired` | Automatisch entsperrt nach Ablauf der Sperrdauer |
 | `expired-cron` | Entsperrt durch den Cron-Job (`unban-expired.sh`) |
 | `manual` | Manuell entsperrt per `unban`-Befehl |

doc/tipps-und-troubleshooting.md

@@ -87,6 +87,30 @@ Das ist normal — iptables-Regeln sind flüchtig. Der **Service** erstellt die
 - `RATE_LIMIT_WINDOW` vergrößern (z.B. 120 Sekunden)
 - Windows-Clients fragen manche Domains von Natur aus sehr oft an — Whitelist nutzen
 
+### Subdomain-Flood-Erkennung sperrt legitime Clients
+
+Manche Dienste (z.B. CDNs, Cloud-Dienste, Microsoft 365) nutzen von Natur aus viele verschiedene Subdomains. Falls ein legitimer Client fälschlicherweise durch die Subdomain-Flood-Erkennung gesperrt wird:
+
+1. Client sofort entsperren:
+   ```bash
+   sudo /opt/adguard-shield/adguard-shield.sh unban <IP>
+   ```
+2. Schwellwert erhöhen — z.B. von 50 auf 100 oder 150:
+   ```bash
+   SUBDOMAIN_FLOOD_MAX_UNIQUE=100
+   ```
+3. Zeitfenster vergrößern — z.B. auf 120 Sekunden:
+   ```bash
+   SUBDOMAIN_FLOOD_WINDOW=120
+   ```
+4. Oder die IP zur Whitelist hinzufügen
+5. Im Zweifelsfall die Erkennung temporär deaktivieren:
+   ```bash
+   SUBDOMAIN_FLOOD_ENABLED=false
+   ```
+
+> **Tipp:** Im Dry-Run-Modus (`sudo /opt/adguard-shield/adguard-shield.sh dry-run`) kann man beobachten, welche Clients die Subdomain-Flood-Erkennung auslösen würden, ohne sie wirklich zu sperren.
+
 ### Monitor startet nicht (PID-File)
 
 ```bash