ARP-Spoofing/MITM: Funktionsweise, Packet Evidence und schnelle Detection

ARP-Spoofing/MITM gehört zu den klassischen Angriffsmustern in lokalen Netzwerken (Layer 2) und ist gleichzeitig eine der häufigsten Ursachen für schwer erklärbare Störungen: „Der Server ist manchmal erreichbar“, „TLS bricht sporadisch ab“, „DNS liefert plötzlich andere Antworten“ oder „nur einige Clients haben Probleme“. Der Kern ist immer ähnlich: Ein Angreifer bringt Endgeräte dazu, falsche Zuordnungen zwischen IP-Adresse und MAC-Adresse zu akzeptieren. Dadurch kann der Traffic über das Gerät des Angreifers umgeleitet werden – als Man-in-the-Middle (MITM) für Mitlesen, Manipulation oder gezielte Unterbrechung. Für SecOps und NOC ist dabei entscheidend, dass ARP-Spoofing/MITM nicht nur theoretisch ist: Es lässt sich in PCAPs und Switch-Telemetrie sehr konkret nachweisen. Wer weiß, wonach zu suchen ist, kann die Incident-Diagnose deutlich beschleunigen und den Blast Radius klein halten. Dieser Leitfaden erklärt die Funktionsweise, zeigt typische Packet Evidence (wie es in Wireshark, tcpdump oder SPAN/ERSPAN aussieht) und beschreibt schnelle, risikoarme Detection-Methoden, die auch in produktiven Netzen praktikabel sind.

Grundlagen: Was ARP macht und warum es angreifbar ist

ARP (Address Resolution Protocol) wird in IPv4-Netzen genutzt, um innerhalb eines Broadcast-Domains (z. B. VLAN) eine IP-Adresse einer MAC-Adresse zuzuordnen. Wenn ein Host ein Paket an eine IP im selben Subnetz senden möchte (oder an sein Default Gateway), muss er die Ziel-MAC kennen. Dafür sendet er eine ARP-Request („Wer hat IP X?“) als Broadcast; der Besitzer der IP antwortet per ARP-Reply („IP X ist MAC Y“). Diese Zuordnung wird im ARP-Cache des Hosts gespeichert, typischerweise für Minuten bis Stunden, abhängig vom Betriebssystem.

Das Problem: Klassisches ARP hat keine eingebaute Authentizität. Hosts akzeptieren ARP-Informationen oft auch dann, wenn sie nicht explizit angefragt wurden („gratuitous ARP“) oder wenn ein ARP-Reply plötzlich eine neue MAC für eine bekannte IP behauptet. Genau diese Eigenschaft nutzt ARP-Spoofing aus: Das Zielgerät aktualisiert seinen ARP-Cache auf eine falsche MAC-Adresse, und der Traffic wird umgeleitet.

Für technische Referenzen ist RFC 826 (Address Resolution Protocol) eine gute Grundlage, weil sie das Protokoll und seine Annahmen beschreibt.

Wie ARP-Spoofing/MITM in der Praxis funktioniert

Bei einem ARP-basierten Man-in-the-Middle geht es fast nie darum, „das ganze Internet“ abzufangen, sondern um lokale Segmente: ein Büro-VLAN, ein Server-VLAN, ein Labornetz oder eine schlecht segmentierte Zone. Typische Ziele sind:

• Default-Gateway: Clients werden dazu gebracht, die Gateway-IP auf die MAC des Angreifers zu mappen.
• Server/Service-IP: Ein Client wird umgeleitet, wenn er mit einem bestimmten Server kommuniziert.
• DNS-Resolver: Wer DNS kontrolliert oder umleitet, beeinflusst nachgelagert sehr viele Verbindungen.

Damit ein MITM stabil bleibt, muss der umgeleitete Traffic weiterhin funktionieren – sonst fällt der Angriff als „Outage“ auf. Ein Angreifer kann den Traffic daher typischerweise weiterleiten (Forwarding) und selektiv manipulieren. Für die Verteidigung ist wichtig: Auch wenn TLS viele Inhalte schützt, bleiben Metadaten und Verbindungsstrukturen sichtbar (Ziel-IP, Timing, SNI in manchen Konstellationen, DNS, Zertifikatsketten). Zudem kann ein MITM Downgrade- oder Unterbrechungsversuche auslösen, die im Netzwerk deutlich erkennbar sind.

Symptome im Betrieb: Woran Teams ARP-Spoofing oft zuerst merken

ARP-Spoofing/MITM zeigt sich häufig über unspezifische Symptome, die zunächst wie „Netzwerk instabil“ wirken. Typische Anzeichen sind:

• Sporadische Verbindungsabbrüche: TCP-Retransmissions, Resets, Timeouts ohne klare Serverfehler.
• „Nur einige Clients“ betroffen: weil ARP-Caches unterschiedlich schnell aktualisiert werden.
• Merkwürdige DNS-Effekte: unerwartete Antworten, wechselnde Ziele, starke Latenzspitzen bei DNS.
• TLS-Auffälligkeiten: plötzliche Handshake-Fehler, Zertifikatswarnungen oder ungewöhnliche Häufung von TLS-Alerts.
• MAC-Adressflapping auf Switchports: gleiche MAC „wandert“ zwischen Ports oder ein Port „sieht“ viele MACs.

Diese Symptome sind nicht exklusiv für ARP-Spoofing – aber wenn sie zusammen mit ARP-Anomalien auftreten, lohnt sich eine gezielte Layer-2-Analyse.

Packet Evidence: Was im PCAP typisch ist

Der größte Vorteil bei ARP-Spoofing ist: Der Nachweis ist oft direkt im Traffic sichtbar, ohne Spekulation. Die folgenden Muster sind in PCAPs (SPAN/ERSPAN, Mirror-Port, Host-Capture) besonders aussagekräftig.

ARP-Replys ohne passende Requests

Ein klassischer Indikator sind ARP-Replys, die nicht auf eine zuvor gesehene ARP-Request antworten. In Wireshark sieht man dann ARP-Replys in hoher Frequenz, ohne dass zuvor ein Broadcast-Request „Who has …?“ gesendet wurde. Das ist nicht automatisch bösartig (gratuitous ARP existiert), aber in Kombination mit Frequenz und Cache-Änderungen hoch verdächtig.

IP-to-MAC Mapping ändert sich plötzlich

Sehr stark ist ein Beweis, wenn die gleiche IP-Adresse innerhalb kurzer Zeit mit unterschiedlichen MAC-Adressen auftaucht. Beispiele:

• Gateway-IP 10.0.0.1 wird einmal als MAC A, kurz darauf als MAC B angekündigt.
• Ein Server 10.0.0.50 „springt“ zwischen zwei MACs, ohne dass ein Failover geplant war.

Wenn Sie im PCAP dieselbe Sender-IP mit wechselnder Sender-MAC in ARP-Replys sehen, ist das ein direkter Hinweis. In Wireshark hilft die Anzeige nach „Protocol = ARP“ plus Sortierung nach „Sender IP address“ und „Sender MAC address“.

Gratuitous ARP in ungewöhnlicher Rate

Gratuitous ARP wird legitim genutzt (z. B. bei IP-Übernahmen in HA-Clustern). Verdächtig wird es, wenn:

• die Rate sehr hoch ist (z. B. mehrere pro Sekunde),
• das Muster dauerhaft ist, nicht nur kurz beim Failover,
• die ARP-Ankündigungen viele Ziele betreffen (Gateway, mehrere Server, DNS).

Folgeeffekte in TCP/HTTP/TLS

Ein MITM kann sauber weiterleiten – oder auch nicht. Häufige Folgeindikatoren im PCAP sind:

• Retransmissions und Dup ACKs steigen an (Timing-Probleme durch Umweg/Überlast).
• RST/FIN Anomalien: Sessions werden abrupt beendet.
• TLS Handshake Alerts: Häufung von „Handshake Failure“, „Unknown CA“ oder ähnlichen Alerts (abhängig von Szenario).

Für die praktische Analyse von Retransmissions und TCP-Flows ist die Wireshark-Dokumentation hilfreich, insbesondere zu TCP-Analysefunktionen und Expert-Infos.

Schnelle Detection: „Low Risk“-Checks, die Sie sofort machen können

Im Incident zählt Geschwindigkeit – aber auch Sicherheit: Viele Gegenmaßnahmen können Traffic beeinträchtigen. Deshalb sind zunächst Checks sinnvoll, die keine Policy-Änderung erfordern.

1) ARP-Cache auf betroffenen Hosts prüfen

Wenn ein Client oder Server betroffen ist, ist der ARP-Cache oft der schnellste Hinweis: Zeigt die Gateway-IP die erwartete MAC? Stimmen MAC-OUIs (Hersteller) mit der Umgebung überein? Ungewöhnliche Hersteller-Kennungen können auffallen, sind aber kein alleiniger Beweis.

2) Switch-Telemetrie: MAC Table und Flapping Events

Auf Access- und Distribution-Switches sind MAC-Table-Events stark: Wenn dieselbe MAC-Adresse auf mehreren Ports auftaucht oder schnell zwischen Ports wechselt, deutet das auf Bridge-Loops, Fehlverkabelung oder Missbrauch hin. Ebenso auffällig ist ein Port, der plötzlich sehr viele neue MACs lernt („MAC Flooding“), was als Vorstufe oder Begleiterscheinung auftreten kann.

3) SPAN/ERSPAN gezielt einsetzen

Statt „alles zu spiegeln“, sollte ein Runbook definieren, welche Ports/VLANs bei Verdacht gespiegelt werden: der betroffene Client-Port, der Gateway-Uplink, oder das VLAN-Interface. Wichtig ist, nur kurz und gezielt zu capturen, um Oversubscription zu vermeiden und die Auswertung zu beschleunigen.

4) ARP-Rate und ARP-Fehlerraten überwachen

Eine pragmatische Detektion ist ein Baseline-Vergleich: Wie viele ARP-Pakete pro Minute sind normal, und wann weicht es signifikant ab? Ein einfacher Schwellenwert kann helfen, ohne sofort zu blocken.

$T=\mu +3\times \sigma$

• T: Alarm-Schwelle (z. B. ARP-Pakete/Minute pro VLAN oder pro Switchport)
• μ: Mittelwert der Baseline
• σ: Standardabweichung der Baseline

Dieses 3-Sigma-Prinzip ist bewusst einfach: Es ersetzt keine Ursachenanalyse, liefert aber ein frühes Signal, wenn ARP-Raten „aus dem Ruder“ laufen.

Wie Sie ARP-Spoofing im PCAP eindeutig belegen

Für eine belastbare Incident-Kommunikation sollte Ihr Evidence Pack mehr enthalten als „wir glauben, es ist ARP“. Ein audit- und RCA-tauglicher Nachweis besteht typischerweise aus:

• Mapping-Beweis: Screenshot/Export aus PCAP, dass IP X innerhalb kurzer Zeit MAC A und MAC B zugeordnet wurde.
• Timeline: Erstes Auftreten der ARP-Anomalie, Beginn der Auswirkungen (Loss/Latenz/TLS-Fehler), Ende oder Mitigation.
• Scope: Welche VLANs/Ports/Hosts sind betroffen? Ist es lokal (ein Access-Segment) oder breit (Distribution)?
• Folgeeffekte: TCP-Analyse (Retransmissions), Applikationsfehler, WAF/Gateway-Logs (falls relevant).

Wenn Sie diese vier Komponenten zusammenführen, wird aus „möglicherweise MITM“ ein nachweisbarer, reproduzierbarer Befund.

Abgrenzung: Legitime ARP-Änderungen vs. Angriff

Ein häufiger Fehler ist, jede ARP-Änderung als Angriff zu interpretieren. Legitime Ursachen sind:

• HA-Failover: virtuelle IPs wechseln die MAC (VRRP/HSRP/Cluster), oft begleitet von gratuitous ARP.
• VM-/Container-Migration: Workloads wechseln Host, MACs können sich ändern.
• Netzumbau: Gateway- oder Switchwechsel, Re-IP, neue L2-Domains.

Die Unterscheidung gelingt über Kontext und Muster: Legitimes Failover ist kurz, dokumentiert, betrifft definierte VIPs und hat klare Change-Records. ARP-Spoofing ist oft dauerhaft, hochfrequent, trifft mehrere Ziele und korreliert mit Störungen oder Security-Signalen.

Schnelle Response: Eindämmung ohne unnötige Nebenwirkungen

Bei ARP-Spoofing ist die Versuchung groß, sofort „hart“ zu blocken. Besser ist ein abgestuftes Vorgehen, das den Betrieb schützt und gleichzeitig den Angriffsvektor schließt.

Erste Maßnahmen mit geringem Risiko

• Segment eingrenzen: Betroffene VLANs/Ports identifizieren und Scope reduzieren.
• Verdächtigen Port isolieren: Wenn ein konkreter Access-Port auffällt (MAC-Flapping, hohe ARP-Rate), kann eine temporäre Isolation den Impact stoppen.
• Monitoring verschärfen: ARP-Events, MAC Moves und Switch-Syslogs mit höherer Priorität korrelieren.

Technische Schutzmechanismen im Switching

Für Enterprise-Netze sind L2-Schutzmechanismen oft die effektivste Prävention, weil sie am Ort des Geschehens wirken (Access-Layer):

• Dynamic ARP Inspection (DAI): validiert ARP-Pakete gegen bekannte Bindings (oft in Kombination mit DHCP Snooping).
• DHCP Snooping: baut eine Binding-Tabelle auf und verhindert missbräuchliche DHCP-Server; dient als Basis für DAI.
• IP Source Guard: bindet IP/MAC/Port und verhindert Spoofing auf L2.
• Port Security: limitiert MAC-Learning pro Port und kann MAC-Flooding reduzieren.

Für eine herstellerneutrale Einordnung lohnt sich der Blick in Switch- und Plattformdokumentationen; als Einstieg sind z. B. Beschreibungen zu Dynamic ARP Inspection (Cisco) oder zu Switch-Sicherheitsfeatures in den jeweiligen Vendor-Guides geeignet.

Detection Engineering: Praktische Signale für SIEM und NDR

Wenn Sie ARP-Spoofing nicht nur „manuell“ erkennen wollen, brauchen Sie Detektionssignale, die stabil sind und wenig False Positives erzeugen. Geeignete Signale sind:

• IP-to-MAC Change Rate: Wie oft ändert sich die MAC für eine IP innerhalb eines Zeitfensters?
• Gratuitous ARP Burst: ungewöhnliche Häufung von gratuitous ARP aus einem Port oder einer MAC.
• MAC Move/Flap Events: gleiche MAC auf mehreren Ports in kurzer Zeit.
• ARP Traffic Share: ARP als Anteil am Gesamttraffic steigt sprunghaft (Storm-/Spoof-Indikator).
• Korrelation mit Impact: ARP-Anomalie + gleichzeitiger Anstieg von Retransmissions/Timeouts.

Für eine robuste Detektion ist die Korrelation entscheidend: Ein einzelnes ARP-Event kann normal sein; eine Kombination aus Mapping-Änderungen, Rate-Spikes und Impact-Metriken ist deutlich aussagekräftiger.

Packet Evidence in Wireshark: Filters und Auswertungen, die schnell helfen

Für die Analyse reichen oft wenige, gezielte Filter und Views. Statt eine „Kochanleitung für Angriffe“ zu liefern, liegt der Fokus hier auf defensiver Sichtbarkeit.

• ARP filtern: Anzeige nur der ARP-Pakete, um Frequenz und Senderbeziehungen zu erkennen.
• Konversationen: TCP/UDP Conversations, um ungewöhnliche Pfade oder neue Zwischenstationen zu identifizieren.
• Expert Infos: Auffälligkeiten wie Retransmissions, Duplicates, RST-Spikes sichtbar machen.
• Zeitleiste: ARP-Ereignisse und Impact (z. B. TCP-Probleme) zeitlich korrelieren.

Als Referenz für Analysefunktionen und Interpretation ist die Wireshark-Dokumentation sinnvoll, weil sie erklärt, wie Wireshark bestimmte TCP-Events klassifiziert.

Warum TLS trotz MITM oft „rettet“ – und wo die Grenzen sind

Ein verbreiteter Irrtum ist: „Mit TLS ist MITM egal.“ TLS reduziert die Gefahr erheblich, aber es löst nicht alle Probleme:

• Vertraulichkeit: Inhalte sind geschützt, sofern Zertifikatsprüfung nicht umgangen wird.
• Integrität: Manipulation ist stark erschwert; Fehlkonfigurationen können aber Downgrades ermöglichen.
• Metadaten: Ziel-IP, Timing, Traffic-Volumen und häufig auch DNS bleiben sichtbar.
• Verfügbarkeit: Ein MITM kann Verbindungen stören (DoS), auch wenn Inhalte geschützt sind.

Für TLS-Hintergründe ist RFC 8446 (TLS 1.3) eine verlässliche Quelle.

Prävention im Enterprise: Architektur- und Betriebsmaßnahmen

Die beste Abwehr gegen ARP-Spoofing/MITM ist, Angriffsflächen strukturell zu reduzieren. Besonders wirksam sind:

• Kleinere Broadcast-Domains: VLANs nicht unnötig groß; Segmentierung reduziert Reichweite.
• Strikte Access-Kontrollen: NAC/802.1X, Port-Security, klare Guest/Corp-Trennung.
• L2-Schutzfeatures: DAI/DHCP Snooping/IP Source Guard dort, wo es sinnvoll ist.
• Monitoring an Control Points: Switch-Events, ARP-Anomalien, Flow-Sichtbarkeit an Boundaries.
• Change Governance: HA-Failover, VIP-Umzüge und Netzumbauten sauber dokumentieren, damit legitime ARP-Änderungen nicht wie Angriff wirken.

SecOps-Runbook: Minimaler Ablauf bei Verdacht auf ARP-Spoofing/MITM

Ein kurzer, operativer Ablauf hilft, in Stresssituationen konsistent zu handeln und Evidence nicht zu verlieren:

• Triage: Betroffene Hosts/Segmente identifizieren, Zeitfenster festlegen, Impact messen.
• Evidence sichern: PCAP (kurz, gezielt), ARP-Cache-Snapshots, Switch MAC/ARP-Events, Firewall/Gateway-Logs.
• Hypothese prüfen: IP-to-MAC Mapping-Änderungen belegen, Rate-Spikes und Flapping korrelieren.
• Eindämmen: Verdächtigen Port/Segment isolieren, ohne „global“ zu blocken; Monitoring verstärken.
• Ursache klären: Legitimer Failover vs. Angriff; Owner/Change-Records prüfen; bei Angriff Incident-Prozess starten.

Für Incident-Response-Methodik und Evidence-orientierte Vorgehensweisen ist NIST SP 800-61 eine etablierte Referenz, die sich gut als Prozessrahmen neben technischen Runbooks eignet.

Outbound-Quellen für belastbare Grundlagen

Für das ARP-Protokoll und seine Funktionsweise ist RFC 826 die maßgebliche technische Referenz. Für TLS-Grundlagen und Handshake-Verhalten eignet sich RFC 8446 (TLS 1.3). Für die praktische PCAP-Analyse und Interpretation von TCP-Auffälligkeiten ist die Wireshark-Dokumentation hilfreich. Für Switch-seitige Schutzmechanismen gegen ARP-Manipulation bietet eine Einführung zu Dynamic ARP Inspection (DAI) einen konkreten Einstieg in das Konzept. Für Incident Response und evidenzbasiertes Vorgehen ist NIST SP 800-61 eine bewährte Grundlage.

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.