Anomalie-Erkennung ist in modernen Netzwerken eine der wenigen Methoden, die auch dann noch funktioniert, wenn Angreifer keine bekannten Signaturen auslösen und wenn ein Großteil des Traffics verschlüsselt ist. Statt „was ist bekannt böse?“ fragt Anomalie-Erkennung: „was ist für dieses Netzwerk, dieses Segment oder diesen Service untypisch?“ Genau dafür brauchen Sie Baselines – also belastbare Normalwerte für East-West Traffic (laterale Kommunikation innerhalb von Datacenter/Cloud/Campus) und North-South Traffic (Ein- und Ausverkehr über Internet, Partner, WAN, VPN). Ohne Baselines wird jeder Peak zum Alarm und jede Änderung zum Incident, was unweigerlich in Alert-Fatigue endet. Mit gut gebauten Baselines können Sie dagegen sehr früh Hinweise auf Lateralmovement, Datenabfluss, C2-Beaconing, Fehlkonfigurationen oder DDoS-nahe Effekte erkennen, ohne im Rauschen zu ertrinken. Dieser Artikel zeigt, wie Sie Baselines für East-West und North-South Traffic praktisch aufbauen, welche Metriken und Telemetriequellen sich bewährt haben, wie Sie Saisonalität und Change-Events berücksichtigen und wie Sie aus Anomalien High-Signal Cases machen – statt „ML-Alarme“, die niemand ernst nimmt.
East-West vs. North-South: Warum zwei Baseline-Welten nötig sind
East-West und North-South unterscheiden sich nicht nur topologisch, sondern auch im Normalverhalten. Wer beide gleich behandelt, baut fast zwangsläufig schlechte Schwellenwerte.
- East-West Traffic: Service-to-Service-Kommunikation, Datenbankzugriffe, Auth/Directory, Storage, Backup, Cluster-Health. Charakteristisch sind viele interne Ziele, stabile Portmuster und starke Abhängigkeiten zwischen Anwendungen.
- North-South Traffic: Egress zu SaaS/Cloud/Update-Zielen, Ingress zu öffentlichen Services, Partnernetze, Remote Access. Charakteristisch sind wechselnde Ziel-IP-Ranges (CDNs/Cloud), große Lastspitzen durch Nutzerverhalten und häufige externe Scans.
In der Praxis bedeutet das: East-West Baselines sind oft feiner und serviceorientiert („wer darf mit wem“), North-South Baselines sind stärker risiko- und kategoriebasiert („welche Ziele, welche Volumina, welche Muster“).
Telemetrie: Welche Daten Sie für Baselines wirklich brauchen
Anomalie-Erkennung steht und fällt mit den Daten. Für Traffic-Baselines sind drei Klassen besonders wertvoll, weil sie sich ergänzen:
- Flow-Daten (NetFlow/IPFIX/VPC Flow Logs): skalierbar für „wer spricht mit wem“, Volumen, Dauer, Ports, Pakete.
- Security-Logs (Firewall/Proxy/DNS): Policy-Kontext, Allow/Deny, NAT, Domain-/URL-Kontext, User/Device.
- Telemetry (Interface/Queue/Session KPIs): Zustand, Drops, PPS/CPS, Session Table, HA Events, Routing Flaps.
Für IPFIX als Standard ist RFC 7011 eine gute Referenz, weil es die Exportmechanik und das Datenmodell beschreibt.
Das Baseline-Prinzip: „Normal ist segment-, zeit- und serviceabhängig“
Baselines sind keine globalen Zahlen („Bandbreite normal: 1 Gbit/s“), sondern Profile. Ein gutes Baseline-Design berücksichtigt mindestens:
- Segment/Zone: User, Server, Management, OT/IoT, DMZ – jedes Segment hat andere Muster.
- Service/Applikation: Web→App→DB, Backup, Monitoring, Directory – jedes System hat seinen eigenen Rhythmus.
- Zeit: Tages-/Wochenmuster, Monatsabschlüsse, Wartungsfenster, Batch-Jobs.
- Topologie: East-West in Datacenter/Cloud, North-South über Proxy/SWG/VPN/Edge.
Ein Baseline-System, das diese Dimensionen ignoriert, erzeugt zwangsläufig False Positives.
Baseline-Aufbau in der Praxis: Ein stufenweises Vorgehen
Ein bewährter Ansatz ist, Baselines in drei Stufen aufzubauen – vom Groben zum Präzisen:
- Stufe 1: Makro-Baselines (Netzgesundheit): Bandbreite/PPS pro Link, Top-Talker, Top-Ports, neue Peaks.
- Stufe 2: Segment-Baselines (Zonenverhalten): typische Ziele, typische Kategorien, typische Ports pro Segment.
- Stufe 3: Service-Baselines (Abhängigkeitsgraphen): erlaubte Servicepfade, typische Frequenzen, typische Volumina pro Kommunikation.
So erreichen Sie schnell erste Erkennungsfähigkeit (Stufe 1/2) und bauen anschließend die präzisesten Signale (Stufe 3).
Metriken für North-South Baselines
North-South ist stark nutzer- und internetabhängig. Gute Baselines fokussieren auf Kategorien und Muster, weniger auf einzelne IPs.
- Bytes-out/Bytes-in pro Segment: Egress/Ingress Volumen, Peaks und Drift.
- PPS/CPS Trends: Viele kleine Verbindungen (CPS) sind oft auffälliger als Bandbreite.
- Neue Destination Kategorien: neue SaaS-Kategorien, neue Country/ASN-Kombinationen (als Kontextsignal).
- Newly seen Domains: DNS- oder Proxy-basierte „neu im Unternehmen“ Ziele.
- Proxy Bypass Rate: Anteil direkter 443-Verbindungen statt Proxy/SWG-Pfad (Umgehung/C2-Indikator).
- Denied/Reset Ratio: Verhältnis Allow/Deny/Reset, besonders bei Edge-Policies und WAF/IPS-Events.
Metriken für East-West Baselines
East-West Baselines sind besonders stark bei Lateralmovement und Fehlkonfigurationen. Hier sind „wer mit wem“ und „wie oft“ zentrale Features.
- Peer Graph: Welche internen Systeme kommunizieren typischerweise miteinander?
- Fan-out/Fan-in: Ein Host kontaktiert plötzlich viele Peers (Fan-out) oder wird von vielen kontaktiert (Fan-in).
- Admin-Port-Muster: SMB/RDP/WinRM/SSH/LDAP – ungewöhnliche Nutzung ist oft hochrelevant.
- Flow-Entropie: Viele kurze Flows zu vielen Zielen kann Scan/Discovery bedeuten.
- Auth-Path Baselines: Welche Clients sprechen typischerweise mit Identity Services (DC/LDAP/Kerberos)?
- Data Tier Access: Unerwartete Pfade zu DB- oder Storage-Zonen (Client→DB) sind oft No-Go und sollten besonders sensibel sein.
Saisonalität und Change-Events: Der häufigste Baseline-Killer
Baselines, die Change nicht berücksichtigen, erzeugen Alarmfluten bei Deployments, Wartungsfenstern oder Monatsabschlüssen. Zwei Best Practices vermeiden das:
- Change-Awareness: Change Windows aus ITSM/CI/CD ins Monitoring einspeisen; in diesen Fenstern andere Schwellen oder Suppression anwenden.
- Adaptive Baselines: Baselines mit gleitenden Fenstern (z. B. 7/14/30 Tage) und robusten Statistiken, damit Ausreißer nicht sofort „neues Normal“ werden.
Statistische Schwellenwerte: Einfach, robust, erklärbar
Sie brauchen nicht zwingend komplexes ML, um gute Anomalie-Erkennung zu erreichen. In vielen Umgebungen funktionieren robuste, erklärbare Verfahren besser, weil sie leichter zu tunen und zu auditieren sind.
Robuste Z-Score-Logik mit Quantilen
Eine einfache, praxistaugliche Methode ist, pro Metrik und Segment ein typisches Quantilband (z. B. 5.–95. Perzentil) zu bestimmen und Abweichungen zu markieren. Alternativ nutzen viele Teams Median und Median Absolute Deviation (MAD), um Ausreißer robust zu erkennen.
MAD = median ( | x – median ( x ) | )
Der Vorteil: Diese Methoden sind stabil gegen Ausreißer (z. B. ein großer Backup-Job) und leichter zu erklären als Blackbox-Modelle.
Rate-of-Change als Frühwarnsignal
- Delta-Metriken: „Wie schnell verändert sich der Wert?“ ist oft relevanter als der absolute Wert.
- Beispiel: CPS springt innerhalb von 2 Minuten um Faktor 5 – das ist oft ein besseres Signal als „CPS ist hoch“.
Detections aus Baselines: Anomalie ist nicht automatisch Incident
Ein häufiges Anti-Pattern ist, jede Abweichung als Alert zu behandeln. Gute Anomalie-Erkennung erzeugt zunächst „Anomalie-Events“, die erst nach Korrelation zu Cases werden. Ein bewährtes Modell:
- Level 1 (Anomaly Event): Abweichung dokumentieren, Kontext anreichern, aber noch kein Ticket.
- Level 2 (Case): Anomalie wiederholt sich, betrifft kritische Assets oder passt zu einem TTP-Muster.
- Level 3 (Incident): Mehrere Signale stimmen überein (Flow + DNS + Firewall + EDR), Response-Playbook startet.
Zur Strukturierung solcher TTP-Muster ist MITRE ATT&CK hilfreich, weil Sie Anomalien in Angriffsphasen übersetzen können (Discovery, Lateral Movement, C2, Exfiltration).
High-Signal Anomalie-Patterns für North-South
- Neue Egress-Ziele aus Server-Zonen: Prod-Server spricht erstmals zu unbekanntem ASN/Hosting-Typ oder neuer Kategorie.
- Upload-Anomalien: Bytes-out steigt stark, besonders zu seltenen Zielen oder „unsanctioned apps“.
- Beaconing-Anzeichen: periodische 443-Verbindungen mit konstanten Intervallen.
- DNS-Anomalien: newly seen domains, NXDOMAIN-Spikes, DGA-ähnliche Muster, DoH-Bypass.
- Edge-Policy Drift: Verhältnis Allow/Deny/Reset ändert sich stark nach Policy-Commit.
High-Signal Anomalie-Patterns für East-West
- Fan-out Scan: ein Host kontaktiert plötzlich viele interne Ziele auf Admin-Ports.
- Neue Peer-Beziehungen: Workload spricht erstmals mit DB- oder Management-Zonen.
- Identity Path Drift: neue Clients sprechen plötzlich häufig mit DC/LDAP/Kerberos.
- Service Graph Brüche: Web-Tier spricht plötzlich direkt mit Storage oder Backup-Subnetzen.
- Segmentübergreifende Chats: IoT/OT Gerät beginnt, viele interne Systeme zu kontaktieren.
Kontextanreicherung: Der Unterschied zwischen „komisch“ und „kritisch“
Damit Baselines nicht zu Alert-Fatigue führen, brauchen Sie Enrichment. Besonders wirksam sind:
- Asset-Kritikalität: Prod vs. Dev, DC/DB/Jump Host – erhöht Priorität.
- Zone/Trust: Management/DMZ/Server-Zonen – beeinflusst Risiko.
- Identity/Device: Privilegierte Nutzer, neue Geräte, nicht-compliant Endpoints.
- NAT/Proxy-Kontext: Attribution hinter Egress NAT, Proxy-Bypass als Umgehungssignal.
- Threat Intel: Nur als Kontext (Confidence/TTL), nicht als alleiniger Trigger.
Response: Von Anomalien zu schnellen, sicheren Maßnahmen
Die beste Anomalie-Erkennung bringt wenig, wenn Response unklar ist. Ein praxistaugliches Response-Set umfasst:
- Triage-Checklist: Ist es Change-bedingt? Gibt es Ticket/Deployment? Ist der Host kritisch?
- Scope-Suche: Wer zeigt dasselbe Muster? Welche Ziele sind betroffen?
- Containment-Optionen: DNS sinkhole, Proxy/FW block mit Timeboxing, EDR isolate, NAC quarantine.
- Nachweise: relevante Logs/Flows sichern, um Postmortems zu ermöglichen.
Für strukturierte Incident-Prozesse ist NIST SP 800-61 Rev. 2 eine nützliche Referenz.
Qualitätssicherung: Baselines brauchen Pflege
Baselines sind nicht „einmal bauen, fertig“. Netzwerke und Anwendungen ändern sich. Deshalb braucht es Betrieb und KPIs:
- Coverage: Welche Segmente liefern Flow-Daten? Wo fehlen Sensoren?
- Data Quality: Ingest-Lag, Drop-Rate, Parser-Errors, Time Drift.
- Signalqualität: TP/FP pro Pattern, Trendanalyse, Top Noise Sources.
- Change-Korrelation: Wie viele Anomalien entstehen durch Deployments? Muss das Change-Awareness verbessert werden?
- Rezertifizierung: Ausnahmen, Whitelists, Service Graph-Modelle regelmäßig prüfen.
Praktische Checkliste: Baselines für East-West und North-South Traffic aufbauen
- 1) Datenquellen sichern: NetFlow/IPFIX + Firewall/DNS/Proxy Logs + Telemetry, alles NTP-synchron und in UTC.
- 2) Segmentieren: Zonen/VRFs/Trust Levels definieren, East-West und North-South getrennt modellieren.
- 3) Makro-Baselines starten: Bandbreite/PPS/CPS, Top Talkers, Top Ports pro Link/Zone.
- 4) Segment-Baselines bauen: typische Ziele, Kategorien, Ports pro Segment; Proxy-Bypass messen.
- 5) Service-Baselines entwickeln: Peer Graphs, erlaubte Pfade, Fan-out/Fan-in, Admin-Port-Muster.
- 6) Saisonalität einplanen: Tages-/Wochenmuster, Batch-Jobs, Wartungsfenster; Change-Awareness integrieren.
- 7) Robuste Schwellen nutzen: Quantile/MAD/Rate-of-change statt fragiler Durchschnittswerte.
- 8) Korrelation einführen: Anomalie-Event → Case → Incident (mehrere Signale).
- 9) Response-Playbooks definieren: Triage, Scope, Containment mit Timeboxing, Evidence.
- 10) Betrieb messen: TP/FP, Coverage, Data Quality, regelmäßige Reviews und Rezertifizierung.
Outbound-Quellen für Standards und Vertiefung
- RFC 7011 (IPFIX) für Flow-Export als Grundlage skalierbarer Traffic-Baselines.
- MITRE ATT&CK zur Ableitung von Anomalie-Patterns entlang realer Angreifertechniken (Discovery, Lateral Movement, C2, Exfil).
- NIST SP 800-61 Rev. 2 für Incident Response Prozesse, die Anomalien in Containment und Recovery übersetzen.
- CIS Controls für praxisnahe Kontrollen zu Monitoring, Logging, Detection Engineering und kontinuierlicher Verbesserung.
- NIST SP 800-92 für Prinzipien zu Log-Management, Datenqualität und Governance als Basis für verlässliche Baselines.
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.

