DHCP Snooping, DAI, IP Source Guard: Layer-2-Hardening

DHCP Snooping, DAI, IP Source Guard: Layer-2-Hardening ist im Enterprise eines der effektivsten Mittel, um klassische Layer-2-Angriffe und Fehlkonfigurationen frühzeitig zu stoppen, bevor sie sich zu großflächigen Incidents entwickeln. In vielen Netzwerken sind VLANs und Switchports historisch gewachsen: Gäste, IoT, BYOD, Drucker, Produktionsgeräte und Office-Clients teilen sich häufig dieselbe Access-Infrastruktur. Genau dort entsteht ein Risiko, das oft unterschätzt wird: Layer 2 ist „nah dran“ an den Endgeräten und damit anfällig für Spoofing, Rogue-DHCP-Server, Man-in-the-Middle-Szenarien via ARP, IP-Adressdiebstahl oder schlichtes Fehlpatching. DHCP Snooping, Dynamic ARP Inspection (DAI) und IP Source Guard sind drei eng zusammenhängende Schutzmechanismen, die auf Access- und Distribution-Switches umgesetzt werden und gemeinsam ein robustes Baseline-Defense-System bilden. DHCP Snooping kontrolliert, wer DHCP-Server spielen darf und baut eine Bindings-Tabelle aus MAC, IP, VLAN und Port auf. DAI nutzt diese Bindings, um ARP-Pakete zu verifizieren und ARP-Spoofing zu blockieren. IP Source Guard setzt die Bindings schließlich als Weiterleitungsregel durch und verhindert, dass ein Port mit „falscher“ IP/MAC-Kombination überhaupt produktiv senden kann. Richtig implementiert, reduzieren diese Mechanismen nicht nur Sicherheitsrisiken, sondern verbessern auch die Betriebssicherheit: Viele schwer zu findende Fehlerbilder – von „plötzlich falsches Gateway“ bis „sporadisch kein Netz“ – werden durch klare Portrollen und Validierungsregeln deutlich schneller eingrenzbar. Dieser Artikel erklärt Architektur und Zusammenspiel, zeigt typische Failure Modes und liefert praxistaugliche Design- und Betriebsregeln, damit Layer-2-Hardening nicht zum Support-Problem wird, sondern zum zuverlässigen Standard.

Warum Layer-2-Hardening heute Pflicht ist

Layer 2 war lange Zeit ein „vertrauenswürdiger“ Bereich: Wer am Switch hängt, gehört dazu. Mit zunehmender Gerätevielfalt, offeneren Arbeitsumgebungen und höherem Automatisierungsgrad ist dieses implizite Vertrauen nicht mehr realistisch. Besonders kritisch sind Access-Segmente, in denen Endgeräte direkten Einfluss auf DHCP- und ARP-Verhalten haben. Ein einziges kompromittiertes Gerät kann dort in Sekunden ein ganzes VLAN stören.

• Rogue DHCP: Ein fremder DHCP-Server verteilt falsche IPs, Gateway oder DNS-Server und verursacht Outages oder Traffic-Umleitungen.
• DHCP Starvation: Ein Angreifer erschöpft den DHCP-Pool durch massenhaft Requests mit wechselnden MACs.
• ARP Spoofing/Poisoning: Manipulierte ARP-Antworten leiten Traffic über einen Angreifer (Man-in-the-Middle) oder erzeugen Blackholing.
• IP Spoofing: Ein Endgerät nutzt eine IP, die ihm nicht zusteht, um Policies zu umgehen oder Konflikte zu erzeugen.
• Fehlkonfigurationen: Falsch angeschlossene Switches, „mini-Switches“ unter dem Tisch, falsche VLAN-Zuordnung oder falsch konfigurierte DHCP-Relays.

Für die Grundlagen von DHCP und den Ablauf von Lease-Vergaben sind RFC 2131 (DHCP) und RFC 2132 (DHCP Options) hilfreiche Referenzen. Für ARP als Basismechanismus eignet sich RFC 826 (ARP).

DHCP Snooping: Der Anker für Bindings und Vertrauen

DHCP Snooping ist der erste Baustein im Trio. Die Idee ist simpel: Der Switch klassifiziert Ports als „trusted“ oder „untrusted“. DHCP-Server-Antworten (z. B. DHCPOFFER, DHCPACK) dürfen nur über trusted Ports kommen. Auf untrusted Ports werden solche Antworten verworfen. Gleichzeitig beobachtet der Switch DHCP-Transaktionen und schreibt eine DHCP Snooping Binding Table: Zuordnung von MAC-Adresse, zugewiesener IP-Adresse, VLAN, Port und Lease-Zeit. Diese Tabelle wird später von DAI und IP Source Guard genutzt.

• Trusted Ports: Uplinks zu Distribution/Core, DHCP-Server-Port, DHCP-Relay-Pfad (je nach Design).
• Untrusted Ports: Endgeräteports (User, IoT, Drucker), AP-Edge-Ports – grundsätzlich alles, was kein autorisierter DHCP-Server sein darf.
• Binding Table: (MAC, IP, VLAN, Interface, Lease) als operative „Source of Truth“ für nachgelagerte Validierungen.

Welche Angriffe DHCP Snooping direkt mitigiert

• Rogue DHCP Server: DHCP-Antworten von untrusted Ports werden blockiert.
• Teilweise DHCP-Manipulation: Falsche Default Gateways oder DNS-Server sind schwerer durchsetzbar, weil nur autorisierte DHCP-Antworten passieren.
• Stabilere Diagnose: Binding Table zeigt, welcher Port welche IP erhalten hat – wertvoll bei Incidents.

Dynamic ARP Inspection: ARP validieren statt vertrauen

Dynamic ARP Inspection (DAI) adressiert das klassische ARP-Problem: ARP kennt keine Authentizität. Jeder Host kann ARP Replies senden, und andere Hosts akzeptieren sie typischerweise. DAI prüft ARP-Pakete (Requests und/oder Replies, je nach Plattform) gegen eine vertrauenswürdige Datenbasis. In DHCP-basierten Netzen ist das meist die DHCP Snooping Binding Table. Stimmen Sender-IP, Sender-MAC, VLAN und Port nicht zur Binding Table, kann der Switch das ARP-Paket droppen, loggen und/oder den Port in einen Schutzstatus setzen.

• Validierung: „Passt diese ARP-Information zur bekannten IP/MAC-Port-Bindung?“
• Schutz gegen ARP Poisoning: verhindert, dass ein Host sich als Gateway oder als anderer Host ausgibt.
• Operative Transparenz: DAI-Drops sind starke Indikatoren für Spoofing oder Fehlkonfigurationen.

DAI ist in vielen Implementierungen eng an DHCP Snooping gekoppelt. Ohne verlässliche Bindings ist DAI entweder nicht nutzbar oder muss mit statischen ARP-ACLs/Bindings ergänzt werden (z. B. für statische IPs).

IP Source Guard: IP/MAC am Port erzwingen

IP Source Guard setzt die Bindings als Durchsetzungsmechanismus um. Während DAI spezifisch ARP prüft, kontrolliert IP Source Guard die Quell-IP (und oft auch die Quell-MAC) von Datenpaketen, die ein Port senden darf. Ziel ist, IP Spoofing im Access zu verhindern. Der Switch erlaubt nur Pakete, deren Quellattribute zur Binding Table passen. Je nach Plattform geschieht das über Hardware-Filter (ähnlich einer portbasierten ACL) oder über spezielle Forwarding-Checks.

• IP Spoofing verhindern: Ein Host kann nicht einfach eine andere IP nutzen, um Policies zu umgehen.
• Stabilere Segmentierung: Quelladressen im Segment entsprechen den erwarteten Leases/Bindings.
• Ergänzung zu DAI: DAI schützt die Auflösung, IP Source Guard schützt die Nutzung.

Zusammenspiel: Warum die drei Mechanismen gemeinsam am stärksten sind

Alle drei Funktionen adressieren unterschiedliche Phasen des gleichen Problems: „Wer darf im Segment welche Identität annehmen?“ DHCP Snooping etabliert Vertrauen und Bindings, DAI schützt die ARP-basierte Zuordnung, IP Source Guard erzwingt die Quellidentität im Datenverkehr. Wird nur ein Teil aktiviert, bleiben Lücken.

• Nur DHCP Snooping: Rogue DHCP ist erschwert, ARP Spoofing bleibt möglich.
• Nur DAI ohne saubere Bindings: viele False Positives oder hohe Betriebsaufwände durch statische Regeln.
• Nur IP Source Guard: kann Spoofing verhindern, aber ARP Poisoning kann weiterhin Traffic umleiten, wenn die ARP-Ebene nicht geschützt ist.
• Trio zusammen: konsistente Identität vom Lease bis zum Datenpaket, deutlich geringere Angriffsfläche.

Architektur im Enterprise: Portrollen, Trust-Boundary und Topologie

Der wichtigste Designschritt ist die Definition der Trust Boundary: Bis wohin vertrauen Sie DHCP-Antworten, und an welchen Stellen darf ARP/ND „ungeprüft“ passieren? Im klassischen Campus ist der Access-Switch der ideale Ort, weil dort die Endgeräteports beginnen. In verteilten Umgebungen (Remote Access, Mikrostandorte, Campus-WLAN) muss die Boundary bewusst gewählt werden.

• Access-Edge: Endgeräteports grundsätzlich untrusted, Uplink zur Distribution trusted.
• DHCP Server/Relay: Ports und Pfade, über die DHCP Replies kommen, müssen trusted sein.
• WLAN/AP-Design: je nach Betriebsmodus (Tunnel/Bridging) sind Bindings und Trust-Ports anders zu bewerten.
• Server/VM-Edge: Hypervisor-uplinks können viele MACs/IPs tragen; Policies müssen zu dieser Realität passen.

Besonderheit: Statische IPs und Geräte ohne DHCP

Viele Enterprise-Umgebungen haben Ausnahmen: Drucker, OT-Geräte, Appliances oder Management-Interfaces mit statischer IP. DHCP Snooping erzeugt für diese Geräte keine Bindings. Wenn Sie DAI und IP Source Guard trotzdem aktivieren, brauchen Sie eine Ergänzung:

• Statische Bindings: manuell definierte IP/MAC/Port-Zuordnungen (aufwendig, aber kontrolliert).
• ARP-ACLs: erlauben bestimmte ARP-Kombinationen (plattformabhängig).
• Portrollen-Sonderbehandlung: definierte Ports/VLANs mit alternativer Policy (nur, wenn sauber dokumentiert und überwacht).

Failure Modes: Wie Layer-2-Hardening „aus Versehen“ Ausfälle erzeugt

DHCP Snooping, DAI und IP Source Guard greifen in Basisfunktionen ein. Fehler in Trust-Ports, VLAN-Trunks oder Timing können deshalb realen Traffic blockieren. Typische Failure Modes sind gut bekannt und lassen sich mit klaren Betriebsregeln stark reduzieren.

• Falsch gesetzte Trust-Ports: DHCP Replies werden gedroppt → Clients bekommen keine IP (oder verlieren sie nach Lease-Refresh).
• Trunk/VLAN-Mismatch: Bindings werden im falschen VLAN geführt oder kommen nicht zustande → DAI dropt legitime ARP.
• Relay/Option-Handling: DHCP über Relays kann spezielle Optionen/Topologien erfordern; falsch interpretierte Antworten wirken wie Rogue DHCP.
• Lease-Timeout/Churn: wenn Endpunkte häufig wechseln, kann eine veraltete Binding Table zu Drops führen.
• Server/Hypervisor-Uplinks: viele IPs/MACs auf einem Port (vSwitch/Bridge) kollidieren mit zu restriktiven Erwartungen.
• Asymmetrische Konfiguration: nur ein Switch im Pfad hat DAI aktiv → Debugging wird schwierig, weil Drops „unsichtbar“ wirken.

Symptome im Incident: Woran Sie Hardening-Probleme erkennen

• DHCP funktioniert sporadisch: Clients erhalten IP nur nach mehreren Versuchen oder gar nicht.
• Nur bestimmte Geräte fallen aus: oft Geräte mit statischer IP oder ungewöhnlichem DHCP-Client-Verhalten.
• Gateway „nicht erreichbar“ trotz Link up: ARP wird gedroppt, daher kein L2-Nachbarzustand.
• DAI-/Snooping-Logs steigen: ungewöhnlich viele Drops/Violations nach einem Change.

Telemetrie und Betrieb: Was Sie messen und alarmieren sollten

Layer-2-Hardening ist nur dann betriebssicher, wenn Sie Drops und Violations sichtbar machen. Andernfalls sehen Sie nur die Anwendungssymptome. Idealerweise korrelieren Sie Switch-Telemetrie mit NAC/802.1X-Informationen und DHCP-Server-Logs.

• DHCP Snooping Drops: Anzahl gedroppter DHCP Replies auf untrusted Ports, Rate-Limit-Events, Binding-Table-Größe.
• DAI Violations: gedroppte ARP-Pakete, Port- oder VLAN-bezogene Hotspots, Top-Quell-MACs/IPs.
• IP Source Guard Drops: Pakete mit nicht erlaubter Quell-IP/MAC, Häufung nach Reboots oder Moves.
• Storm Control Korrelation: ARP/DHCP-Spikes mit Broadcast/Unknown-Unicast Countern abgleichen.
• Change-Korrelation: Trunk-Änderungen, VLAN-Moves, neue Voice/WLAN-Profile, neue DHCP Scopes.

Ein einfaches Rate-Limit-Modell für DHCP Snooping

$\mathrm{MaxRequests}=\mathrm{RateLimit}\times \mathrm{Zeitfenster}$

Wenn Sie auf Access-Ports ein DHCP Snooping Rate Limit setzen, ist MaxRequests der grobe Rahmen, wie viele DHCP-Requests ein Port in einem Zeitfenster akzeptieren kann, bevor er drosselt oder schützt. Zu niedrige Werte erzeugen False Positives (z. B. bei Boot-Stürmen oder Telefon+PC), zu hohe Werte reduzieren den Schutz gegen Starvation.

Mitigation-Techniken: Hardening so konfigurieren, dass es nicht „beißt“

Das Ziel ist ein Setup, das Angriffe und Fehlverhalten stoppt, aber legitime Sonderfälle sauber abbildet. Bewährte Maßnahmen:

• Portrollen-Templates: User-Port, Voice-Port, AP-Port, IoT-Port, Server-Port, Uplink – je Rolle definierte Snooping/DAI/Source-Guard-Profile.
• Trust minimal vergeben: trusted nur dort, wo DHCP-Antworten wirklich herkommen müssen.
• Statische Bindings sauber verwalten: für Geräte ohne DHCP, inklusive Ownership, Dokumentation und Lifecycle.
• Rate Limits realistisch setzen: pro Portrolle, mit Baselines aus Telemetrie statt „Gefühl“.
• Logging mit Augenmaß: genug Daten für RCA, aber keine Log-Stürme, die Control Plane belasten.
• Rollout schrittweise: zuerst monitoren (wo möglich), dann blocken; Pilotsegmente mit hohem Support-Fokus.

Design im Kontext von VLANs, Trunks und MLAG

Layer-2-Hardening ist eng an VLAN-Design und Trunking gekoppelt. Wenn VLANs großflächig gestreckt werden, steigt die Komplexität: Bindings entstehen an vielen Stellen, ARP-Pfade sind länger, und Fehlkonfigurationen wirken weiter. Ebenso können MLAG-Designs mit dual-homed Access Switches besondere Aufmerksamkeit erfordern, weil Bindings und Portrollen symmetrisch sein müssen.

• Allowed VLANs statt „all“: reduziert die Ausbreitung potenzieller Rogue-DHCP- oder ARP-Effekte.
• Symmetrie in MLAG: identische Policies auf beiden Peers, sonst entstehen „nur auf einer Seite“ Drops.
• Broadcast-Domain-Größe begrenzen: kleinere VLANs verringern die Wirkung von ARP- und DHCP-Anomalien.
• L3 näher an die Edge: reduziert Angriffsfläche und Fault Domains, weil ARP nur innerhalb des Subnetzes relevant ist.

Für VLAN-Bridging-Grundlagen ist IEEE 802.1Q eine passende Referenz.

IPv6-Hinweis: Was ändert sich bei ND, RA und DHCPv6?

DHCP Snooping und DAI sind historisch stark IPv4-/ARP-orientiert. In IPv6-Umgebungen verschieben sich die Schwerpunkte: Neighbor Discovery (ND) und Router Advertisements (RA) sind zentrale Kontrollpunkte. Viele Hersteller bieten RA Guard, ND Inspection oder ähnliche Mechanismen als IPv6-Pendant. Operativ ist wichtig, das Konzept der Trust Boundary beizubehalten: Wer darf RAs senden, wer darf ND-Informationen beeinflussen, und wie werden Bindings/Identitäten abgebildet?

• RA Guard: blockiert unerwünschte Router Advertisements an Access-Ports.
• ND Inspection/Snooping: validiert ND-Informationen ähnlich wie DAI für ARP.
• DHCPv6: kann ergänzend genutzt werden, ersetzt aber RA nicht vollständig (je nach Design).

Für IPv6 Neighbor Discovery ist RFC 4861 eine zentrale Quelle, um Failure Modes und Validierungslogik korrekt einzuordnen.

Praxis-Runbook: Telemetrie-basierte Behebung bei Verdacht auf Spoofing oder Rogue DHCP

• Scope des Problems bestimmen: betroffenes VLAN, betroffene Etage/Access-Switch, Zeitpunkt und Change-Korrelation.
• DHCP Snooping Events prüfen: Drops auf untrusted Ports, Binding Table Einträge, Rate-Limit-Trigger.
• Rogue-Quelle lokalisieren: Port mit DHCP-Reply-Versuchen; physische Zuordnung (Patchfeld/Room/Device) herstellen.
• DAI Violations prüfen: welche IP/MAC-Kombinationen werden gedroppt, ist es ein einzelner Host oder viele?
• Binding-Integrität validieren: stimmt das VLAN, stimmt der Port, sind Leases aktuell?
• Containment: Port isolieren (Quarantäne VLAN), Rate Limits verschärfen, ggf. Port shutdown nach Prozess.
• Nachsorge: Portrolle/Template korrigieren, statische Bindings ergänzen, Monitoring-Schwellen anpassen.

Outbound-Links für Standards und vertiefende Informationen

• RFC 2131 (Dynamic Host Configuration Protocol – DHCP)
• RFC 2132 (DHCP Options)
• RFC 826 (Address Resolution Protocol – ARP)
• RFC 4861 (Neighbor Discovery for IPv6)
• IEEE 802.1Q (VLAN Bridging als L2-Grundlage)
• DHCP Snooping und DAI (Praxisdoku und Troubleshooting-Beispiele)

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.