Erkennungen + Regelsätze für JA3-Sequenzen

Überblick — was der Bildschirm leistet

Security ▸ Detections (/security/detections) ist das Erkennungs-Flaggschiff von InfraGuard. Er führt drei Dinge auf einer Seite zusammen:

1. Erzählung der Erkennungsalgorithmen — Lern-Popover erklären, wie jede Engine Bedrohungen fängt (Kitsune ML · srct-Heuristiken · nginx is_suspicious · JA3).
2. Erzählung nach der Erkennung — zeigt anhand echter Daten die auffälligen IPs · verdächtigen Web-Zugriffe · Laufhistorie, die jede Engine im jüngsten Fenster erfasst hat.
3. ★ Regelsätze für JA3-Sequenzen — eine deterministische Heuristik liest die chronologische JA3-Fingerabdruckfolge einer einzelnen Quell-IP und zählt ihr „fortlaufendes anomales Verhalten“ als fachsprachliche Regelsätze auf, gespeichert in infr_sec_ruleset.

Erfassung und automatische Sperrung laufen im Backend bereits (die alte stats-design-Oberfläche zeigte nur Firewall- und Blacklist-Tabellen) — der Zweck dieses Bildschirms ist es, diese verborgene Telemetrie als verlässliche Erzählung sichtbar zu machen.

Dieser Bildschirm ist überwiegend lesend + Analyse auf Abruf. Die Detektoren selbst (kts_tx · srct_tx · eve_ingest) sind Node-Collectors, die unter pm2 auf den Zielhosts laufen; die Anwendung liest nur die Tabellen, die sie füllen. Sie schnüffelt selbst niemals Datenverkehr mit.

Der LLM-Erzählpfad wurde am 2026-09-04 entfernt. Früher schickte die Analyse die Sequenzzusammenfassung an einen KI-Adapter und speicherte dessen Freitextantwort. Drei gemessene Probleme haben das beendet: Die Schlussfolgerung des LLM („JA3-Rotation“) war dieselbe, die eine dreizeilige Verhältnisrechnung bereits lieferte — bei rund 9.100 Token pro Lauf; der Freitext fror die Sprache des Schreibenden ein, sodass englische Sitzungen koreanische Karten lasen; und der Schreibpfad stempelte provider/model selbst im Rückfallfall aus dem Adapter, weshalb 10 von 13 gespeicherten Zeilen model=kimi-k2.6 behaupteten, obwohl sie Vorlagenausgabe waren. Die Analyse ist nun rein heuristisch — kein externer Aufruf, keine Token-Kosten — und provider/model halten fest, was tatsächlich lief.

Wann man ihn nutzt

• Um anhand des JA3-Rotationsmusters zu beurteilen, ob eine IP ein Botnet / automatisierter Scanner ist.
• Um auf einen Blick zu sehen, was die IDS-/ML-/nginx-Engines gerade fangen (Einstiegspunkt für die Triage).
• Um Erkennungs-Collectors auf einem neuen Host auszurollen (pm2-Befehl / Quellcode kopieren).
• Um aus den auffälligsten JA3-Verursachern Regelsätze mit Sperr- oder Meldeempfehlung zu machen.
• Wenn man aus Overview / Threats per Direktlink kommt, um eine bestimmte IP sofort zu analysieren (?ip=-Vorauswahl).

Aufbau

KPI-Leiste

Die ersten beiden KPI heißen „KI“, weil Kitsune tatsächlich ein Autoencoder des maschinellen Lernens ist — diese Bezeichnung stimmt und bleibt.

Panel der Erkennungsalgorithmen (Edu-Popover)

Jede Engine-Karte öffnet ein Lern-Popover mit Prinzip · was sie beobachtet · Tipps. Der Text liegt im statischen Sprachpaket security.det.edu.*.

• Kitsune — Anomalieerkennung per Autoencoder-Ensemble
• srct — heuristischer Suricata-Autoblocker (5 Kategorien)
• nginx is_suspicious — Marker für Webangriffe nach TLS-Terminierung
• JA3-Sequenzanalyse — der Star dieses Bildschirms

pm2-Rollout-Anleitung

Liefert Befehl und Quellcode, um die 5 Erkennungs-Collectors als pm2-Cron auf einem Zielhost auszurollen (siehe Datenquellen · pm2-Tabelle).

Erkennungsprotokoll & Laufhistorie

• Auffällige IPs (Kitsune-Top) — die 50 höchsten nach anomaly_score: IP · Score · Sitzungszahl · Sperr-Flag · run_ts.
• Verdächtiger Webverkehr (nginx-Top) — die 12 häufigsten is_suspicious-Treffer: src_ip · Hits · letzter Zeitstempel.
• Laufhistorie — die 30 jüngsten Zeilen aus kitsune_process_log · srct_process_log (geprüft/gesperrt · Meldung).

JA3-Verursacher & Regelsätze

• Verursacherliste — die 12 auffälligsten JA3-Verursacher über ein festes 6-Stunden-Fenster: ja3_variety · tls_conns · sni_variety · last_ts · Land (geo). Das eigene Netz (IP /24 registrierter Instanzen) wird ausgeschlossen.
• Regelsatztabelle — gespeicherte Regelsätze (die letzten 60): Entität · Verhalten · Kategorie · Schweregrad · Empfehlung · Konfidenz · Herkunft. Pro Zeile Aktivieren / Zurückstellen / Löschen.

Vorgehen

1) Erkennungslage überblicken

Der Bereichsschalter (1h / 6h / 24h) oben ändert das Beobachtungsfenster (Standard 24h). KPI und Erkennungsprotokolle werden für dieses Fenster neu berechnet. Die Seite fragt etwa alle 30 s ab, der Dienst cacht 30 s.

Allein die Verursacherliste umfasst stets die letzten 6 Stunden, unabhängig vom gewählten Bereich. JA3-Rotation baut sich über mehrere Stunden auf; ein kurzes Fenster zeigt das Muster nicht (abgestimmt auf das 360-Minuten-JA3-Fenster der automatischen Sperrung).

2) JA3-Sequenzanalyse ausführen (★)

1. Wählen Sie eine IP aus der Verursacherliste (oder kommen Sie per Direktlink aus Overview/Threats) und klicken Sie [Analysieren].
2. Der Server holt die TLS-JA3-Sequenz dieser IP chronologisch aus suricata_tls_ct (Fenster = Betriebsrichtlinie sec_ai_window_min, Standard 60 Min. · bis zu 200 Zeilen).
3. Liegt die Sequenzlänge unter dem Minimum (sec_ai_min_seq, Standard 5), wird mit insufficient_sequence übersprungen.
4. Die Heuristik ordnet die Sequenz in Befunde ein (siehe Regeltabelle unten).
5. Das Ergebnis wird als Regelsätze gespeichert; Liste und der Trichter in Overview aktualisieren sich sofort.

Beispielantwort:

{
  "ok": true,
  "provider": "heuristic",
  "model": null,
  "saved": 1,
  "seq_len": 37,
  "findings": [
    { "key": "ja3_rotation",
      "params": { "conns": 37, "variety": 34 },
      "category": "tls_anomaly",
      "severity": "crit", "action": "block", "confidence": 91 }
  ]
}

Die Analyse ist deterministisch und kostenlos — dieselbe Sequenz ergibt immer dieselben Regelsätze, es wird nie ein externer Dienst kontaktiert, und sie funktioniert ohne Netzwerkzugang. Ein Lauf kostet nichts: Analysieren Sie ruhig erneut, sobald sich die Zahlen eines Verursachers ändern.

Heuristische Regeln

Befunde entstehen aus Sequenzstatistiken (rotation = ja3_variety / seq_len).

Sensible URLs werden über die Regex .env .git wp-config .aws /actuator phpunit /.. shell.php wp-login xmlrpc erkannt (aus nginx is_suspicious + suricata_http-Kontext).

Kategorien, Schweregrade und Empfehlungen werden vor dem Einfügen gegen die Spalten-Enums geprüft (recon · credential_access · exfil · bruteforce · c2 · tls_anomaly · scan · other / info · warn · crit / observe · block · isolate · report).

Formulierung der Regelsätze und Sprachen

Ein Befund wird als Identität gespeichert, nicht als Satz. heuristicFindings() liefert {key, params}; die Zeile behält rule_key + params (Migration 000783), und die Formulierung wird beim Lesen der Zeile in der Sprache des Lesenden angewandt.

• Der Text liegt in resources/lang/<locale>/security.php unter det.rule.<key>.{name,behavior} — übersetzt in alle 8 Konsolensprachen.
• Die Spalten name / behavior enthalten weiterhin die englische Fassung als Rückfall, damit Exporte, Audits und vor 000783 geschriebene Zeilen lesbar bleiben. Fehlt rule_key oder hat eine Sprache den Schlüssel nicht, wird der gespeicherte Text verwendet — der rohe Schlüssel wird nie angezeigt.
• Der Detections-Cache ist nach Sprache getrennt (infr:sec:det:<locale>:<range>). Ohne das würde eine koreanische Sitzung, die den 30-Sekunden-Cache füllt, ihre Formulierung an den nächsten englischen Leser weiterreichen — genau das geschah zuvor.

Vor 000783 erzeugte Zeilen behalten ihren ursprünglichen Text. Die Migration stellt rule_key nur dort wieder her, wo die Evidenz der Zeile selbst die alte Vorlage exakt reproduziert (kein Raten); Freitextzeilen aus dem alten LLM-Pfad bleiben eingefroren, bis diese IP erneut analysiert wird und sie ersetzt werden.

3) Regelsätze verwalten

Eine erneute Analyse ersetzt nur die maschinell abgeleiteten Regelsätze dieser IP (löscht entity_type=ip, entity_key=ip, source=ai und legt sie neu an) — von Hand verfasste Regelsätze bleiben erhalten.

Das Feld action eines Regelsatzes ist eine Empfehlung, keine Anweisung. Nichts handelt danach: Die automatische Sperrung berechnet die JA3-Rotation direkt aus suricata_tls_ct und liest infr_sec_ruleset nie. Ein Regelsatz mit action=block sperrt nichts — gesperrt wird über Blocklist oder durch den Autoblock-Scheduler.

4) Geplante Sammlung (Opt-in)

Der Befehl infr:sec-analyze durchläuft die auffälligsten JA3-Verursacher und sammelt Regelsätze. Es ist ein Einmalbefehl, der nach dem Lauf endet, lässt sich also gefahrlos einplanen (kein Daemon).

# Sperre umgehen und einmal ausführen (Debug)
php artisan infr:sec-analyze --force

# Einzelne IP analysieren (ignoriert die Sperre)
php artisan infr:sec-analyze --ip=203.0.113.10

• Sperre: Betriebsrichtlinie sec_ai_schedule_on (Standard 0 = aus). Ist sie aus, passiert nichts — aktivieren Sie sie im Sicherheits-Tab der Betriebsrichtlinie.
• Ein geplanter Lauf analysiert die obersten sec_ai_top_n (Standard 10) Verursacher.
• Der Zeitplan läuft alle 30 Minuten und verursacht, da die Analyse heuristisch ist, keine Token-Kosten und keine externen Aufrufe. Standardmäßig bleibt er nur deshalb aus, weil die Regelsätze informativ sind.

5) pm2-Rollout-Befehle kopieren

Die pm2-Karte bietet [Befehl kopieren] (pm2-Ausführungszeile), [Quellcode kopieren] (Snippet-Rumpf) und [Mit Instanzwerten füllen & kopieren] (Ersetzung der HOSTNAME/IP-Token). Der Quellcode stammt aus dem eingespielten Snippet in Inventory ▸ Tools (infr_snippet).

Datenquellen

Gelesene Alttabellen (nicht verändern)

Neue Tabellen im Besitz der Anwendung

• infr_sec_ruleset (Migrationen 000730 · 000783) — Regelsätze. Spalten: entity_type · entity_key · name · behavior · rule_key · params (json) · category · severity · action · confidence · ja3 · sequence (json) · evidence (json) · source (ai=maschinell abgeleitet | manual) · provider · model · status (draft|active|dismissed). Wird von SecurityAiService::persist() gefüllt.
• infr_snippet — pm2-Quellcode-Rümpfe.
• infr_audit_log — auditiert sec.ai_analyze · sec.ruleset_save · sec.ruleset_delete. Die erste Aktionszeichenkette bleibt unverändert, damit die bestehende Audit-Spur nicht in zwei Teile zerfällt.

pm2-Rollout-Collectors

Dienste und Routen

• DetectionService — baut KPI, Erkennungsprotokolle, Verursacher und Regelsätze (30-s-Cache pro Sprache, nur lesend über SecurityRepository); phrase() legt die Formulierung beim Lesen an.
• SecurityAiService — JA3-Sequenz → heuristische Befunde → Regelsatz-Upsert. Enthält keinen LLM-Aufruf.
• SecurityScope::excludePrefixes() — Ausschluss des eigenen Netzes (IP /24 registrierter Instanzen + Betriebsrichtlinie; nichts fest verdrahtet).

Zugriff

• Die Schreibschranke setzt der Controller in canWrite() durch (Session infr_user_level ≥ 2) — die Demo-Stufe kann weder analysieren noch Regelsätze bearbeiten.
• Die IP-Eingabe wird mit filter_var(FILTER_VALIDATE_IP) geprüft (ungültige IP → 422).
• Jeder destruktive Vorgang wird ins Audit-Log geschrieben → Audit.

Fehlerbehebung & FAQ

Analyse mit insufficient_sequence übersprungen — die suricata_tls_ct-Sequenz dieser IP liegt unter sec_ai_min_seq (Standard 5). Erweitern Sie das Fenster (sec_ai_window_min, Standard 60 Min.) oder wählen Sie aus dem 6-Stunden-Fenster der Verursacherliste eine aktivere IP.

• Ein alter Regelsatz erscheint in der falschen Sprache — er wurde vor 000783 geschrieben und trägt eingefrorenen Text. Analysieren Sie diese IP erneut; die neue Zeile speichert rule_key und folgt der Sprache des Lesenden. Zeilen zu IPs, die nicht mehr auftauchen, können aus der Tabelle gelöscht werden.
• KPI/Regelsätze ändern sich nicht — das liegt am 30-s-Cache samt Abfragetakt. Analyse und Speichern invalidieren den Cache sofort (flush, über alle Sprachvarianten), ein Neuladen zeigt sie also.
• Die Verursacherliste ist leer — in den letzten 6 Stunden gibt es in suricata_tls_ct keine JA3-Aktivität, oder alles wurde als eigenes Netz ausgeschlossen. Prüfen Sie, ob der Collector eve_ingest läuft.
• Der Zeitplan tut nichts — sec_ai_schedule_on=0 (Standard). Aktivieren Sie ihn im Sicherheits-Tab der Betriebsrichtlinie oder führen Sie ihn einmal mit --force aus.
• Alle Erkennungsprotokolle stehen auf null — der zuständige pm2-Prozess ist womöglich gestorben. Starten Sie ihn mit dem Rollout-Befehl der pm2-Karte neu und prüfen Sie die Laufhistorie.

Verwandt

• Sicherheitsübersicht — Verteidigungstrichter
• Bedrohungen — IDS-Bedrohungstriage
• Regelsätze — Katalog der Erkennungsregeln
• Automatische Sperrung
• Sperrliste & Reputation
• Betriebsrichtlinie