Flow Logs: Accept/Reject richtig interpretieren

Wer mit Netzwerk-Telemetrie arbeitet, stolpert früher oder später über eine scheinbar einfache Frage: Was bedeutet in Flow Logs eigentlich „ACCEPT“ und was „REJECT“ – und wie lässt sich das in der Praxis korrekt deuten? Genau hier passieren die meisten Fehlinterpretationen, weil viele davon ausgehen, dass „ACCEPT“ automatisch „Verbindung erfolgreich“ heißt und „REJECT“ automatisch „Angriff“ oder „Fehlkonfiguration“. In Wirklichkeit beschreiben Accept/Reject in Flow Logs in erster Linie die Entscheidung einer Sicherheits- oder Filterinstanz (z. B. Security Group oder Network ACL) für ein bestimmtes Paket- oder Flow-Ereignis – nicht den gesamten End-to-End-Erfolg einer Anwendung. Dieser Artikel erklärt, wie Sie „Flow Logs: Accept/Reject richtig interpretieren“, welche Unterschiede es zwischen Cloud-Anbietern gibt, welche Felder Sie zusätzlich betrachten müssen und wie Sie typische Szenarien (Port-Scans, Timeout-Probleme, Routing-Fehler, zu strikte Regeln) sauber auseinanderhalten. Ziel ist, dass Sie Accept/Reject nicht nur „lesen“, sondern zuverlässig für Troubleshooting, Security-Analysen und Compliance nutzen können.

Was Flow Logs überhaupt messen (und was nicht)

Flow Logs sind strukturierte Netzwerkprotokolle, die Metadaten über Netzwerkverkehr erfassen – typischerweise 5-Tupel (Quelle, Ziel, Quellport, Zielport, Protokoll) plus Zeitfenster, Zähler, Richtung und eine Entscheidung/Disposition. Wichtig: Flow Logs sind keine Paketmitschnitte und enthalten in der Regel keine Payload. Sie sind daher ideal für Trendanalysen, Sicherheits-Forensik auf Metadatenebene, Baselines und schnelles Troubleshooting, aber nur eingeschränkt geeignet, um „warum“ eine Anwendung fehlschlägt, vollständig zu erklären.

Der häufigste Denkfehler: „ACCEPT“ wird als „die Verbindung hat funktioniert“ interpretiert. Tatsächlich kann Verkehr akzeptiert werden und trotzdem im nächsten Schritt scheitern – etwa durch fehlendes Routing, eine nicht laufende Anwendung, ein Downstream-Problem oder ein Timeout. Umgekehrt kann „REJECT“ auch völlig legitim sein (z. B. weil ein Server harte Eingangsfilter hat) und sogar erwünscht, wenn Sie Angriffsflächen reduzieren.

Accept/Reject: Bedeutung nach Anbieter und Log-Typ

Die genaue Semantik hängt vom Cloud-Anbieter und vom jeweiligen Logging-Produkt ab. Die Grundidee bleibt: Accept/Reject (oder ein äquivalenter Zustand) beschreibt, ob der Datenverkehr an einer bestimmten Kontrollstelle erlaubt oder verworfen wurde. Für die korrekte Interpretation müssen Sie immer wissen: Wo wurde geloggt (Subnetz, ENI/Interface, VM-Instanz, Firewall, NSG), welche Regeln greifen, und welcher Log-Typ es ist.

• AWS VPC Flow Logs: Feld „action“ ist typischerweise „ACCEPT“ oder „REJECT“ und spiegelt die Entscheidung von Security Groups und/oder Network ACLs wider (abhängig von Kontext und Datenpfad). Referenz: AWS VPC Flow Logs Dokumentation.
• Azure NSG Flow Logs: NSG-Flow-Logs enthalten Einträge, die erlaubten oder verweigerten Verkehr abbilden; wichtig ist die Einordnung über NSG-Regeln und ggf. Traffic Analytics. Referenz: Azure NSG Flow Logs Übersicht.
• Google Cloud VPC Flow Logs: Statt „ACCEPT/REJECT“ gibt es eine Disposition wie „ACCEPTED“ oder „DROPPED“. Referenz: Google Cloud VPC Flow Logs.

Warum „ACCEPT“ nicht gleich „Erfolg“ ist

„ACCEPT“ bedeutet in den meisten Umgebungen: Der Verkehr wurde von der betrachteten Sicherheits-/Filterebene nicht blockiert. Damit ist aber nur gesagt, dass das Paket (oder der Flow im Zeitfenster) die Regelprüfung bestanden hat. Ob am Ziel tatsächlich ein Dienst lauscht, ob die Route stimmt oder ob der Rückweg funktioniert, ist damit nicht garantiert.

Typische Ursachen für „ACCEPT“, aber trotzdem Timeout

• Service nicht erreichbar: Zielport ist offen (Regeln erlauben), aber der Dienst läuft nicht oder lauscht auf einer anderen Schnittstelle.
• Routing/Next Hop Problem: Security erlaubt, aber Route Table führt ins Leere, ins falsche Subnetz oder über ein nicht erreichbares Gateway.
• Asymmetrisches Routing: Hinweg akzeptiert, Rückweg geht über eine andere Kontrollstelle und wird dort verworfen (oder kommt nie zurück).
• Stateful vs. stateless Missverständnis: Bei stateful Firewalls/Security Groups ist Rückverkehr oft implizit erlaubt; bei stateless Listen (z. B. NACLs) müssen Rückregeln explizit passen.
• Ephemeral Ports: Rückverkehr nutzt dynamische Quellports. Wenn Rückregeln zu eng sind, sehen Sie u. U. „ACCEPT“ in eine Richtung und „REJECT“ in die andere.

Was „REJECT“ wirklich bedeutet (und wann es harmlos ist)

„REJECT“ heißt im Flow-Log-Kontext meist: Der Verkehr wurde an der erfassten Kontrollstelle verworfen, weil er nicht zu den erlaubenden Regeln passte oder explizit blockiert wurde. Das ist nicht automatisch ein Sicherheitsvorfall. Im Gegenteil: In gut gehärteten Umgebungen sind viele REJECTs normal – etwa wenn nur definierte Verwaltungsnetze auf SSH zugreifen dürfen oder wenn interne Systeme grundsätzlich keine eingehenden Verbindungen akzeptieren.

Legitime REJECT-Muster

• Port-Scans von außen: Viele Zielports, viele Quell-IP-Adressen, kurze Zeitfenster, hoher Anteil REJECT – häufig Internet-Rauschen.
• Interne Fehlkonfigurationen: Ein Service versucht, auf einen falschen Port zuzugreifen (z. B. 5432 statt 5433) und wird regelkonform blockiert.
• Zero-Trust Segmentierung: Ost-West-Verkehr ist standardmäßig dicht, nur Whitelist-Flows sind erlaubt.

Die Felder, die Sie für Accept/Reject immer mitlesen sollten

Accept/Reject ist nur ein Signal. Für eine belastbare Interpretation brauchen Sie Kontextfelder. Je nach Anbieter heißen sie unterschiedlich, aber die Logik ist vergleichbar: Wer spricht mit wem, wann, wie oft, in welche Richtung – und wie „vollständig“ war der Flow.

• Zeitfenster / Aggregation: Flow Logs werden oft in Intervallen aggregiert (z. B. 1–10 Minuten). Ein Eintrag kann mehrere Pakete zusammenfassen.
• Bytes/Packets: Hohe Paketzahlen bei „REJECT“ können auf Scans oder fehlerhafte Retries hinweisen; „ACCEPT“ mit sehr wenigen Bytes kann ein SYN ohne Antwort sein.
• Direction (Ingress/Egress): Entscheidend, um Rückweg-Probleme zu erkennen.
• Interface/Subnet/Resource-ID: Zeigt, an welcher Stelle geloggt wurde. Das bestimmt, welche Regelwerke überhaupt relevant sind.
• TCP-Flags / Disposition-Details (falls vorhanden): Einige Logformate oder ergänzende Produkte liefern zusätzliche Signale.

Praxis: Häufige Interpretationsfehler und wie Sie sie vermeiden

Fehler 1: „REJECT“ = „Security Incident“

Ein REJECT ist zunächst nur ein abgewiesener Flow. Prüfen Sie zuerst, ob die Quelle überhaupt legitim ist (z. B. internes Subnetz, Monitoring-System, Bastion Host). Dann schauen Sie auf Muster: Ein einzelner REJECT auf einen Admin-Port kann ein Tippfehler sein; tausende REJECTs über viele Ports von extern ist eher Scan-Rauschen. Erst wenn Quelle, Ziel und Muster unplausibel sind, wird es sicherheitsrelevant.

Fehler 2: „ACCEPT“ = „Dienst erreichbar“

Wenn Nutzer „Timeout“ melden, aber Flow Logs „ACCEPT“ zeigen, ist das kein Widerspruch. Das Log sagt nur: die Netzwerkregeln haben nicht blockiert. Danach kommen OS-Firewall, Service-Health, DNS-Auflösung, Load-Balancer-Zustand, Routing und Rückweg. Für sauberes Troubleshooting kombinieren Sie Flow Logs mit Metriken/Health Checks und ggf. Firewall-Logs auf Hostebene.

Fehler 3: Ephemeral Ports werden ignoriert

Gerade bei stateless Filtern ist es essenziell, Rückverkehr korrekt abzubilden. Ein Client verbindet sich auf Zielport 443, nutzt aber lokal einen zufälligen Quellport. Antwortpakete gehen dann an diesen Ephemeral Port zurück. Wenn Ihre Rückregeln nur „443“ erlauben, sehen Sie möglicherweise „REJECT“ auf dem Rückweg. Das wirkt wie „Server blockiert“, ist aber schlicht eine zu enge Rückregel.

Konkrete Szenarien richtig lesen

Szenario: SSH-Zugriff klappt nicht, Flow Logs zeigen REJECT

• Was es meist bedeutet: Der eingehende TCP/22-Flow wird an einer Kontrollstelle blockiert (z. B. NACL/NSG/Firewall-Regel).
• So prüfen Sie: Quelle-IP (stimmt sie?), Ziel (richtige Instanz/Subnetz?), Richtung (Ingress?), Regelreihenfolge (First Match), und ob es eine explizite Deny-Regel gibt.
• Typischer Fix: Whitelist der Admin-IP oder des VPN-Netzes; zusätzlich Rückpfad-Regeln bei stateless Filtern.

Szenario: API-Calls timeouten, Flow Logs zeigen ACCEPT, aber wenig Bytes

• Was es oft bedeutet: SYN kommt durch, aber der Server antwortet nicht (Service down) oder Antwort kommt nicht zurück (Rückweg/Asymmetrie).
• So prüfen Sie: Vergleich von Ingress- und Egress-Logs, Byte-/Packet-Zähler, sowie Logs am Load Balancer oder Host-Firewall. Prüfen Sie außerdem DNS und ob das Ziel wirklich die erwartete IP ist.

Szenario: Viele REJECTs auf zufällige Ports aus dem Internet

• Was es meist ist: Internet-Scanning. Das ist normaler Hintergrundlärm.
• So reagieren Sie sinnvoll: Baseline erstellen (typische Volumina), Alarmierung auf Anomalien (starker Spike, neue Quellnetze, Fokus auf sensible Ports), und ggf. WAF/Edge-Filter oder Rate-Limits einsetzen.

Messbar machen: Reject-Rate und Trendanalyse

Für Betrieb und Security ist nicht nur der einzelne Logeintrag relevant, sondern das Verhältnis und die Veränderung über Zeit. Eine einfache Kennzahl ist die Reject-Rate: Anteil verworfener Flows an allen beobachteten Flows in einem Zeitfenster. Das kann helfen, Deployments zu bewerten (z. B. plötzlich mehr REJECT nach Regeländerung) oder Angriffsphasen zu erkennen (z. B. Scan-Welle).

$\mathrm{RejectRate}=\frac{\mathrm{REJECT} \mathrm{Flows}}{\mathrm{ACCEPT}+\mathrm{REJECT} \mathrm{Flows}}$

Interpretieren Sie diese Kennzahl immer im Kontext: Ein Internet-exponiertes Subnetz hat naturgemäß mehr REJECT als ein internes Backend. Entscheidend sind Abweichungen von der eigenen Baseline und eine Aufschlüsselung nach Zielport, Quellnetz, Richtung und betroffener Ressource.

Best Practices für verlässliche Interpretation

• Logging-Punkt dokumentieren: Halten Sie fest, auf welcher Ebene geloggt wird (Subnetz, Interface, VM, Firewall). Ohne das ist Accept/Reject oft irreführend.
• Regelwerke versionieren und auditieren: Bei Änderungen an SG/NACL/NSG sollten Sie nachvollziehen können, wann welche Regel aktiv war.
• Immer Richtung + Rückweg prüfen: Viele Fehler sind Rückpfad-Probleme. Einseitige Betrachtung führt zu falschen Schlüssen.
• Ephemeral-Port-Bereiche berücksichtigen: Besonders bei stateless Filtern müssen Rückregeln sauber abgedeckt sein.
• Flow Logs mit weiteren Datenquellen kombinieren: Health Checks, Load-Balancer-Logs, Host-Firewall-Logs und DNS-Logs ergänzen die Sicht. Für AWS kann auch die übergreifende Netzwerkanalyse helfen, z. B. mit Reachability Analyzer. Referenz: AWS Reachability Analyzer.
• Baseline statt Bauchgefühl: Legen Sie Normalwerte fest (z. B. Reject-Rate pro Subnetz/Service). Alarmieren Sie auf Abweichungen, nicht auf jeden REJECT.

Quick-Checkliste: Accept/Reject in 60 Sekunden einordnen

• 1) Wo wurde geloggt? (Ressource/Subnetz/Interface) → bestimmt relevante Regeln.
• 2) Welche Richtung? Ingress/Egress → Rückweg-Probleme erkennen.
• 3) Bytes/Packets plausibel? Sehr wenig bei ACCEPT kann „nur Anbahnung“ bedeuten.
• 4) Muster oder Einzelfall? Spike, viele Ports, viele Quellen → Scan; einzelner Port/Quelle → eher Konfig oder legitimer Zugriff.
• 5) Passt es zur Baseline? Wenn nein: nach Änderungen an Regeln, Routing, Deployments suchen.

Outbound-Quellen für tieferes Verständnis

• AWS VPC Flow Logs: Felder, Formate, Einschränkungen
• Azure NSG Flow Logs: Grundlagen und Auswertung
• Google Cloud VPC Flow Logs: Disposition und Konfiguration
• AWS Reachability Analyzer: Pfad- und Erreichbarkeitsprüfung

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.