Einführung
Der Routendetektor des Teams meldet jeden POST an collector.example.test/collect. Manche sind erlaubte öffentliche Demonstrationen. Du sollst interne Dokument-Uploads erkennen und erlaubte Übertragungen erhalten.
Die unabhängige Umgebung enthält broad.rules, den vorherigen Routendetektor, sowie vollständige synthetische TCP/HTTP-Mitschnitte. Verwende den Tab Analyst für Befehle und wähle den Tab Traffic Reference für die Ansicht der aufgezeichneten Anfragen; sie öffnet sich direkt. Dieselben Beispiele stehen in traffic/requests.txt. Dateien der vorherigen VM sind nicht nötig. Die Inhaltsprüfung gilt für dieses unverschlüsselte HTTP, nicht für verschlüsseltes HTTPS.
Den Kontext sensibler Dokumente finden
In diesem Schritt siehst du, warum ein Body-Hinweis nützlich ist, allein aber nicht genügt. classification=internal ist ein synthetisches Geschäftsfeld für die Behandlungskategorie eines Dokuments, kein Abschlussmarker.
Wähle zu Beginn dieses Schritts den Tab Analyst in der Lab-Oberfläche aus.
Wechsle zum Tab Traffic Reference, um die Anfrageinhalte zu vergleichen, und dann zurück zum Tab Analyst. Lies die Referenz und führe den vorbereiteten Detektor mit dem folgenden Suricata-Befehl gegen den aufgezeichneten PCAP-Mitschnitt aus. Die Optionen bleiben gleich: ausschließlich gewählte Regeln mit -S, Eingabe-PCAP mit -r, Ausgabeordner mit -l.
Wechsle zum Tab Analyst, bevor du den folgenden Befehl ausführst.
cat traffic/requests.txt
mkdir -p broad-output
suricata --runmode single -c suricata.yaml -S broad.rules -r traffic/core.pcap -l broad-output --init-errors-fatal
python3 /opt/c09/read-alerts.py broad-output/eve.json
Erwarte vier Alarme, darunter zwei öffentliche Dokumente. classification=public bedeutet, dass der Inhalt auf dieser Route öffentlich demonstriert werden darf. Die Richtlinie kombiniert Methode, Ziel, Route und interne Klassifizierung.
Probiere einen reinen Body-Detektor für den neuen Buffer. http.request_body lässt nachfolgendes content den rekonstruierten Body prüfen, auch über TCP-Paketgrenzen hinweg. Die Engine setzt die Daten zusammen; eine Textsuche in einzelnen Paketen wäre nicht gleichwertig. Wir verlangen keine vollständigen Buffer-Grenzen, denn die Klassifizierung ist nur ein Feld eines längeren Bodys.
Nutze wieder wörtliche mehrzeilige Eingabe: > ersetzt die Datei und das abschließende RULE steht allein auf einer Zeile.
cat > body.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.request_body; content:"classification=internal"; sid:1000001; rev:1;)
RULE
mkdir -p body-output
suricata --runmode single -c suricata.yaml -S body.rules -r traffic/core.pcap -l body-output --init-errors-fatal
python3 /opt/c09/read-alerts.py body-output/eve.json
Erwarte Alerts: 9. Jetzt alarmieren auch interne Dokumente an erlaubten Zielen, PUT-Anfragen und andere Empfängerrouten. Ein sensibles Wort an beliebiger Stelle zu suchen ist zu weit gefasst. Behalte das Ergebnis als Experiment, nicht als endgültigen Richtliniendetektor.
python3 /opt/c09/check.py body.rules body
Beide Datensätze sollen neun Übertragungen mit diesem Body melden. Syntaxfehler lassen sich beheben: Schreibe den Block neu und verwende beim Wiederholen einen neuen Ausgabeordner, damit angehängte Ereignisse die Anzahl nicht verfälschen.
Bedingungen kombinieren und das Gleichgewicht prüfen
In diesem Schritt kombinierst du die vier gelernten HTTP-Felder. Behalte POST, den exakten Empfängerhost und die genaue Upload-Route bei und ergänze die interne Klassifizierung.
Wähle zu Beginn dieses Schritts den Tab Analyst in der Lab-Oberfläche aus.
Erstelle local.rules als endgültiges Ergebnis. Bedingungen unterschiedlicher Sticky Buffer sind mit AND verknüpft: Die Transaktion muss alle erfüllen. sid:1000001 bleibt eine eindeutige lokale Kennung; eine aktive Regel genügt.
Wechsle zum Tab Analyst, bevor du den folgenden Befehl ausführst.
cat > local.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; http.host; content:"collector.example.test"; startswith; endswith; http.uri; content:"/collect"; startswith; endswith; http.request_body; content:"classification=internal"; sid:1000001; rev:1;)
RULE
Teste vor der Wiedergabe die Syntax mit -T. Der Ordner und -l geben auch dem Syntaxtest eine beschreibbare Ausgabe. Konfiguration und Regeln werden ohne Paketlesen geladen. Korrekte Syntax beweist noch keine gute Erkennung.
mkdir -p syntax-output
suricata -T -c suricata.yaml -S local.rules -l syntax-output --init-errors-fatal
mkdir -p final-output
suricata --runmode single -c suricata.yaml -S local.rules -r traffic/core.pcap -l final-output --init-errors-fatal
python3 /opt/c09/read-alerts.py final-output/eve.json
Erwarte Alerts: 2 für 41002 und 41007. Jeweils geht ein internes Dokument per POST an die nicht genehmigte Empfängerroute. Öffentliche Demonstrationen, genehmigte Uploads, Zustandsabfragen, andere Methoden und Routen bleiben still. Alarme melden weiterhin action: allowed: Offline-Erkennung beobachtet, verhindert aber keinen Upload.
Führe den ausgewogenen Regressionstest aus. Nach einer Änderung wiederholt er bekannte erforderliche und verbotene Treffer. Er verwendet frische Ausgaben für den sichtbaren Datensatz und weitere Fälle mit anderen Dokumentnamen und Ports. Geprüft wird die Regel, nicht die alte Ereignisanzahl.
python3 /opt/c09/check.py local.rules final
Beide Zeilen sollen zwei erwartete Übertragungen und stille Vergleichsfälle melden. Wiederhole den Test: Ergebnis und Mitschnitt müssen gleich bleiben. Fehlende Alarme deuten auf zu enge Bedingungen oder falsche Buffer hin, unerwartete auf fehlende oder lockere Bedingungen. Schreibe local.rules neu und versuche es erneut. Deaktiviere die Engine nicht und entferne keine legitimen Vergleichsdaten.
Das ist ein begrenzter Richtliniendetektor, keine universelle Datenverlust-Erkennung. Größere Inhalte, Verschlüsselung, Kodierungen und weitere Protokolle benötigen eigene Planung und Tests. Die Challenge ändert die Richtlinienfakten und verwendet dieselben vier Buffer.
Zusammenfassung
Du hast einen reinen Routendetektor mit einem reinen Body-Experiment verglichen und danach alle vier HTTP-Felder kombiniert. Du hast die Regel mit ausgewogenen Datensätzen in frischen Ausgabeordnern geprüft und die Sichtbarkeitsgrenzen erklärt.
