VPC Flow Logs/VNet Flow Logs lesen, um blockierten Traffic zu finden

VPC Flow Logs (AWS) und VNet Flow Logs (Azure) gehören zu den zuverlässigsten Datenquellen, wenn Sie blockierten Traffic in der Cloud finden möchten – vorausgesetzt, Sie wissen, wie Sie die Felder korrekt interpretieren und wie Sie aus Rohdaten eine belastbare Diagnose ableiten. Viele On-Calls scheitern nicht daran, dass Flow Logs fehlen, sondern daran, dass Teams „ACCEPT“ mit „alles ist gut“ verwechseln, „REJECT“ nicht in Kontext setzen oder den falschen Beobachtungspunkt auswerten (z. B. falsche ENI, falsches Subnetz, falsche Richtung). Hinzu kommen Unterschiede zwischen AWS und Azure: AWS liefert je nach Version und Aggregation andere Felder (Action, Log Status, Interface ID etc.), während Azure NSG Flow Logs stärker auf NSG-Regeln und Flow-States ausgerichtet sind. Dieser Artikel zeigt, wie Sie VPC Flow Logs/VNet Flow Logs strukturiert lesen, typische Fallstricke vermeiden und blockierten Traffic systematisch lokalisieren – vom ersten Symptom bis zur konkreten Regel oder Komponente, die den Drop verursacht.

Grundverständnis: Was Flow Logs leisten – und was nicht

Flow Logs sind keine Paketmitschnitte. Sie zeigen Metadaten über beobachteten Netzwerkverkehr: Quell-/Ziel-IP, Ports, Protokoll, Richtung und (je nach Plattform) eine Entscheidung wie ACCEPT/REJECT. Das ist ideal, um Blockaden, falsche Pfade oder unerwartete Kommunikation zu finden, aber nicht ideal, um Payload-Fehler, TLS-Inhalte oder Applikationsprobleme zu debuggen.

• Flow Logs sind stark bei: „Wurde der Traffic auf Netzwerkebene gesehen?“ und „Wurde er zugelassen oder verworfen?“
• Flow Logs sind begrenzt bei: HTTP-Statuscodes, TLS-Handshake-Details, Layer-7-Policies, Payload-Analyse
• Flow Logs sind perspektivisch: Sie gelten am Messpunkt (ENI/Subnetz/NSG) – nicht „im ganzen Netz“

Wichtige Implikation

Wenn Sie blockierten Traffic finden wollen, müssen Sie wissen, wo Sie messen: am Client-Interface, am Server-Interface, am Subnetz, am Load Balancer oder an einer zentralen Firewall. Oft ist der „Drop“ nicht dort, wo Sie zuerst hinschauen.

AWS VPC Flow Logs: Felder lesen, ohne sich zu täuschen

AWS VPC Flow Logs können in verschiedenen Versionen und Formaten exportiert werden (z. B. zu CloudWatch Logs, S3 oder Kinesis). Unabhängig vom Ziel ist das Prinzip gleich: Ein Log-Eintrag beschreibt einen „Flow“ über ein Zeitfenster (Aggregation), nicht zwingend ein einzelnes Paket.

Die zentralen Felder (konzeptionell)

• srcaddr / dstaddr: Quell- und Ziel-IP
• srcport / dstport: Quell- und Zielport
• protocol: z. B. TCP (6), UDP (17), ICMP (1)
• packets / bytes: Volumen im Aggregationsfenster
• start / end: Zeitfenster, für das aggregiert wurde
• action: ACCEPT oder REJECT
• log-status: OK, NODATA oder SKIPDATA (wichtig für Interpretationsfehler)
• interface-id: ENI, an der der Flow beobachtet wurde

Referenz: AWS VPC Flow Logs und Flow Log Records.

ACCEPT bedeutet nicht „End-to-End funktioniert“

Ein ACCEPT in AWS bedeutet: Auf dieser ENI wurde der Flow nicht durch die Security Group oder NACL verworfen (im Rahmen dessen, was VPC Flow Logs abbilden). Das sagt nichts darüber aus, ob die Applikation antwortet, ob die Route stimmt oder ob der Rückweg symmetrisch ist. Ein häufiger Fehler ist daher: „Ich sehe ACCEPT, also kann es kein Netzwerkproblem sein.“ In Wahrheit kann es sein, dass die Gegenseite den Rückverkehr droppt oder dass der Flow auf einem anderen Interface endet.

REJECT ist Gold – aber nur mit Kontext

Ein REJECT ist ein sehr starkes Signal: Irgendwo wurde Traffic auf Netzwerkebene verworfen. Der wichtigste nächste Schritt ist: Welcher Kontrollpunkt? In AWS können sowohl Security Groups als auch NACLs blocken. In der Praxis entscheiden Sie das über Richtung, Ports, erwartete Regeln und über parallele Logs an Client- und Server-ENI.

Log-Status: Warum „NODATA“ und „SKIPDATA“ wichtig sind

• OK: Datensatz ist vollständig für das Zeitfenster.
• NODATA: Es gab in diesem Intervall keinen Traffic (kein Beweis für Block, sondern Abwesenheit).
• SKIPDATA: Es gab Daten, aber sie wurden verworfen/geskippt (z. B. Limits/Interne Gründe) – gefährlich, weil Sie dann „blinde Flecken“ haben.

Wenn Sie ein Problem debuggen und sehen SKIPDATA oder große Lücken, müssen Sie diese Beobachtung explizit einplanen: Flow Logs sind dann nicht vollständig und können den Drop übersehen.

Azure VNet/NSG Flow Logs: Struktur verstehen und blockierte Flows identifizieren

In Azure werden Flow Logs häufig im Kontext von Network Watcher und NSG Flow Logs genutzt. Der Fokus liegt stärker auf NSG-Entscheidungen und auf der Zuordnung zu Regeln. Die Logs werden typischerweise in ein Storage Account geschrieben und können mit Traffic Analytics oder SIEM ausgewertet werden.

Referenz: Azure NSG Flow Logs Überblick und Azure Traffic Analytics.

Was Azure-Flow-Logs besonders nützlich macht

• NSG-Regelkontext: Sie können häufig nachvollziehen, welche Regel den Flow erlaubt oder blockt.
• Flow States: Azure beschreibt Flows über Zustände/Sequenzen (abhängig vom Format/Version).
• Gute Integration: Traffic Analytics kann Muster und Top-Talker sichtbar machen.

Typische Falle in Azure

Viele Azure-Probleme sind nicht „NSG blockt“, sondern Routing/UDR oder eine Azure Firewall/Appliance im Pfad. Wenn NSG Flow Logs ACCEPT zeigen, kann Traffic trotzdem später verworfen werden. Wie in AWS gilt: Der Messpunkt entscheidet.

Die wichtigste Methode: Von der Hypothese zum Filter (5-Tuple + Zeitfenster)

Blockierten Traffic finden Sie am schnellsten, wenn Sie konsequent mit dem 5-Tuple arbeiten: Quell-IP, Ziel-IP, Quellport, Zielport, Protokoll – plus ein klarer Zeitbereich rund um das Ereignis. Ohne diese Disziplin versinken Teams in Millionen Logzeilen.

Minimaldaten, die Sie vor dem Log-Query sammeln sollten

• Zeitfenster: Start/Ende des Problems (mit Puffer, z. B. ±5–10 Minuten)
• Quelle: Instanz/Pod/VM, Subnetz, private IP
• Ziel: Service-IP/LB-IP/Endpoint, Port (z. B. 443/5432)
• Richtung: Client→Server oder Server→Client (beides prüfen)
• DNS-Auflösung: Wenn Hostname genutzt wurde, welche IP war es wirklich?

Blockaden richtig lokalisieren: Client-Seite vs. Server-Seite vs. Subnetz

Ein häufiger Fehler ist, nur auf einer Seite zu suchen. Für einen belastbaren Befund benötigen Sie idealerweise Logs von beiden Seiten. Das Muster ist immer gleich: Sie prüfen, ob der Flow am Client rausgeht, ob er am Server ankommt und ob der Rückverkehr denselben Weg zurückfindet.

Diagnosematrix (praktisch)

• Client sieht REJECT: sehr oft Egress-SG oder Client-Subnetz-NACL/NSG
• Client sieht ACCEPT, Server sieht nichts: Routing/Next Hop/Peering/TGW/Firewall im Pfad oder falsches Ziel (DNS)
• Server sieht REJECT: sehr oft Ingress-SG/NSG oder Server-Subnetz-NACL
• Beide sehen ACCEPT, aber App failt: Applikation/Listener/Host-Firewall/TLS/Policy
• Hinweg ACCEPT, Rückweg fehlt: asymmetrisches Routing, NACL-Ephemeral-Ports, NAT/Stateful Firewall

Ephemeral Ports: Der Grund, warum „Port 443 ist offen“ nicht reicht

Gerade bei NACLs/NSGs und stateless Filtern ist der Rückverkehr über Ephemeral Ports entscheidend. Wenn Ephemeral-Range nicht passend erlaubt ist, entstehen Timeouts, obwohl Zielport offen ist. Viele Teams sehen dann nur „SYN raus“ und interpretieren es als SG-Problem.

Wie Sie das in Flow Logs erkennen

• Sie sehen ausgehende Flows mit dstport = 443 (oder Service-Port) als ACCEPT.
• Sie sehen fehlenden oder REJECTed Rückverkehr, bei dem dstport = Client-Ephemeral-Port ist.
• Bei stateless Filtern fehlen passende Allow-Regeln für den Ephemeral-Bereich in der Rückrichtung.

Asymmetrisches Routing mit Flow Logs aufdecken

Asymmetrisches Routing ist ein Top-Use-Case für Flow Logs, weil Sie Pfade indirekt über Beobachtungspunkte und Interfaces nachweisen können. Das Ziel: Den Rückverkehr dort zu finden, wo er nicht sein sollte – oder zu zeigen, dass er gar nicht am erwarteten Interface ankommt.

Praktisches Vorgehen

• Identifizieren Sie die ENIs/Interfaces der beteiligten Komponenten (Client, Server, NAT, Firewall, LB).
• Filtern Sie Flows mit identischem 5-Tuple (oder korrespondierenden Ports) im gleichen Zeitfenster.
• Prüfen Sie, ob Hin- und Rückrichtung am selben Kontrollpunkt sichtbar sind.
• Wenn der Rückverkehr an einer anderen ENI auftaucht: Pfad ist asymmetrisch oder wurde geroutet/gesnatet.

Ein einfacher KPI zur Plausibilisierung

Wenn Sie SYNs und korrespondierende Antworten zählen können (z. B. über Flow-Volumen und bekannte Muster), lässt sich eine grobe Erfolgsrate ableiten. In vielen Umgebungen ist die TLS-Handshake-Erfolgsrate ein indirekter Proxy für „Rückweg funktioniert“.

$\mathrm{Erfolgsrate}=\frac{\mathrm{ErfolgreicheVerbindungen}}{\mathrm{Verbindungsversuche}}$

Wichtige Fallstricke: Aggregation, Sampling und „blinde Flecken“

Flow Logs sind aggregiert. Das bedeutet: Ein Eintrag kann viele Pakete/Bytes enthalten. Zudem gibt es je nach Plattform Limits und Situationen, in denen Logs nicht vollständig sind. Wer blockierten Traffic finden will, muss diese Grenzen aktiv berücksichtigen.

• Aggregation: Ein Drop kann in einem Zeitfenster „untergehen“, wenn nur ein Teil des Flows verworfen wird.
• Time Skew: Uhren/Zeitzonen/Log-Ingest können die Reihenfolge verzerren.
• SKIPDATA/Limits: Logs können unvollständig sein; fehlende Logs sind kein Beweis für „kein Traffic“.
• Falscher Messpunkt: Flow Logs an ENI A helfen nicht, wenn der Drop an Firewall B passiert.
• Verschleierung durch NAT: Source-IP/Port können sich ändern; Sie müssen NAT-Mappings berücksichtigen.

Blockierten Traffic in der Praxis finden: Muster, die Sie wiedererkennen werden

Statt jedes Mal bei null zu starten, hilft es, typische Muster zu kennen. Diese Muster tauchen in AWS und Azure sehr ähnlich auf, auch wenn die Feldnamen variieren.

Muster: „Server-Port offen, aber Timeout“

• Client→Server: ACCEPT auf dstport (z. B. 443)
• Server sieht nichts oder REJECT
• Ursache oft: Routing/Peering/TGW/UDR oder falsches Ziel (DNS)

Muster: „Nur manche Clients betroffen“

• Betroffene Clients lösen Hostname auf andere IPs auf oder nutzen anderen Resolver
• Oder: nur ein Subnetz hat restriktive NACL/NSG-Regeln
• Flow Logs zeigen unterschiedliche dstaddr oder unterschiedliche REJECT-Points

Muster: „Intermittierend unter Last“

• Mehr Drops/Timeouts in Peaks
• Verdacht: NAT/SNAT-Port-Exhaustion, State-Table, Firewall-Kapazität, Rate Limits
• Flow Logs zeigen erhöhte REJECTs oder fehlenden Rückverkehr in Peaks

Operational Best Practices: Flow Logs so aufsetzen, dass sie im Incident helfen

Die beste Analyse hilft wenig, wenn Logs nicht vorhanden oder nicht durchsuchbar sind. Mit ein paar Standards erhöhen Sie die Debug-Fähigkeit massiv.

• Coverage: Logging für kritische Subnetze/Interfaces standardisieren (Prod mindestens).
• Retention: ausreichend lange Aufbewahrung für Postmortems und Security-Analysen.
• Zentrale Ablage: CloudWatch/S3/Log Analytics/SIEM so strukturieren, dass Teams schnell filtern können.
• Metadaten: Tags (Service, Env, Owner) für Ressourcen, damit ENIs/Subnetze schnell zugeordnet werden.
• Dashboards: Top REJECTs, Top dstports, Top srcaddr, Trends pro AZ/Subnetz.
• Runbooks: Standard-Queries und Interpretationshilfen dokumentieren.

Outbound-Links zu relevanten Informationsquellen

• AWS VPC Flow Logs: Überblick
• AWS: Flow Log Records und Felder
• AWS: Security Groups (stateful)
• AWS: Network ACLs (stateless)
• Azure: NSG Flow Logs Überblick
• Azure: Traffic Analytics
• Azure: Network Security Groups
• GCP: VPC Flow Logs (als ergänzende Referenz)

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.