Einführung
Ein Dokumentteam lädt normalerweise Dateien zu docs.approved.test hoch. Ein kleiner Mitschnitt enthält auch Uploads an ein anderes Ziel. Du darfst für diese synthetischen Übertragungen einen Offline-Detektor erstellen.
Ein Paketmitschnitt (PCAP) speichert Netzwerkpakete. Suricata rekonstruiert ihre HTTP-Anfragen und testet Erkennungsregeln. Hier liest es Dateien und kontaktiert die Hostnamen nicht. Alle Namen und Dokumente sind erfunden. Unverschlüsseltes HTTP macht den Inhalt sichtbar; das Lesen verschlüsselten HTTPS-Verkehrs wird nicht gezeigt.
Verwende den Tab Analyst für Befehle. Wähle den Tab Traffic Reference, um dieselben vorbereiteten Anfragen wie in traffic/requests.txt zu sehen; die Referenzseite öffnet sich direkt. Dies sind Aufzeichnungen, keine aktive Topologie. Grundlegende Terminaleingabe und Tab-Wechsel genügen; IDS-Kenntnisse werden nicht vorausgesetzt.
Upload-Anfragen erkennen
In diesem Schritt erstellst du eine erste Regel für POST-Anfragen einschließlich normaler Uploads. Ein Alarm bedeutet eine Regelübereinstimmung, beweist keinen Einbruch und blockiert keinen Verkehr.
Wähle zu Beginn dieses Schritts den Tab Analyst in der Lab-Oberfläche aus.
HTTP ist ein Anfrage-Antwort-Protokoll. Die Methode benennt die Aktion: POST sendet Inhalte, GET fordert Ressourcen an. Der Host-Header nennt die Zielwebsite, die URI die Route und der Body enthält übermittelte Dokumentfelder. Wechsle zum Tab Traffic Reference, um die vorbereiteten HTTP-Übertragungen im Browser zu sehen. Die Seite ist eine Referenz, keine Live-Paketüberwachung. Wechsle anschließend zurück zum Tab Analyst, um dieselben Übertragungen zu lesen und alle folgenden Befehle auszuführen. cat zeigt eine Datei an; Pfade geben ihren Ort an.
Wechsle zum Tab Analyst, bevor du den folgenden Befehl ausführst.
cat traffic/requests.txt
Vergleiche den legitimen POST an docs.approved.test, den GET des Empfängers und den POST mit classification=internal. Interne Dokumente dürfen zum genehmigten Dokumentdienst. Die Empfängerroute erlaubt öffentliche Beispieldokumente, jedoch keine internen. Ziel und Inhalt zählen gemeinsam; ein unbekannter Hostname allein ist kein Beweis.
Eine Suricata-Regel enthält einen Kopf und Optionen in Klammern. alert http wählt Alarme für analysiertes HTTP. Die beiden Paare any any erlauben beliebige Quell-/Zieladressen und Ports; -> zeigt von Quelle zu Ziel. flow:established,to_server begrenzt die Prüfung auf Anfragen eines verbundenen Clients. Semikolons beenden Optionen. msg beschreibt den Treffer, sid ist die numerische Signaturkennung und rev die Revision. Jede Regel verwendet eine eindeutige sid.
Ein Sticky Buffer bestimmt das HTTP-Feld für nachfolgendes content. http.method wählt die Methode. content:"POST" sucht den Text; startswith und endswith verlangen das vollständige Feld statt einer Teilzeichenfolge. Verwende die folgende Regel.
cat > method.rules schreibt die Datei und ersetzt alten Inhalt. <<'RULE' beginnt wörtliche mehrzeilige Eingabe; das abschließende RULE muss allein auf einer Zeile stehen. So kannst du einfach editieren. Bei Tippfehlern führst du den ganzen Block erneut aus.
cat > method.rules <<'RULE'
alert http any any -> any any (msg:"Review document upload"; flow:established,to_server; http.method; content:"POST"; startswith; endswith; sid:1000001; rev:1;)
RULE
Gib den Mitschnitt wieder. mkdir -p erstellt den Ausgabeordner und akzeptiert vorhandene Ordner. --runmode single verwendet einen Paketverarbeitungs-Thread; -c wählt die Konfiguration, -S lädt ausschließlich deine Regeldatei, -r liest den PCAP und -l wählt die Ausgabe. --init-errors-fatal stoppt bei nicht ladbaren Regeln. Die Konfiguration prüft höchstens 64 KB pro Anfrage-Body; alle Beispiele passen hinein. Reale Bereitstellungsgrenzen müssen separat geprüft werden.
mkdir -p method-output
suricata --runmode single -c suricata.yaml -S method.rules -r traffic/core.pcap -l method-output --init-errors-fatal
python3 /opt/c09/read-alerts.py method-output/eve.json
Suricatas Stoppmeldung am Ende der Offline-Datei ist normal. eve.json enthält ein JSON-Objekt pro Ereignis. JSON nutzt benannte Felder: event_type: alert kennzeichnet einen Treffer, signature_id seine Regel und HTTP-Felder die Anfrage. Das mitgelieferte Python-Leseprogramm zeigt Quellport, Methode, Host, URI und Signaturkennung jedes Alarms. Der Quellport ordnet die Übertragung der Referenz zu; er ist keine Richtlinienbedingung.
Erwarte Alerts: 10. Normale Dokument-POSTs und Empfänger-POSTs erscheinen. GET und PUT bleiben still. Der bewusst breite erste Detektor vermittelt Methodenabgleich.
Der Prüfer führt deine unveränderte Regel auf zwei kleinen unabhängigen Datensätzen in temporären Ausgabeordnern aus. Er ignoriert gespeicherte Protokolle und verändert weder Regeln noch Mitschnitte. Prüfe den Methodendetektor:
python3 /opt/c09/check.py method.rules method
Beide Zeilen sollen 10 beabsichtigte Übertragungen melden. Bei Syntaxfehlern prüfst du Anführungszeichen, Semikolons und die schließende Klammer, schreibst neu und versuchst es erneut. Im selben Ausgabeordner werden Ereignisse angehängt; verwende zum Zählen einen neuen Ordner. Der Prüfer beginnt immer mit einer leeren Ausgabe.
Den Empfänger als Ziel auswählen
In diesem Schritt kombinierst du Methode und Host, um normale Dokument-Uploads auszuschließen. Alle Buffer einer Regel müssen auf dieselbe HTTP-Transaktion passen.
Wähle zu Beginn dieses Schritts den Tab Analyst in der Lab-Oberfläche aus.
Der Name der Zielwebsite gehört zu http.host, nicht in die Body-Suche. Ein Dokument kann den Empfänger erwähnen, ohne dorthin gesendet zu werden. Suricata normalisiert den Host-Buffer auf Kleinbuchstaben. collector.example.test.other.test in der Referenz ist ein anderer Host. Vollständiger Feldabgleich hält ihn getrennt.
Erstelle eine neue Datei und behalte den ersten Detektor zum Vergleich. Kopf und Methodenbedingung bleiben; der neue Host-Buffer ergänzt das Ziel.
Wechsle zum Tab Analyst, bevor du den folgenden Befehl ausführst.
cat > destination.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; sid:1000001; rev:1;)
RULE
mkdir -p destination-output
suricata --runmode single -c suricata.yaml -S destination.rules -r traffic/core.pcap -l destination-output --init-errors-fatal
python3 /opt/c09/read-alerts.py destination-output/eve.json
Erwarte Alerts: 6. Genehmigter Dokumentdienst und ähnlich benannter Host verschwinden. POSTs an /status und /collect-backup passen weiterhin, weil Routen noch nicht unterschieden werden. Diese bekannten Fehlalarme zeigen Treffer außerhalb des zu untersuchenden Verhaltens.
python3 /opt/c09/check.py destination.rules destination
Beide Datensätze sollen sechs passende Methoden-Host-Übertragungen melden. Meldet ein erlaubter Host noch Alarme, prüfe startswith; endswith; nach dem Host-Inhalt. Eine gespeicherte JSON-Zeile zu ändern repariert den Detektor nicht; ändere die Regel und wiederhole die Wiedergabe.
Erkennung auf die Upload-Route begrenzen
In diesem Schritt erstellst du einen funktionierenden Routendetektor und erkennst seine verbleibende Inhaltsgrenze. Die URI bezeichnet die Route, etwa /collect, und unterscheidet sich vom Host.
Wähle zu Beginn dieses Schritts den Tab Analyst in der Lab-Oberfläche aus.
Wähle mit http.uri und vollständigem Feldabgleich genau /collect. /collect-backup ist eine andere Route. Behalte Methode und Ziel bei, damit Zustandsabfragen und legitime Ziele still bleiben.
Wechsle zum Tab Analyst, bevor du den folgenden Befehl ausführst.
cat > upload.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; sid:1000001; rev:1;)
RULE
mkdir -p route-output
suricata --runmode single -c suricata.yaml -S upload.rules -r traffic/core.pcap -l route-output --init-errors-fatal
python3 /opt/c09/read-alerts.py route-output/eve.json
Erwarte Alerts: 4 für 41002, 41003, 41007 und 41011. Vergleiche die Inhalte in der Referenz: zwei interne und zwei öffentliche Beispieldokumente. Alle vier sind POSTs an den gewählten Host und die Route. Die Routenüberwachung funktioniert, überschätzt aber sensible Uploads.
python3 /opt/c09/check.py upload.rules route
Beide Datensätze sollen vier beabsichtigte Routenübertragungen treffen. Der Prüfer variiert auch Dokumentnamen und Quellports: solche Nebenwerte dürfen die Erkennung nicht bestimmen. Erkläre beim Weitergeben der Alarme den Regelzweck. Im nächsten Lab ergänzt du Dokumentkontext und testest weniger Fehlalarme in einer frischen Umgebung.
Zusammenfassung
Du hast mit echter Suricata-Wiedergabe Detektoren für Methode, Ziel und Route erstellt. Du hast Alarme aufgezeichneten Anfragen zugeordnet und Fehlalarme öffentlicher Dokumente erkannt, bevor du von der Erkennung sensibler Uploads gesprochen hast.
