NetFlow/IPFIX zur Attack-Detection: Die nützlichsten Felder

NetFlow/IPFIX zur Attack-Detection ist für viele Security- und NOC-Teams der schnellste Weg, aus „Traffic ist komisch“ belastbare Indikatoren zu machen – ohne direkt in PCAPs zu versinken. Flow-Daten liefern keine Payload, aber sie liefern Struktur: Wer spricht mit wem, wie lange, wie viel, über welche Ports und in welche Richtung. Genau diese Metadaten reichen in sehr vielen Fällen, um DDoS-Muster, Scans, Brute-Force-Versuche, Datenabflüsse oder Command-and-Control-Anomalien früh zu erkennen. Der entscheidende Hebel ist dabei nicht nur „NetFlow aktivieren“, sondern die richtigen Felder zu exportieren und sie so zu korrelieren, dass echte Angriffe sichtbar werden, während normales Betriebsrauschen klein bleibt. Dieser Beitrag zeigt, welche NetFlow-/IPFIX-Information Elements in der Praxis am meisten Nutzen bringen, wie Sie daraus robuste Detection-Signale bauen und welche typischen Fehlinterpretationen Sie vermeiden sollten – von Directional Metrics über TCP-Flags bis zu NAT- und Interface-Kontext.

NetFlow vs. IPFIX: Was für Detection wirklich zählt

NetFlow (v5/v9) und IPFIX sind eng verwandt: NetFlow v9 ist template-basiert, IPFIX ist der IETF-Standard, der das Konzept generalisiert und formalisiert. Für Attack-Detection ist weniger die „Marke“ entscheidend als die Frage, ob Ihr Export templates, enterprise fields und ausreichend Kontext liefert. In modernen Umgebungen ist IPFIX oft die bessere Wahl, weil es standardisierte Information Elements, flexiblere Templates und bessere Erweiterbarkeit bietet. NetFlow v5 ist zwar verbreitet, aber limitiert (z. B. weniger Felder, keine Templates).

• Template-basierter Export (NetFlow v9/IPFIX) erlaubt mehr und bessere Felder.
• Bidirektionale Sicht (Ingress/Egress, Direction, Reverse-Fields) reduziert False Positives.
• Exporter-/Interface-Kontext ist für Incident-Triage oft wichtiger als exotische Felder.

Wenn Sie eine technische Referenz für IPFIX suchen, sind die IETF-Dokumente ein guter Startpunkt, z. B. IPFIX Protocol Specification (RFC 7011) und die dazugehörige Informationsmodell-Beschreibung IPFIX Information Model (RFC 7012).

Grundfeldgruppe: Das „5-Tuple“ plus Zeit – unverzichtbar, aber nicht ausreichend

Jede sinnvolle Flow-Detection beginnt mit dem 5-Tuple und verlässlichen Zeitstempeln. Ohne diese Basis können Sie weder Sessions clustern noch Häufigkeiten robust vergleichen.

• sourceIPv4Address/sourceIPv6Address und destinationIPv4Address/destinationIPv6Address
• sourceTransportPort und destinationTransportPort
• protocolIdentifier (TCP/UDP/ICMP etc.)
• flowStartMilliseconds und flowEndMilliseconds (oder Sekunden-Varianten)

Für Detection reicht das 5-Tuple allein jedoch selten: Scans, DDoS oder Exfiltration werden erst klar, wenn Volumen, Richtung, Flags und Kontext hinzukommen.

Volumen- und Rate-Felder: Bytes, Pakete und „Wie schnell“

Für nahezu jede Attack-Klasse brauchen Sie Zählwerte. Achten Sie darauf, ob Ihr Exporter Bytes/Pakete pro Flow, pro Richtung oder aggregiert liefert. Für Low-Noise-Detection ist eine klare Richtungssicht entscheidend.

• octetDeltaCount (Bytes im Flow) und packetDeltaCount (Pakete im Flow)
• octetTotalCount/packetTotalCount (je nach Exporter/Template)
• flowDurationMilliseconds (oder über Start/End berechenbar)

Praktische Kennzahlen aus Flow-Feldern ableiten

Viele SIEM/NDR-Regeln arbeiten nicht mit absoluten Bytes, sondern mit Raten. Eine einfache, robuste Rate ist „Packets per Second“ (pps) oder „Bytes per Second“ (bps) pro Key (z. B. Ziel-IP, Ziel-Port, Tenant). Das lässt sich aus Standardfeldern berechnen:

$\mathrm{pps}=\frac{\mathrm{packetDeltaCount}}{\frac{\mathrm{flowEndMilliseconds}-\mathrm{flowStartMilliseconds}}{1000}}$

Für DDoS-Triage ist pps oft aussagekräftiger als Bytes, weil viele L3/L4-Angriffe paketgetrieben sind (z. B. SYN-Flood, UDP-Flood).

Richtungs- und Interface-Kontext: Ingress/Egress macht Angriffe „beweisbar“

Eine der häufigsten Ursachen für Fehlalarme ist fehlende Klarheit über die Richtung. Ein hoher Traffic zu einem Server kann normal sein (z. B. Content Delivery), aber ein hoher Traffic vom Server nach extern kann Exfiltration bedeuten. Deshalb sind Directional Fields und Interface-IDs so wertvoll.

• ingressInterface und egressInterface (oder SNMP ifIndex-Varianten)
• flowDirection (falls unterstützt)
• sourceMacAddress/destinationMacAddress (in Campus/LAN-Szenarien hilfreich)
• bgpSourceAsNumber/bgpDestinationAsNumber (wenn BGP-Kontext exportiert wird)

Mit Interface-Kontext können Sie z. B. unterscheiden, ob ein Scan aus dem Internet kommt (Ingress am WAN) oder intern startet (Ingress im LAN/Server-VLAN). Das reduziert Triaging-Zeit erheblich.

TCP-spezifische Felder: Flags, Retransmission-Signale und Session-Anomalien

Für viele Angriffe (SYN-Flood, Port Scans, Brute Force, C2-Beacons) sind TCP-Flags extrem hilfreich. Nicht jeder Exporter liefert alle Bits gleich, aber schon ein Flags-Feld macht einen großen Unterschied.

• tcpControlBits (SYN/ACK/RST/FIN etc.)
• initialTCPFlags und unionTCPFlags (wenn verfügbar)
• flowEndReason (z. B. Timeout vs. TCP-FIN/RST, exporterabhängig)

Typische Detection-Muster mit TCP-Flags

• SYN-Flood: sehr viele Flows mit SYN, wenig ACK, kurze Dauer, hoher pps auf Ziel-IP/Port.
• Port Scan (TCP): viele Ziele/Ports mit kurzen Flows, häufig RST oder fehlender Handshake.
• Brute Force: viele kurze Verbindungen zu Auth-Ports (SSH/RDP/HTTPS-Login), repetitive Source-Key.

ICMP- und UDP-Kontext: Amplification und „Noise“ sauber trennen

UDP und ICMP sind für volumetrische Angriffe und Reflection/Amplification besonders relevant. Hier helfen Protokollfelder, Ports und (wenn möglich) ICMP-Typ/Code.

• icmpTypeCodeIPv4 / icmpTypeCodeIPv6 (oder getrennte Type/Code-IEs)
• destinationTransportPort (für UDP-Reflection: 53/123/1900/389/11211 etc.)
• packetDeltaCount und octetDeltaCount (pps/bps-Profile)

Wichtig: Viele Netze haben normales ICMP-Rauschen (PMTUD, Unreachable, Monitoring). Für „echte“ Incidents brauchen Sie Korrelation: z. B. ICMP-Spike + Latenzanstieg + Drops am Edge.

NAT- und User-Kontext: Der Unterschied zwischen „eine IP“ und „ein Täter“

In Enterprise- und Cloud-Umgebungen ist NAT allgegenwärtig. Ohne NAT-Felder sehen Sie oft nur eine Gateway-IP, hinter der hunderte Hosts stecken. Für Attack-Detection (und forensische Zuordnung) sind NAT-Informationen daher Gold wert, sofern Ihr Exporter sie liefern kann.

• postNATSourceIPv4Address / postNATDestinationIPv4Address (oder vendor-spezifische Varianten)
• postNAPTSourceTransportPort / postNAPTDestinationTransportPort
• natEvent oder NAT-Logging-Korrelation (je nach Plattform)

Wenn NAT-Felder nicht verfügbar sind, kompensieren Sie mit Standort-/Interface-Kontext und einem konsequenten Logging-Join (Firewall/NAT-Logs + Flow-Daten).

Exporter-Identität und Sampling: Ohne diese Felder sind Thresholds gefährlich

Flow-Daten sind nicht immer „vollständig“. Viele Geräte sampeln (1:1000 oder adaptiv), und einige Systeme aggregieren unterschiedlich. Für belastbare Detection müssen Sie wissen: von welchem Exporter kommt ein Flow, und ob Sampling aktiv ist.

• exporterIPv4Address/exporterIPv6Address oder Observation Domain ID
• samplingInterval und samplingAlgorithm (falls exportiert)
• observationPointId / observationDomainId

Ohne Sampling-Kontext können Sie pps/bps nur relativ vergleichen, nicht absolut. Viele Teams lösen das, indem sie Schwellenwerte pro Exporter-Domäne definieren und auf Trend/Anomalie statt absolute Zahlen setzen.

Application- und Service-Signale: Wenn L7 fehlt, helfen „L4-Proxy-Indikatoren“

Flow-Daten sind L3/L4-lastig, aber Sie können trotzdem sehr brauchbare Service-Signale ableiten: Ziel-Port, Flow-Dauer, Byte-Ratio, Verbindungsfrequenz und (wenn verfügbar) TLS-/HTTP-Metadaten aus erweiterten Exportern.

• destinationTransportPort als Service-Proxy (443/80/22/3389/445 etc.)
• flowDurationMilliseconds (Beacons sind oft kurz, regelmäßig, ähnlich groß)
• bytes-to-packets Ratio als Hinweis auf Payload-Charakter (kleine Pakete vs. große Transfers)
• enterprise-specific Information Elements (z. B. TLS SNI, JA3-ähnliche Fingerprints – vendorabhängig)

Wenn Sie solche erweiterten Felder nutzen, dokumentieren Sie sauber, welche Geräte welche Templates liefern, damit Regeln nicht „still“ ausfallen.

Die nützlichsten Felder je Angriffsklasse (praxisnahe Kurzmatrix)

In der täglichen Arbeit hilft eine pragmatische Priorisierung: Welche Felder bringen für welche Angriffsklasse den größten Mehrwert?

DDoS L3/L4 (SYN/UDP/ICMP Flood, Reflection)

• octetDeltaCount, packetDeltaCount, flowStart/End, ingress/egressInterface
• protocolIdentifier, destinationTransportPort, tcpControlBits (bei SYN-Flood)
• icmpTypeCode (bei ICMP-Flood), exporter/observationDomain + sampling

Port Scanning (TCP/UDP)

• sourceIP, destinationIP, destinationTransportPort, protocolIdentifier
• tcpControlBits (SYN ohne ACK, RST), sehr kurze flowDuration
• Unique-Count pro Source: viele Ziele/Ports in kurzer Zeit (Korrelation im SIEM/NDR)

Brute Force (SSH/RDP/VPN/Web-Login)

• sourceIP/Client-ID (wenn vorhanden), destinationIP, destinationPort
• Viele kurze Flows, wiederholte Versuche, zeitliche Cluster
• Ingress-Interface (Internet vs. intern), NAT-Felder (wenn relevant)

Data Exfiltration / ungewöhnliche Transfers

• octetDeltaCount (Outbound), flowDirection/egressInterface, destinationASN/Geo (wenn verfügbar)
• Lang laufende Flows mit hohem Byte-Volumen oder viele kleine Uploads (je nach TTP)
• Baseline pro Host/Tenant: „plötzlicher“ Outbound-Anstieg

C2 Beaconing / Low-and-Slow

• Regelmäßigkeit: flowStart/End-Zeitmuster, ähnliche Größen (Bytes/Pakete)
• destinationIP/ASN, destinationPort (häufig 443/53/8080), kurze Dauer
• Interface- und Tenant-Kontext zur Einordnung „normaler“ Telemetrie

Qualität vor Quantität: Welche Felder Sie priorisieren sollten

In vielen Umgebungen ist Export-Bandbreite begrenzt. Wenn Sie nicht alles exportieren können, priorisieren Sie Felder, die sowohl Detection als auch Triage unterstützen. Eine typische „Minimum plus“-Liste sieht so aus:

• 5-Tuple + flowStart/flowEnd
• octetDeltaCount + packetDeltaCount
• ingressInterface + egressInterface (oder mindestens ingress)
• tcpControlBits (wenn TCP relevant ist)
• exporter/observationDomain + samplingInterval (für korrekte Interpretation)
• Optional: ICMP Type/Code, MAC-Adressen (LAN), NAT-Felder (bei starker NAT-Nutzung)

Typische Fehlinterpretationen, die zu False Positives führen

Flow-Detection ist mächtig, aber anfällig für Missverständnisse. Diese Stolperfallen sollten Sie systematisch abfangen:

• Sampling ignoriert: Schwellenwerte werden „zu niedrig“ gesetzt und springen zwischen Exportern.
• Richtung unklar: Exfiltration und Download werden verwechselt, weil Egress/Ingress fehlt.
• Normaler Burst wird als Angriff gelesen: Deployments, Backups, Batch-Jobs erzeugen legitime Peaks.
• NAT-Effekt: Viele Clients hinter einer IP wirken wie ein Scan/Brute Force.
• Top-Talker ohne Kontext: Hohe Bytes sind nicht automatisch böse (CDN, Updates, Videokonferenzen).

Die beste Gegenmaßnahme ist ein Baseline-Ansatz: pro Exporter-Domäne, pro Tenant, pro kritischem Service. Dann arbeiten Sie mit Abweichungen statt mit starren Grenzwerten.

Detection „operierbar“ machen: Korrelations-Keys, die in der Praxis funktionieren

Damit Ihr SIEM/NDR nicht überläuft, sollten Sie Flow-Detections an wenige, stabile Keys binden. Diese Keys sind in der Praxis bewährt:

• Ziel-IP + Ziel-Port (DDoS/Service-Impact)
• Quell-IP (Scan/Brute Force, aber NAT beachten)
• Tenant/Zone + Ziel-Service (Multi-Tenant-Fairness, schnellere Triage)
• Exporter/Interface (Edge vs. intern; Routing-/Segment-Kontext)
• ASN/Geo-Klasse (bei Internet-Traffic, sofern verfügbar)

Outbound-Links für Standards und Feldreferenzen

• IPFIX Protocol Specification (RFC 7011)
• IPFIX Information Model (RFC 7012)
• IANA IPFIX Information Elements Registry (Feldliste und IDs)
• Cisco NetFlow Überblick und Konzepte (Herstellerreferenz)
• nfdump/nfcapd als praktische Tool-Referenz für Flow-Analyse

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.