Erkennungs-Regelsätze

Überblick — was der Bildschirm leistet

Erkennungs-Regelsätze (/security/rulesets) ist die kanonische Bibliothek, die jede von InfraGuard beobachtete und bewertete Erkennungsregel zu 44 Regelsätzen in 11 Kategorien normalisiert. Der Bildschirm erledigt drei Dinge an einem Ort:

1. Überblick — ordnet Regelsatz-Karten innerhalb von Kategorieabschnitten an und zeigt für das gewählte Zeitfenster (1h/6h/24h) die tatsächliche Ereignisanzahl und den Zeitstempel der letzten Sichtung je Regelsatz.
2. Erläuterung — beschreibt jeden Regelsatz in drei Schritten (was er erkennt · warum er auslöst · Worst Case).
3. Wiedergabe — ein Klick auf eine Karte öffnet ein Modal mit den tatsächlich erfassten letzten Ereignissen dieses Regelsatzes, in einer engine-spezifischen Tabelle.

Der Kern des Entwurfs ist die Trennung von Klassifikationsstruktur und Erläuterungstext. Die Struktur (Kategorien, Regelsatz-Schlüssel, Trefferregeln je Engine) liegt in der gebietsschema-unabhängigen statischen SOT App\Support\SecurityRulebook (cache-sicher), der Erläuterungstext (Name, Bedeutung, Belege, Risiko) dagegen in resources/lang/{ko,en}/secrules.php. Das Frontend führt beide über key+category zusammen und rendert sie.

Dieser Bildschirm ist strikt schreibgeschützt. Er aktiviert, deaktiviert, bearbeitet oder löscht keine Regelsätze. Er ist ein Referenzkatalog, der die Frage beantwortet: „Was wird in dieser Organisation gerade beobachtet, und was bedeutet das?“ Die Stelle, an der die Erkennungskonstanten (Schwellenwerte/Fenster) tatsächlich geändert werden, ist Regeln und Schwellenwerte (Verwaltung ▸ Regeln).

Die 44 Regelsätze sind an echte Telemetrie angeschlossen

Regelsätze sind keine abstrakten Regeln — jeder ist über eine Trefferregel (match) an eine reale Erfassungstabelle gebunden. Alle Quellen liegen auf der Verbindung legacy_glory (die Alt-Datenbank, die die Collector-Flotte befüllt).

Wann Sie ihn nutzen

• Kontext vor der Triage gewinnen — wenn Sie in Bedrohungen oder Erkennungen · KI JA3 auf eine unbekannte Signatur stoßen, klären Sie, zu welcher Regelsatz-Familie sie gehört und was sie impliziert.
• Die Beobachtungslage überblicken — sehen Sie auf einen Blick, welche Kategorien in den letzten 24h auslösen und ob Web-Angriffe noch auf Aufklärungsniveau liegen oder bereits zu RCE-Sondierung eskaliert sind.
• Einarbeitung und Reporting — ein Schulungs- und Reporting-Artefakt, das nach Kategorie und Engine erklärt, „was wir erkennen“.
• Ereignisse wiedergeben — prüfen Sie die tatsächlichen Anfrage-IPs, URLs und Statuscodes, die ein bestimmter Regelsatz (z. B. web_secret_scan) zuletzt erfasst hat, und übergeben Sie Verdächtige anschließend an IP-Reputation oder Sperrliste.

Aufbau

KPIs im Kopfbereich

Intern werden außerdem Summen je Engine berechnet (Ereignissummen für kitsune und suricata), damit die Zahlen mit der Stufe „Regelsätze“ des Sicherheits-Abwehrtrichters konsistent bleiben.

Bedienelemente

• Fensterumschalter — 1h (60 Min.) · 6h (360 Min.) · 24h (1440 Min.). Standard 24h.
• Automatische Aktualisierung (LIVE) — fragt /security/rulesets/live ab, um die Zähler zu aktualisieren (pausierbar).
• Vollbild — blendet die obere Navigation für einen immersiven Dashboard-Modus aus (ESC zum Verlassen).

Kategorieabschnitte und Regelsatz-Karten

Die 11 Kategorien bilden Abschnitte in Anzeigereihenfolge, und innerhalb jedes Abschnitts werden die Regelsätze in einem minmax(600)-Kartenraster angeordnet. Jede Karte zeigt den Regelsatznamen, ein MDI-Symbol, ein Schweregrad-Abzeichen (crit/warn/info), die Ereignisanzahl im Fenster, den Zeitstempel der letzten Sichtung sowie [Open]. Ohne Ereignisse zeigt sie „ruhig / nichts im Fenster beobachtet“.

So gehen Sie vor

1) Fenster wählen → die Lage lesen

Wählen Sie zuerst das interessierende Fenster (1h/6h/24h). Nutzen Sie active (beobachtete Regelsätze) und die Ereignisanzahl jeder Karte, um zu sehen, was gerade auslöst. Beachten Sie: Das Schweregrad-Abzeichen ist ein implizierter Schweregrad — die meisten Suricata-Engine-Ereignisse sind sev3 (informativ), doch ihre Implikation unterscheidet sich (Rauschen / Scan / Exploit). Das Abzeichen des Regelsatzes spiegelt diesen Implikationston wider, nicht den rohen sev-Wert.

2) Auf eine Karte klicken → Modal mit den letzten Ereignissen

Ein Klick auf eine Karte ruft /security/rulesets/events?key=<rulesetKey>&range=<window> auf und öffnet ein Modal mit:

• Dreistufige Erläuterung — was er erkennt · warum er auslöst · Worst Case.
• Aggregate — Ereignisanzahl · eindeutige Quellen (distinkte src-IPs).
• Chips der passenden Signaturen (nur Suricata) — die tatsächlichen Signaturzeichenketten, die der sig-Teilstringtreffer dieses Regelsatzes erfasst hat, jeweils mit Anzahl und minimalem sev (Top 12).
• Engine-spezifische Ereignistabelle (die letzten 60 Zeilen).
• Quell-IP → Reputation — je src-IP eine Schaltfläche für das AbuseIPDB-Popup. Registrierte IPs des internen Netzes erhalten ein internal-Abzeichen, und die Reputationsschaltfläche wird ausgeblendet (verhindert, dass eigene Server für Angreifer gehalten werden).

Spalten der engine-spezifischen Ereignistabelle:

3) Priorität der Web-Angriffsklassifizierung (disjunkt)

Die 8 Web-Regelsätze (nginx) sind gegenseitig disjunkt. Eine einzelne is_suspicious=1-Anfrage wird in der Definitionsreihenfolge des Katalogs geprüft und genau einem zuerst passenden Regelsatz zugeordnet; passt keiner, fällt sie an den Auffangposten (web_suspicious_other). Dieselbe Anfrage wird also nie in zwei Web-Regelsätzen doppelt gezählt.

Aus Performancegründen aggregiert die Web-Klassifizierung über eine Stichprobe der jüngsten 6,000 Zeilen (Repository-Obergrenze 8,000). Während starker Scans werden Ereignisse außerhalb der Stichprobe womöglich nicht abgebildet — lesen Sie die Zahlen als Verteilung/Trend, nicht als absolute Zähler.

4) Was der Suricata-Teilstringtreffer impliziert

Suricata-Regelsätze lösen bei einem Teilstringtreffer in Kleinschreibung der Signaturzeichenkette aus. Beispielsweise summiert stream_invalid_ts jedes Ereignis, dessen Signatur invalid timestamp enthält. Ein einzelner Regelsatz kann mehrere tatsächliche Signaturen bündeln (im Modal als Chips „passende Signaturen“ sichtbar), und die sig-Schlüsselwörter verschiedener Regelsätze sind so entworfen, dass sie sich nicht überschneiden.

5) Gemessenes Beispiel (zur Orientierung)

Eine beispielhafte 24h-Momentaufnahme: 37 von 44 Regelsätzen lösen aus, stream_invalid_ts 10,243, web_secret_scan 3,304 (überwiegend 404 aus der .env-Familie), srct_heuristic 126,252, ja3_rotation 300 (Vielfalt 307/307). Die Werte variieren je nach Organisation und Zeitpunkt.

Datenquellen

Alle Quellen liegen auf der Verbindung legacy_glory (schreibgeschützt) und werden ausschließlich über config('database.connections.legacy_glory') erreicht — keine fest im Code hinterlegten Zugangsdaten.

Performance und Caching

• Der Kartenüberblick (build) wird 30 Sekunden zwischengespeichert (infr:sec:rulebook:<range>). Suricata holt das Signaturhistogramm einmalig und summiert die Teilstringtreffer über alle 44 Regelsätze, um N+1 zu vermeiden.
• JA3 schließt das eigene Netz (registrierte Instanz-IPs /24) per NOT LIKE über SecurityScope::excludePrefixes() aus und zählt nur Quell-IPs mit ja3_variety >= 2 als Auffällige.
• Modal-Ereignisse sind auf 60 Zeilen pro Fenster begrenzt. Jede Repository-Abfrage nutzt ein enges Zeitfenster + LIMIT + Parameterbindung.

Zugriff

• Schreibgeschützt. Die Controller-Prüfung ist level≥1 für Lesezugriffe, und das Betreten des Sicherheits-Rollenbereichs selbst ist über min_req=2 der Sitemap geschützt (Sicherheitsbetrieb) — in der Praxis erreichen ihn Staff (=5), Admin (=10) oder Benutzer mit Sicherheits-Scope.
• Da es keinen Schreibpfad gibt, gibt es weder eine Step-up-Bestätigung noch ein Audit-Log. /rulesets, /rulesets/live und /rulesets/events sind allesamt reine Lesezugriffe.
• Der Parameter key des events-Endpunkts wird nur aus der Katalog-Whitelist zugelassen. Schlüssel außerhalb der Liste liefern 404 unknown_ruleset (beliebige Tabellenabfragen sind nicht möglich).

Level-Konvention: demo=1 · staff=5 · admin=10. Einige Bereiche sind zusätzlich durch die Middleware infr.level:N geschützt. Das vollständige Stufenschema finden Sie unter RBAC-Level.

Fehlerbehebung und FAQ

Alle Karten zeigen „ruhig“

Entweder gibt es im gewählten Fenster (Standard 24h) keine passenden Ereignisse, oder die Verbindung legacy_glory ist nicht erreichbar. Der Dienst fängt Quellfehler kulant ab und zeigt leere Zähler (0) — Karten verschwinden nicht. Erweitern Sie das Fenster oder prüfen Sie die Verbindung.

Die Zähler der Web-Regelsätze weichen von [Bedrohungen] / [Erkennungen] ab

Die Web-Klassifizierung ist ein Verteilungsaggregat über eine Stichprobe der jüngsten 6,000 Zeilen (kein absoluter Zähler). Sie ist zudem disjunkt, sodass eine Anfrage genau einem Regelsatz zugeordnet wird. Die maßgebliche Ereignisquelle folgt der jeweils eigenen Abfrage jedes Bildschirms.

Eine bestimmte Signatur wird von keinem Regelsatz erfasst

Der Suricata-Abgleich erfolgt als Schlüsselwort-Teilstring-Treffer. Neue oder benutzerdefinierte Signaturen, die der Katalog nicht abdeckt, fließen in keinen Regelsatz-Zähler ein. Um sie zu klassifizieren und zu erläutern, fügen Sie das Signatur-Schlüsselwort dem sig-Array von SecurityRulebook hinzu — eine Codeänderung, keine Laufzeiteinstellung.

JA3-Auffällige sind 0, obwohl viel TLS-Verkehr anliegt

Der JA3-Regelsatz zählt nur Quell-IPs mit ja3_variety >= 2 (Fingerabdruck-Rotation) als Auffällige. Ohne Rotation gilt eine Quelle als normal und wird nicht gezählt. IPs des eigenen Netzes sind ebenfalls ausgeschlossen.

Eine IP zeigt im Ereignis-Modal ein internal-Abzeichen

Das ist eine registrierte IP des internen Netzes, ermittelt durch SecurityScope::internalMatchers(). Sie verhindert, dass eigene Server — die die Richtungslogik von Suricata als „Quelle“ ausweisen kann — für Angreifer gehalten werden, und blendet die Reputationsschaltfläche aus. Die Definition des internen Netzes wird unter internal_networks in der Betriebsrichtlinie verwaltet.

Verwandte Themen

• Erkennungen · JA3-Sequenzanalyse — der übergeordnete Bildschirm (Erkennungen); eine deterministische Heuristik leitet aus JA3-Sequenzen neue Regelsätze ab.
• Bedrohungen — Triage von IDS-Bedrohungsentitäten samt Signaturkunde.
• Sicherheitsübersicht — konsistent mit der Stufe „Regelsätze“ des Abwehrtrichters.
• IP-Reputation — prüfen Sie eine Quell-IP aus dem Modal gegen AbuseIPDB.
• Sperrliste — überführen Sie eine verdächtige Quelle in eine Sperre.
• Regeln und Schwellenwerte (Verwaltung ▸ Regeln) — justieren Sie tatsächlich die Konstanten der Erkennungs-Collector (Schwellenwerte/Fenster).