Netzwerk-Forensik: Was Sie bei einem Angriff sichern sollten

Netzwerk-Forensik ist in einem Sicherheitsvorfall oft der Unterschied zwischen „Wir haben etwas gemerkt“ und „Wir verstehen, was passiert ist“. Während Endpoint-Forensik auf einzelne Systeme schaut, liefert Netzwerk-Forensik den Gesamtzusammenhang: Welche Verbindungen wurden aufgebaut? Welche Daten flossen wohin? Welche Hosts haben sich lateral bewegt? Welche Accounts wurden missbraucht? Und welche externen Ziele (Command-and-Control, Drop-Zonen, Phishing-Hosts) waren beteiligt? Gerade bei modernen Angriffen – Phishing mit Session-Hijacking, Ransomware mit schneller Ausbreitung, Datenabfluss über verschlüsselte Kanäle oder Cloud-APIs – ist der Netzwerkblick unverzichtbar. Gleichzeitig ist Netzwerk-Forensik zeitkritisch: Viele Logs rotieren nach Tagen, NAT-Tabellen sind flüchtig, DHCP-Leases ändern sich, und paketbasierte Daten gibt es oft nur, wenn Sie sie aktiv erfassen. Dieser Artikel zeigt praxisnah, was Sie bei einem Angriff im Rahmen der Netzwerk-Forensik sichern sollten, in welcher Reihenfolge es sinnvoll ist und wie Sie Beweise so sammeln, dass sie technisch verwertbar, nachvollziehbar und im Zweifel audit- bzw. gerichtsverwertbar bleiben.

Grundprinzipien der Netzwerk-Forensik im Incident

Bevor Sie Daten einsammeln, sollten drei Prinzipien klar sein: Erstens müssen Sie Beweise sichern, ohne unnötig zu zerstören (z. B. durch Reboots oder massenhafte Konfigänderungen). Zweitens brauchen Sie Kontext, damit Daten später interpretierbar sind (Zeit, Zeitzone, Systemzuordnung, Verantwortliche). Drittens müssen Sie schnell entscheiden, welche Quellen flüchtig sind und daher Priorität haben.

• Beweissicherung vor Perfektion: Lieber schnell die wichtigsten Logs und Tabellen sichern, als erst eine „schöne“ Dokumentation zu schreiben.
• Chain of Custody: Wer hat was wann gesichert, wo wird es abgelegt, wer hat Zugriff?
• Zeitsynchronisation: Zeitabweichungen zerstören Korrelation. NTP-Status und Zeitzone sofort dokumentieren.
• Minimalinvasiv arbeiten: Änderungen an Firewalls, Proxies und Routern können Spuren verändern; erst sichern, dann ändern.

Priorität 1: Flüchtige Netzwerkdaten sichern

Flüchtige Daten sind Informationen, die im Minuten- oder Sekundenbereich verschwinden können. Dazu zählen Sessions, NAT-States, ARP-Tabellen, Routing-Neighbor-States, VPN-Sessionlisten oder aktive Proxy-Verbindungen. Diese Daten sind in der Netzwerk-Forensik extrem wertvoll, weil sie zeigen, was „jetzt gerade“ passiert.

Firewall- und NAT-States

• Aktive Sessions: Quell-IP/Port, Ziel-IP/Port, Protokoll, Startzeit, Bytes/Packets, Policy-ID
• NAT-Übersetzungen: Interne IP ↔ öffentliche IP/Port (entscheidend für Attribution bei Exfiltration)
• Conntrack/State Tables: Besonders wichtig bei Linux-basierten Firewalls/Appliances

VPN- und Remote-Access-Sessions

• Aktive Benutzer-Sessions: User, Quelle (Public IP), zugewiesene VPN-IP, Gruppen/Rollen
• Device-/Client-Infos: Client-Version, Plattform, Zertifikat/Fingerprint (falls vorhanden)
• Änderungen in Echtzeit: Neue Logins, häufige Fehlversuche, ungewöhnliche Geo-Standorte

Switching- und Routing-States

• ARP/ND-Tabellen: IP ↔ MAC Zuordnung, wichtig bei IP-Spoofing oder Rogue Devices
• MAC-Adress-Tabellen: Wo hängt ein Gerät physisch/logisch (Switchport, VLAN, Trunk)?
• Routing-Neighbor-Infos: BGP/OSPF/ISIS-Neighbors, Flaps, unerwartete Routen

Proxy-/SWG-Sessions

• Aktive Verbindungen: Ziel-Hostnames, URLs (wenn verfügbar), Kategorien, User-Identität
• TLS-Metadaten: SNI, Zertifikatsinfos, ggf. Inspection-Entscheidungen

Priorität 2: Zentrale Logs sichern

Die meisten Forensikfragen lassen sich über Logs beantworten – wenn sie vorhanden und zeitlich korrekt sind. Ziel ist, alle relevanten Logquellen schnell zu sichern und gegen Rotation/Überschreiben zu schützen. Idealerweise werden Logs ohnehin zentral gesammelt (SIEM, Logserver). Dann sichern Sie zusätzlich Rohdaten oder Export-Snapshots für den relevanten Zeitraum.

Firewall-Logs

• Allow/Deny: Besonders Denies und neue Allow-Flows sind wichtig für Anomalien
• Policy Hits: Welche Regel wurde verwendet? (Regel-ID/Name ist Gold wert)
• Threat Logs: IPS/AV/URL-Filter Events, Blockgründe, Signatur-IDs
• Admin-Aktivität: Konfigänderungen, Login-Versuche, neue Accounts, API-Tokens

VPN-Logs

• Authentifizierung: Erfolgreiche und fehlgeschlagene Anmeldungen
• Session-Events: Connect/Disconnect, IP-Zuweisungen, Gruppen-/Policy-Zuordnung
• MFA-Events: Push-Approvals, Fehlversuche, ungewöhnliche Muster

DNS-Logs

DNS ist eines der wichtigsten Forensiksignale, weil es häufig den „ersten Kontakt“ zu bösartigen Domains sichtbar macht. Auch bei verschlüsseltem Webtraffic kann DNS Aufschluss über Zielinfrastruktur geben.

• Query Logs: Wer fragt welche Domain an, wann, wie oft?
• NXDOMAIN-Spikes: Hinweise auf DGA oder Fehlkonfigurationen
• Neue/seltene Domains: Besonders bei Malware-Kampagnen relevant

Wenn Syslog als Transport genutzt wird, ist RFC 5424 eine hilfreiche Referenz für Format und Transportgrundlagen.

DHCP-Logs

• IP-Leases: IP ↔ MAC ↔ Hostname ↔ Zeitstempel (entscheidend für Gerätezuordnung)
• Lease History: Wer hatte eine IP zu einem bestimmten Zeitpunkt?

Proxy/SWG/WAF-Logs

• URL/Hostnames: Phishing-Landingpages, Malware-Downloads, Cloud-Exfiltration
• File Events: Downloads/Uploads, Malware-Detections, Sandbox-Verdicts
• Policy Decisions: Block/Allow, Kategorie, DLP-Treffer (falls vorhanden)

Identity- und Directory-Logs (netzwerkrelevant)

Viele Angriffe sind letztlich Identitätsangriffe. Ohne Identity-Logs bleibt Netzwerk-Forensik oft unvollständig.

• SSO/IdP Logs: Login-Events, Token-Ausstellungen, riskante Authentifizierungen
• AD/LDAP: Anmeldeereignisse, Kerberos-Anomalien, neue Admin-Gruppenmitgliedschaften

Priorität 3: Flow-Daten und Telemetrie sichern

Wenn Sie keine vollständigen Packet Captures haben, sind Flow-Daten die zweitbeste Quelle, um Netzwerkverhalten zu rekonstruieren. NetFlow/IPFIX/sFlow liefern Metadaten pro Verbindung: Quelle, Ziel, Ports, Bytes, Zeit. Das reicht oft, um laterale Bewegung, Datenabfluss oder C2-Verbindungen zu erkennen.

• NetFlow/IPFIX: Besonders wertvoll für Ost-West-Traffic und „wer spricht mit wem“
• sFlow: Sampling-basiert, gut für hohe Durchsätze, weniger vollständig
• Cloud Flow Logs: In Cloud-Netzen häufig die wichtigste Quelle (VPC/VNet Flow Logs)

Wichtig ist, Flow-Daten im Vorfallzeitraum zu exportieren und zu „freezen“, damit spätere Retention oder Normalisierung im System die Rohdaten nicht verändert.

Packet Capture: Wann PCAP wirklich nötig ist

Pakete sind der Goldstandard, aber nicht immer verfügbar oder sinnvoll. Für Netzwerk-Forensik sind PCAPs besonders hilfreich, wenn Sie Protokolldetails, Payload-Indikatoren oder genaue Handshakes analysieren müssen (z. B. bei Exploit-Verdacht oder Datenabflussmustern). Gleichzeitig können PCAPs datenschutzsensibel sein und schnell sehr groß werden.

Typische Anlässe für gezieltes Packet Capture

• Exploit-Verdacht: Ungewöhnliche Requests auf Web-UI, WAF/IPS meldet Exploit-Muster
• Datenabfluss: Verdächtiger Upload-Traffic, ungewöhnliche Sessions zu Cloud-Storage oder unbekannten Hosts
• DNS-Tunneling: Ungewöhnlich lange DNS-Labels, hohe Query-Raten
• Protokollmissbrauch: SMB/LDAP/SSH-Anomalien, Lateralmovement-Hinweise

PCAP praktisch sichern, ohne alles zu speichern

• Zielgerichtet: Capture nur für betroffene Hosts, Ports, Zonen oder Zeitfenster
• Ring Buffer: Rotierende Capture-Dateien, die bei Incident „eingefroren“ werden
• Metadata zuerst: Wenn Datenschutz kritisch ist, zuerst Flow/DNS/Proxy nutzen, PCAP nur bei Bedarf

Beweissicherung an Netzwerkgeräten: Was Sie exportieren sollten

Neben Logs und Sessions sind Konfigurationen und Zustände der Geräte entscheidend. Viele Angriffe verändern nicht nur Datenflüsse, sondern auch Policies, NAT, VPN-Profile oder Admin-Accounts. Ein Konfig-Export ist daher ein zentraler Forensikbaustein.

Firewall/NGFW

• Running Config: Vollständiger Konfigexport inkl. Policy, NAT, Objects, Interfaces, Routing
• Rulebase Snapshot: Export der Regelwerke mit Kommentaren/IDs
• Admin Accounts & Roles: Wer hat welche Rechte? Letzte Änderungen?
• Certificates/Keys (vorsichtig): Nur nach interner Policy; Schlüsselmaterial ist hochsensibel

VPN-Gateway

• Portal/Profiles: Zugriffsprofile, Split-Tunneling, Routen, erlaubte Ressourcen
• Auth-Integrationen: RADIUS/LDAP/SAML-Konfig, Zertifikate, MFA-Policies
• Session- und Login-Historie: Exporte aus dem relevanten Zeitraum

Switches/Router

• Konfiguration: VLANs, SVIs, ACLs, Routing-Protokolle, VRFs
• Port-Status: Welche MACs waren an welchen Ports, Port-Security-Events
• Routing-Tabellen: Unerwartete Routen, Policy-Based Routing, BGP/OSPF-Changes

WLAN-Infrastruktur

• Client History: Verbundene Clients, Zeiten, SSIDs, Roaming
• 802.1X/RADIUS Events: Authentifizierungsversuche, Failure Codes
• Guest Portal Logs: Anmeldungen, Gerätezuordnung (falls genutzt)

Zeitleiste und Korrelation: Was Sie immer parallel dokumentieren sollten

Netzwerk-Forensik ohne Zeitleiste ist wie Fehlersuche ohne Zeitstempel. Sobald Sie Daten sichern, sollten Sie eine Incident-Timeline mitführen: wann wurde was entdeckt, welche Änderungen wurden durchgeführt, welche Indikatoren wurden gesehen, welche Systeme wurden isoliert. Diese Metadokumentation ist später entscheidend, um Ursache und Wirkung zu trennen.

• Discovery Time: Wann wurde der Vorfall erkannt und durch welche Quelle?
• Containment Actions: Welche Ports/Regeln wurden geändert? Welche Hosts isoliert?
• Key Events: Erste verdächtige DNS-Queries, erste C2-Verbindung, erste Admin-Änderung
• Time Sync Notes: Zeitzonen, NTP-Status, bekannte Clock Drifts

Beweissicherung vs. Eindämmung: Die richtige Reihenfolge

Im Incident stehen Teams unter Druck: „Sofort abschalten!“ Das kann richtig sein, aber es kann auch Beweise zerstören. Eine pragmatische Reihenfolge minimiert Schaden und sichert dennoch relevante Daten:

• 1) Flüchtige Daten sichern: Sessions, NAT, VPN, ARP, aktive Verbindungen
• 2) Logs exportieren: Firewall, VPN, DNS, DHCP, Proxy/SWG, Identity
• 3) Containment durchführen: Exposure reduzieren (z. B. Adminzugänge schließen), IOC-Blocken
• 4) Konfig-Snapshots ziehen: Vor und nach Containment, um Änderungen nachvollziehbar zu haben
• 5) Verifikation und Monitoring: Prüfen, ob Angriffsaktivität stoppt, ohne Blindflug

Was Prüfer und Incident-Responder bei Evidence erwarten

Wenn ein Vorfall später intern, durch Kunden oder in Audits bewertet wird, zählt nicht nur, dass Sie gehandelt haben, sondern dass Sie nachvollziehbar gehandelt haben. Das bedeutet nicht „Bürokratie“, sondern belastbare Nachweise.

• Chain of Custody: wer hat welche Dateien/Exports erzeugt, wo liegen sie, wie sind sie geschützt?
• Integrität: Hashwerte für wichtige Artefakte (z. B. Logexports, Konfig-Snapshots)
• Scope und Zeitraum: Welche Zeitspanne ist abgedeckt? Welche Systeme sind enthalten?
• Reproduzierbarkeit: Wie wurden Daten exportiert (Kommando/GUI-Pfad), mit welchen Filtern?

Datenschutz und Rechtsrahmen: Netzforensik sauber absichern

Netzwerk-Forensik kann personenbezogene Daten enthalten (IP-Zuordnung, URLs, User-IDs). Sie sollten daher vorab Regeln definieren, wie Forensikdaten verarbeitet werden: Zugriffsbeschränkung, Zweckbindung, Aufbewahrungsfristen und sichere Speicherung. Der praktische Ansatz lautet: so viel wie nötig, so wenig wie möglich – bei gleichzeitig ausreichender Aussagekraft.

• Access Control: Nur Incident-Team und definierte Rollen dürfen Forensikdaten sehen
• Retention: Vorab festlegen, wie lange Vorfallartefakte aufbewahrt werden
• Redaktion: Bei externen Reports Daten maskieren, ohne Beweiswert zu verlieren

Typische Lücken, die Netzwerk-Forensik erschweren

• Kein zentrales Logging: Logs rotieren auf Geräten, bevor sie gesichert werden
• Keine Zeitkonsistenz: Geräte laufen mit unterschiedlichen Zeitzonen/NTP-Drift, Korrelation wird unzuverlässig
• NAT ohne Nachweis: Keine NAT-Logs/State-Exports – externe IPs sind nicht intern zuordenbar
• DHCP ohne Historie: IP-Zuordnung zu Geräten ist nach Tagen nicht mehr möglich
• Zu grobe Segmentierung: Laterale Bewegung ist schwer zu erkennen, weil „alles darf alles“
• Keine Flow-Daten: Ohne NetFlow/IPFIX bleibt nur punktuelles Logging
• Keine PCAP-Option: Wenn Protokolldetails nötig sind, fehlen Capture-Punkte oder Ringbuffer

Praktisches „First 60 Minutes“-Playbook für Netzwerk-Forensik

Die folgenden Schritte sind ein bewährtes Muster, um in der ersten Stunde eines Vorfalls die wichtigsten Netzwerkdaten zu sichern, ohne den Betrieb blind zu verändern.

• Minute 0–10: Incident-Timeline starten, Zeit/Zeitzone notieren, betroffene IPs/Hosts sammeln
• Minute 10–20: Firewall/VPN: aktive Sessions, NAT-States, Admin-Logins sichern
• Minute 20–30: DNS/DHCP: Query- und Lease-Logs exportieren, betroffene Hostnames/IPs zuordnen
• Minute 30–40: Proxy/SWG/WAF: relevante Requests, Downloads, Blockevents exportieren
• Minute 40–50: Flow-Daten (NetFlow/IPFIX) für den Zeitraum sichern, erste „Top Targets“ identifizieren
• Minute 50–60: Nur wenn nötig: gezieltes PCAP starten (Ringbuffer) und Containment-Maßnahmen planen

Checkliste: Was Sie bei einem Angriff in der Netzwerk-Forensik sichern sollten

• Flüchtige Zustände: Firewall-Sessions, NAT-States, VPN-Sessionlisten, ARP/ND-Tabellen, MAC-Tabellen.
• Zentrale Logs: Firewall (Allow/Deny/
  

  Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

  Cisco Networking • CCNA • Packet Tracer • Network Configuration

  Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

  Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

  Leistungsumfang:

  • Netzwerkdesign & Topologie-Planung

  • Router- & Switch-Konfiguration (Cisco IOS)

  • VLAN, Inter-VLAN Routing

  • OSPF, RIP, EIGRP (Grundlagen & Implementierung)

  • NAT, ACL, DHCP, DNS-Konfiguration

  • Troubleshooting & Netzwerkoptimierung

  • Packet Tracer Projektentwicklung & Dokumentation

  • CCNA Lern- & Praxisunterstützung

  Lieferumfang:

  • Konfigurationsdateien

  • Packet-Tracer-Dateien (.pkt)

  • Netzwerkdokumentation

  • Schritt-für-Schritt-Erklärungen (auf Wunsch)

  Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

  CTA:
  Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
  Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.