Lab-Bericht — Pentest gegen das eigene IDS

Test 1 — nmap Top-1000 Stealth-Scan

Angriffsmuster: Klassischer SYN-Stealth-Scan auf die 1 000 häufigsten Ports. Erwartet: SCAN_001, DOS_CONN_001.

nmap -sS -T4 -Pn --top-ports 1000 192.168.1.80

Bewertung: Heuristik nagelt es korrekt fest. ML feuert nicht — wie in der 24-h-Beobachtung.

Test 2 — nmap Full-Port mit Service-Detection

Angriffsmuster: Vollständiger TCP-Connect-Scan über alle 65 535 Ports plus Service-Banner-Probes (~3 300 pps).

nmap -sT -sV -T4 -Pn -p- 192.168.1.80

Bewertung: Heuristik feuert breit und korrekt-priorisiert. ML weiterhin still.

Test 3 — hping3 SYN-Flood

Angriffsmuster: Dauer-SYN-Flood gegen Port 80 mit hoher Paketrate. Klassischer DoS-Versuch.

sudo hping3 -S -p 80 --flood -c 20000 192.168.1.80

Bewertung: Heuristik korrekt critical, ML auch hier still bei einem SYN-Flood — substanziell unterempfindlich.

Nebeneffekt: dieser 4-min-Flood stopfte den Tap-Kafka-Producer-Buffer. Folge-Tests T5–T8 sahen über 5 min lang fast keinen Verkehr. Daraus folgt der Backpressure-Fix in Phase 3.

Diagnose T4 — Threshold-Probe 0.65 → 0.40

Threshold zur Laufzeit über /models/ml_config.json auf 0,40 abgesenkt. Score-Verteilung der nächsten 5 min:

Top-Scorer waren mDNS-Discovery, MQTT, normaler SSH-Verkehr — die Kali- Tests tauchten unter den Top-Scorern überhaupt nicht auf. Daraus folgt: das Problem ist nicht der Threshold, das Problem ist das Modell — 14 sehr basale Flow-Statistiken reichen nicht aus.

Test 9 — nmap Top-1000 mit Modell v2

nmap -sS -T4 -Pn --top-ports 1000 192.168.1.80

Test 10 — nmap Top-1000 mit Threshold 0.40

Bewertung: ML feuert auf einen anderen Flow (Linuxhost zu CDN) — die „ehrliche Lieferung" des Modells. Es markiert ungewöhnliche Single-Flow-Bandbreitenprofile, nicht den Scan selbst. Top-Score normaler Subnet-Verkehr klettert von 0,46 (Modell v1) auf 0,55 (Modell v2).

Test 11 — hping3 SYN-Flood, kontrolliert

sudo hping3 -S -p 80 -i u200 -c 10000 192.168.1.80

Bewertung: Heuristik korrekt + sofort. ML stumm — strukturell richtig: hping3 randomisiert src_port pro Paket, daher landen 10 000 Mini-Flows mit je 1 SYN-Paket im Aggregator. IsolationForest auf Single-Flow-Features kann das prinzipiell nicht detektieren — diese Multi-Flow-Aggregation leistet die signature-engine über ctx.flow_rate(src_ip, window_s).

Test BT — Burst + sofort nmap

Worst-Case-Folge: 5-kpps-SYN-Flood, direkt danach nmap-Scan. Vor dem Fix hätte der nmap nichts mehr durchbekommen — der Tap-Buffer wäre 5+ Minuten am Aufholen.

sudo hping3 -S -p 80 -i u200 -c 10000 192.168.1.80   # 5 kpps × 2 s
nmap -sS -T4 -Pn --top-ports 1000 192.168.1.80       # direkt im Anschluss

Backpressure-Metriken

Bewertung: Vor Fix: 5+ min Pipeline-Stillstand. Jetzt: 30 s Aufholzeit, danach sofort einsatzbereit. Operator-Diagnose: docker logs --tail 5 cyjan-tap-flow-aggregator | grep kafka_drop.

Test D1 — DNS-Flood mit Amplification-Profil

python3 /tmp/dnsattack.py --mode amp --count 1000 --rate 300
# → sent=1000 pps=300.3 avg_pkt=33.9 byte_out=33.9 KB

Bewertung: TUNNEL trifft sauber. AMP_001 trifft nicht — pkt_size_mean 102 liegt knapp über der 100-Byte-Schwelle, weil DNS-Antworten den Mean hochziehen (bidirektionale Aggregation).

Test D4 — DNS-Flood gegen non-listening Port (Reflection-Source-Profil)

Angriffsmuster: Hochfrequente DNS-Queries gegen den Master auf Port 53 — der dort nicht lauscht. Damit geht der Flow rein outgoing: keine DNS-Replies, nur ICMP-Port-Unreachable. Entspricht exakt dem Profil eines echten Spoofed-Reflection-Angriffs.

python3 /tmp/dnsattack_v2.py --server 192.168.1.81 --mode amp --count 1000 --rate 300
# → sent=991 pps=297.6 avg_pkt=33.9

Bewertung: Default-Schwelle pkt_size_mean < 100 ist richtig kalibriert für echte Reflection-Angriffe — sie verfehlt nur Tests, in denen der Lab-Resolver tatsächlich antwortet (D1).

Tests D3, D5, D7 — DGA-Pattern + Schwellen-Anpassung

Drei IAT-Verteilungen gegen DNS_DGA_001 (Default-Schwelle entropy_iat > 2.5, gesenkt auf 1.5 in Commit 48659ff):

Bewertung: 1,5 markiert die richtige Grenze: chaotisches Multi-Modal-Timing löst aus, monomodales/bimodales Idle-Verhalten nicht. Operator kann via Settings → Rule Adjustments → DNS_DGA_001 → entropy_iat jederzeit weiter anpassen.

Befund Phase 4 — DNS-Detektion komplett funktional

Test S1 — Single-Alert mit aktiver Baseline

Synthetische Baseline injiziert: 50 Alerts SUPPRESSION_TEST_001 über 11 Stunden (mean=4,55/h, std=1,04). Cache nahm Pattern auf: 73 → 74 ML-Learned.

Suppression greift wie spec: Severity medium → low, Tag gesetzt. ✓

Tests S3 + S4 — Spike-Durchbruch

S3: 60 Alerts in <1 s mit gleichem rule+ip aber varying dst_port (umgeht 5-min-Dedup). Alle 60 wurden suppressed — der Cache hatte recent_1h aus dem letzten Refresh (= 0) noch im Speicher. Refresh-Latenz sichtbar.

Cache-Refresh nach 60 s:

Cache-Stats jetzt: "73 aktiv suppressed, 1 Spike-Durchbruch".

S4: 1 neuer Alert nach Refresh:

Bewertung: Severity bleibt original, kein Tag. Spike- Durchbruch wirkt — gesamter Lebenszyklus verifiziert.

Maßnahme — Cache-Refresh-Intervall (Commit b58c208)

REFRESH_INTERVAL_S 60 → 30 s + ENV-tunbar (SUPPRESSION_REFRESH_INTERVAL_S). Halbiert die Worst-Case- Latenz vom Spike-Beginn bis Durchbruch (~2 min → ~1 min). DB-Last bleibt unter 100 ms (indizierte Felder).

Defaults LEARN_WINDOW_D=14, MIN_HOURS=8, Z_THRESHOLD=2.0 bleiben unverändert — gut kalibriert.

Test RT1 — Frischer Trainingslauf mit parallelen Pentests

State → training, training_until = now() + 5 min. Parallel auf Kali: 3× nmap top-1000, 1× hping3 SYN-Burst, 1× DNS-Flood.

Bewertung: first_apply springt aggressiv auf das aktuelle Quantil. Bei reichlicher Datenlage sinnvoll (SCAN_001 von absurd-niedrig 8 → realistisch 1 049). Bei sparsamer Datenlage problematisch — SCAN_004 fiel von 28 auf 8, was praktisch jedes Subnet-Discovery alarmiert hätte. Daraus folgt RT2.

Test RT2 — Floor-Constraint (Commit c776cc0)

Sanity-Floor in tuner._postprocess(): getunte Schwelle wird nie unter schema.default × TUNER_FLOOR_FACTOR geklemmt (Default 0,3, ENV-tunbar).

max_change_per_cycle=0,20 greift parallel und limitiert auf old × 1,2 = 9,6 → int(9). Floor und max_change zusammen ergeben in diesem Cycle 9. Verifiziert.

Test RT3 — FP/TP-Konflikt-Pfad (Bug + Fix Commit afe8e49)

Synthetische Markierungen: 5× FP mit metric_value=11, 3× TP mit metric_value=9. → FP_lower = 12, TP_upper = 9 → Konflikt. Spec sagt: alten Wert behalten + Warning.

Bug-Beobachtung

value=50  value_internal=None  fp_seen=5  tp_seen=3  fp_max=12  tp_min=9

value_internal wurde auf None gesetzt → signature-engine fällt auf YAML-Default zurück (1 050 → 50, massiver Sprung).

Fix verifiziert

1. TPs entfernt → kein Konflikt → Cycle setzt value_internal = 1 050.
2. TPs wieder gesetzt → Konflikt → Cycle bewahrt value_internal.

2026-04-30T19:48:38 WARNING tuner – Rule SCAN_001/port_count: FP/TP-Konflikt
                              (FP_max+1=12.0 > TP_min=9.0) — alten Wert behalten
value=50  value_internal=1050  fp_seen=5  tp_seen=3  fp_max=12  tp_min=9

Bewertung: Konflikt-Pfad bewahrt jetzt sowohl value als auch value_internal aus dem existing_param-Eintrag. Skalar-Override-Form (Backwards-Compat) trägt kein value_internal — bleibt dort None (war schon vorher so).