pcap_or_it_didnt_happen.sh

Vor einiger Zeit kam ein potenzieller Neukunde mit einer Projektanfrage auf uns zu: Firewall-Migration, über 1.000 Regeln auf 50 Interfaces. Verbindungen zu Kunden, Lieferanten, Support-Partnern—aber keine Dokumentation, keine Kommentare, kein IPAM. Der Admin, der das aufgebaut hat, ist seit Jahren weg. Ein anderer Dienstleister hatte 8 Monate veranschlagt.

Wir haben es anders gemacht: Firewall-Interfaces gespiegelt, eine Woche Traffic mitgeschnitten, ein Skript geschrieben, das die PCAPs parst und Access-Lists generiert. Das Ergebnis muss trotzdem geprüft werden—bei Firewall-Regeln gilt Vier-Augen-Prinzip—aber man kommt schneller zu den ersten 90%. Die Migration war in 4 Wochen abgeschlossen.

Die Skripte sind geblieben und zu einem Toolkit gewachsen. Traffic mitschneiden mit tcpdump, auf S3 hochladen, ERSPAN-Captures nach Host aufteilen, ACL-Regeln generieren. Aktuell Cisco-ASA-Syntax, aber die Analyse ist herstellerunabhängig—für Palo Alto oder Fortinet braucht es nur andere Templates.

Das Toolkit

Basiert auf Scapy für das Parsing der Pakete. Nutzt Pythons ProcessPoolExecutor für echtes Multiprocessing, volle CPU-Auslastung. GNU Parallel für Batch-Verarbeitung über Hosts. S3/MinIO-Integration für Storage. Beim ersten Projekt haben wir 10TB an PCAPs verarbeitet—und das waren nur die Packet-Header!

Fünf Skripte:

• pcap_or_it_didnt_happen.sh — Schneidet Traffic mit tcpdump mit, rotiert Dateien, lädt auf S3 hoch. Läuft auf dem Host oder SPAN/ERSPAN-Collector.
• split_erspan_pcaps.py — Teilt Multi-Host ERSPAN/SPAN-Captures in Per-Host PCAPs auf. Handhabt GRE-Dekapsulierung. Parallele Verarbeitung.
• generate_pcap_csv.py — Erstellt Inventory-CSV aus PCAP-Dateien. Mappt Hostnamen auf IPs anhand von ASA-Objektdefinitionen.
• process_pcaps.sh — Batch-Prozessor. Gruppiert aufgeteilte Dateien nach Hostname, führt Analyse parallel mit GNU Parallel aus.
• pcap_to_acl.py — Kern-Engine. Parst PCAPs, erkennt Verbindungsrichtung, generiert deduplizierte Access-Lists.

Workflow

Standard (Per-Host Captures)

pcap_or_it_didnt_happen.sh → generate_pcap_csv.py → process_pcaps.sh

Das einfachste Setup: Capture-Skript auf jedem Host laufen lassen, den Sie analysieren möchten, dann eine Inventory-Datei generieren, die Hostnamen auf IPs mappt, und schließlich alles zu ACLs batch-verarbeiten.

ERSPAN/SPAN (Multi-Host Captures)

pcap_or_it_didnt_happen.sh → split_erspan_pcaps.py → generate_pcap_csv.py → process_pcaps.sh

Wenn Sie Traffic von mehreren Hosts auf einen einzelnen Collector spiegeln, gibt es einen zusätzlichen Schritt. Das Split-Skript trennt den kombinierten Capture in Per-Host PCAPs auf, bevor verarbeitet wird. Es handhabt sowohl GRE-gekapseltes ERSPAN als auch regulären SPAN Traffic automatisch.

Beispiel-Output

! ACL-Regeln für webserver01 (10.1.1.10) - DMZ Zone
! Generiert aus PCAP-Analyse

access-list acl-DMZ-in extended permit tcp object o-webserver01-v4 object o-appserver-v4 eq 8080
access-list acl-DMZ-in extended permit tcp object o-webserver01-v4 object o-appserver-v4 eq 8443

! ACL-Regeln für appserver01 (10.2.1.10) - APPS Zone

access-list acl-APPS-in extended permit tcp object o-appserver01-v4 object o-database-v4 eq 5432
access-list acl-APPS-in extended permit tcp object o-appserver01-v4 object o-redis-v4 eq 6379

Der Output nutzt Ihre Hostnamen und FQDN-Inventory um aussagekräftige Objektnamen statt ACL-Einträge mit IPs zu bauen. Regeln werden über alle Capture-Dateien pro Host dedupliziert, sodass Sie nicht mit tausenden doppelten Einträgen enden.

Die Probleme

Der erste Kunde war kein Einzelfall. Das gleiche Muster sehen wir immer wieder:

• Hardware-EOL-Ankündigung kommt rein. Migration auf neue Firewall nötig.
• Keiner weiß, was die Hälfte der Regeln macht. Der Admin, der die Umgebung aufgebaut hat, ist längst weg.
• Dokumentation existiert, aber von 2017. Seitdem wurde 300 mal am Ruleset geändert.
• Manche Regeln haben "temporary fix" im Kommentar. Seit vier Jahren.
• Irgendwo ist ein "permit any any", das keiner zu löschen wagt.

Der traditionelle Ansatz: jeden Application Owner befragen, alte Tickets durchgehen (falls die noch existieren), fundiert raten. Dauert Monate. Übersieht trotzdem Sachen.

Wie wir helfen

Wir spiegeln Firewall-Interfaces und schneiden nur Header mit—keine Payload-Daten. Captures gehen auf Ihren On-Site S3 oder einen unserer Standorte. Verarbeitung kann vor Ort oder in unserer Infrastruktur passieren. Die Dauer hängt von Ihrer Umgebung ab—wenige Tage für einfache Setups, eine Woche oder mehr wenn Batch-Jobs oder monatliche Prozesse erfasst werden müssen.

Das Toolkit verarbeitet die PCAPs und generiert Regeln. Aber das sind nur die ersten 90%. Die restlichen 10% werden interessant.

Wir prüfen alle generierten Regeln mit Ihren Application Teams. Gehen sie Zeile für Zeile durch. "Dieser Server spricht mit der Datenbank auf Port 5432—ist das erwartet?" Manchmal ja. Manchmal "Moment, der Server wurde letztes Jahr stillgelegt." Manchmal "das ist der Managementpfad unsers Backup-Systems, das mit dem alten Storage Array spricht und wir scheinbar vergessen haben abzuklemmen."

Verdächtige Funde werden markiert. Unbekannte Traffic-Muster werden untersucht. Am Ende haben Sie nicht nur ein funktionierendes Ruleset—Sie haben ein dokumentiertes Ruleset, in dem jede Regel einen Grund hat, und Sie haben Verbindungen aufgeräumt, die nicht mehr existieren sollten.

Typisches Engagement: 2–4 Wochen von Kickoff bis fertiges Ruleset. Implementierungs-Timeline hängt von Ihrem Change-Management-Prozess ab.

FAQ