DHCP Snooping konfigurieren: Schutz vor Rogue DHCP

Ein „Rogue DHCP“-Server ist einer der schnellsten Wege, ein funktionierendes LAN in wenigen Minuten zu sabotieren – oft unbeabsichtigt. Ein falsch angeschlossener Heimrouter im Büro, ein „hilfreicher“ Mini-Switch mit DHCP-Funktion oder ein kompromittiertes Gerät kann Clients mit falschen IP-Adressen, falschem Default Gateway oder manipulierten DNS-Servern versorgen. Die Folgen reichen von „kein Internet“ bis zu gezieltem Traffic-Abgriff (Man-in-the-Middle), weil DNS-Anfragen umgebogen oder Gateways gefälscht werden. Genau hier setzt DHCP Snooping konfigurieren an: Diese Sicherheitsfunktion auf Cisco Switches überwacht DHCP-Nachrichten auf Layer 2, blockiert DHCP-Angebote von nicht autorisierten Ports und erstellt eine vertrauenswürdige Binding-Tabelle (IP ↔ MAC ↔ VLAN ↔ Port). Damit schützen Sie Ihre Nutzer vor Rogue DHCP, erhöhen die Stabilität der Adressvergabe und schaffen gleichzeitig die Grundlage für weitere Schutzmechanismen wie Dynamic ARP Inspection (DAI) und IP Source Guard. In diesem Leitfaden lernen Sie Schritt für Schritt, wie DHCP Snooping in Cisco-Umgebungen korrekt eingerichtet wird, welche Ports „trusted“ sein müssen, wie Sie Rate-Limits sinnvoll setzen, welche typischen Fehler beim Rollout auftreten – und wie Sie das Feature so implementieren, dass es sicher ist, ohne den Betrieb zu stören.

Was ist DHCP Snooping und warum ist es so effektiv?

DHCP Snooping ist eine Switch-Funktion, die DHCP-Traffic (in der Regel DHCPv4) überwacht und klassifiziert. Der zentrale Gedanke ist einfach: In einem VLAN gibt es üblicherweise nur wenige legitime DHCP-Server (z. B. ein zentraler Server im Rechenzentrum oder ein Router im Standort). Alle anderen Ports sollten keine DHCP-Serverantworten (DHCPOFFER, DHCPACK, DHCPNAK) ins VLAN senden dürfen. DHCP Snooping setzt genau hier an, indem es Ports in zwei Kategorien einteilt:

  • Trusted Ports: dürfen DHCP-Serverantworten senden (typisch: Uplinks, Ports zum DHCP-Server, Port-Channels zur Distribution).
  • Untrusted Ports: dürfen keine DHCP-Serverantworten senden (typisch: Endgeräteports, Access-Ports).

Zusätzlich führt der Switch eine DHCP Snooping Binding Table, in der er dynamisch lernt, welche IP-Adresse einem Client (MAC) an welchem Port und in welchem VLAN zugewiesen wurde. Diese Tabelle ist in vielen Designs die Grundlage für weitere Layer-2-Sicherheitsfunktionen. Eine gute Cisco-Referenz zum Einstieg bietet der Anchor-Text Cisco DHCP Snooping Überblick.

Rogue DHCP: Typische Ursachen und reale Auswirkungen

Ein Rogue DHCP-Server ist nicht immer ein Angreifer. Häufig entsteht das Problem durch Fehlkonfiguration oder Unwissen. Typische Ursachen:

  • Ein Mitarbeiter bringt einen Heimrouter mit und steckt ihn ins LAN (DHCP ist standardmäßig aktiv).
  • Ein Access Point oder IoT-Gateway startet mit aktivem DHCP-Dienst.
  • Ein Testgerät im Labor wird versehentlich in ein produktives VLAN gepatcht.
  • Ein kompromittiertes Gerät verteilt absichtlich „böse“ DHCP-Optionen.

Die Auswirkungen sind gravierend, weil DHCP zentrale Parameter verteilt:

  • Falsches Default Gateway: Clients senden Traffic an ein falsches Gerät, Internet und Intranet brechen ein.
  • Manipulierte DNS-Server: Auflösung wird umgebogen, Benutzer landen auf Phishing-Seiten.
  • IP-Konflikte: Mehrere DHCP-Server vergeben dieselben Adressen, Instabilität entsteht.
  • Schatten-Subnetze: Clients landen in einem falschen IP-Bereich und können zentrale Services nicht erreichen.

Voraussetzungen und Designprinzipien vor der Aktivierung

Bevor Sie DHCP Snooping einschalten, sollten Sie Ihr Layer-2-/Layer-3-Design kurz prüfen. Das Feature wirkt am besten, wenn klar ist, wo DHCP-Server stehen und über welche Links DHCP-Antworten in die VLANs gelangen.

  • DHCP-Server-Standort: zentral (z. B. Serverfarm) oder lokal (z. B. Router im Standort).
  • DHCP Relay (ip helper-address): Wenn DHCP zentral ist, kommen die Antworten über Uplink/Distribution zurück.
  • VLAN-Scope: Auf welchen VLANs soll Snooping aktiv sein? Meist nur Client-VLANs, nicht zwingend alle.
  • Trusted Ports definieren: Uplink-Trunks, Port-Channels, Ports zum DHCP-Server müssen trusted sein.

Best Practice: Starten Sie mit einem Pilot-VLAN, validieren Sie die Funktion und rollen Sie danach schrittweise aus. DHCP Snooping ist sicher, aber falsch gesetzte Trust-Ports können DHCP für ein VLAN vollständig lahmlegen.

Grundkonfiguration: DHCP Snooping auf Cisco Switch aktivieren

Die Konfiguration erfolgt in der Regel in drei Schritten: Feature aktivieren, VLANs auswählen, Trust-Ports setzen. Die genauen Befehle können je nach Catalyst-Serie und IOS/IOS XE leicht variieren, das Grundmuster ist jedoch stabil.

Schritt 1: DHCP Snooping global aktivieren

configure terminal
ip dhcp snooping
end

Schritt 2: DHCP Snooping für VLANs aktivieren

Beispiel: Snooping für VLAN 10 und VLAN 20 (Client-VLANs):

configure terminal
ip dhcp snooping vlan 10,20
end

Wichtig: Ohne VLAN-Zuordnung ist DHCP Snooping zwar global aktiv, greift aber nicht in den VLANs.

Schritt 3: Trusted Ports definieren

Trusted sind Ports, über die legitime DHCP-Serverantworten in das VLAN gelangen. Typisch sind Uplinks zur Distribution oder Ports zum DHCP-Server/Relay-Pfad.

configure terminal
interface gigabitethernet1/0/48
description Uplink zur Distribution
ip dhcp snooping trust
end

Alle anderen Access-Ports bleiben standardmäßig untrusted – genau das ist gewollt.

Rate Limiting: DHCP-Floods und Fehlverhalten begrenzen

Neben Rogue DHCP schützt DHCP Snooping auch vor DHCP-Flooding, bei dem ein Gerät massenhaft DHCP-Requests erzeugt, um den Pool zu erschöpfen. Deshalb ist ein Rate-Limit auf untrusted Ports eine sehr sinnvolle Ergänzung. Damit begrenzen Sie, wie viele DHCP-Pakete pro Sekunde ein Endgeräteport senden darf.

Beispiel: Rate-Limit auf einem Access-Port setzen

configure terminal
interface gigabitethernet1/0/10
description Client-Port
ip dhcp snooping limit rate 15
end

Die richtige Rate hängt von Ihrer Umgebung ab. Für typische Clientports sind niedrige Werte sinnvoll. Für Access Points oder Ports mit vielen Clients (z. B. hinter einem Telefon mit PC, oder hinter einem kleinen Switch in Sonderfällen) müssen Sie eventuell höher gehen – sofern das Design diese Anschlüsse überhaupt zulässt.

Option 82 (DHCP Relay Information): Chancen und typische Fallstricke

Option 82 fügt DHCP-Nachrichten zusätzliche Informationen über den Eingangsport und VLAN-Kontext hinzu. Das ist besonders in größeren Netzen nützlich, weil DHCP-Server damit pro Standort/Port unterschiedliche Policies anwenden können. Allerdings kann Option 82 auch zu Problemen führen, wenn der DHCP-Server oder ein Upstream-Gerät die Option nicht erwartet.

  • Vorteil: bessere Nachvollziehbarkeit, standortbasierte Zuweisungen, Audit-Fähigkeit.
  • Risiko: Einige DHCP-Server oder Sicherheitsrichtlinien droppen Pakete mit Option 82.

Wenn nach Aktivierung von DHCP Snooping plötzlich keine Leases mehr vergeben werden, ist Option 82 ein möglicher Grund. Prüfen Sie dann die Server- und Relay-Einstellungen. Für den allgemeinen DHCP-Standardkontext ist der Anchor-Text RFC 2131 (DHCP) hilfreich.

DHCP Snooping Binding Table: Warum sie so wichtig ist

Die Binding Table ist ein zentrales Ergebnis von DHCP Snooping. Sie enthält dynamisch gelernte Zuordnungen aus DHCPACKs, typischerweise:

  • Client-MAC-Adresse
  • zugewiesene IP-Adresse
  • VLAN
  • Port
  • Lease-Zeit

Diese Tabelle ist nicht nur zur Diagnose nützlich („Welcher Client hat welche IP?“), sondern auch die Grundlage für:

  • Dynamic ARP Inspection (DAI): blockiert ARP-Spoofing anhand der Binding Table.
  • IP Source Guard: erlaubt IP-Traffic nur, wenn er zur bekannten IP/MAC/Port-Zuordnung passt.

Damit wird DHCP Snooping zu einem Baustein einer mehrschichtigen Access-Layer-Security-Strategie.

Persistenz: Binding Database speichern, damit Reboots nicht schaden

Ein praktisches Betriebsproblem: Wenn ein Switch neu startet, verliert er ohne zusätzliche Konfiguration seine dynamische Binding Table. In Umgebungen mit DAI oder IP Source Guard kann das nach einem Reboot zu unerwarteten Blockings führen, weil keine Bindings bekannt sind, bis Clients ihre Leases erneuern. Deshalb ist es oft sinnvoll, die DHCP Snooping Database zu persistieren.

Beispiel: Snooping Database lokal speichern

configure terminal
ip dhcp snooping database flash:dhcp_snoop.db
end

Je nach Plattform kann auch ein Remote-Speicher (z. B. via TFTP/FTP) möglich sein. Wichtig ist, dass der Speicherort zuverlässig ist und in Ihren Betriebsprozessen berücksichtigt wird.

DHCP Snooping in Trunk- und EtherChannel-Umgebungen

In modernen Cisco-Netzen sind Uplinks häufig Trunks und oft als EtherChannel gebündelt. DHCP Snooping funktioniert hier zuverlässig, wenn Sie die Trust-Logik korrekt setzen:

  • Trunk-Uplinks: in der Regel trusted, weil DHCP-Antworten darüber zurückkommen (vom DHCP-Server oder Relay-Pfad).
  • Port-Channel: Trust wird am logischen Port-Channel oder an den Member-Ports gesetzt (plattformabhängig). Best Practice ist, die Konfiguration konsistent am Port-Channel zu führen.
  • Access-Ports: bleiben untrusted, auch wenn dort IP-Telefone oder APs hängen; bei Sonderfällen Rate-Limits anpassen.

Wenn Sie DHCP Snooping auf einem Access-Switch aktivieren und das DHCP Relay auf einem L3-Switch sitzt, muss der Uplink zwischen beiden trusted sein, sonst werden die DHCPACKs blockiert und Clients bekommen keine Lease.

Verifikation: So prüfen Sie, ob DHCP Snooping korrekt arbeitet

Nach der Aktivierung sollten Sie verifizieren, dass Snooping aktiv ist, die VLANs stimmen, Trust korrekt gesetzt ist und Bindings aufgebaut werden. Diese Befehle sind in Cisco-Umgebungen besonders nützlich:

  • show ip dhcp snooping (Status, VLANs, Option 82, Counters)
  • show ip dhcp snooping binding (Binding Table)
  • show running-config | include dhcp snooping (Konfigübersicht)
  • show interfaces status (Ports identifizieren, Uplink prüfen)

Ein plausibler Zustand ist: DHCP Snooping ist enabled, die relevanten VLANs sind gelistet, der Uplink-Port ist trusted, Access-Ports sind untrusted, und in der Binding Table erscheinen Clients nach DHCP-Vergabe.

Troubleshooting: Häufige Fehler und schnelle Fixes

Wenn nach der Aktivierung plötzlich „kein DHCP“ mehr funktioniert, liegt es sehr oft an einem Trust- oder VLAN-Fehler. Die folgenden Ursachen sind in der Praxis am häufigsten.

Problem: Clients bekommen keine IP mehr

  • Uplink nicht trusted: DHCPACKs kommen über den Uplink, werden aber blockiert.
  • Falsche VLAN-Liste: Snooping ist nicht für das betroffene VLAN aktiviert.
  • Option 82 Konflikt: DHCP-Server/Relay akzeptiert Pakete nicht.
  • Rate Limit zu niedrig: DHCP-Pakete werden gedroppt (bei APs/Mehrclientports möglich).

Prüfen Sie zuerst:

  • show ip dhcp snooping (VLANs, Drops/Counters)
  • show running-config interface <Uplink> (trust vorhanden?)
  • show ip dhcp snooping binding (werden Bindings aufgebaut?)

Problem: Rogue DHCP ist weiterhin aktiv

  • Falscher Port trusted: Ein Endgeräteport wurde versehentlich trusted gesetzt.
  • Rogue sitzt „hinter“ einem trusted Link: z. B. ein falscher Switch hinter einem Uplink-Port im Access-Bereich.
  • DHCP Snooping nicht im richtigen VLAN aktiv: Rogue verteilt im VLAN, das nicht geschützt ist.

Fix: Trust-Ports ausschließlich auf Uplinks/Serverports setzen, VLAN-Abdeckung prüfen und im Zweifelsfall Access-Design korrigieren (keine unmanaged Switches in kritischen Bereichen).

Problem: Bindings fehlen nach Reboot und Security-Features blocken

  • DHCP Snooping Database nicht persistent konfiguriert
  • Clients erneuern Leases nicht sofort

Fix: Snooping Database persistieren und Rollout-Plan so gestalten, dass nach Reboots eine kontrollierte Lease-Erneuerung stattfindet.

Best Practices: DHCP Snooping sicher und wartbar einführen

  • Schrittweiser Rollout: erst Pilot-VLAN, dann Ausweitung auf weitere VLANs.
  • Trust nur auf Uplinks/Serverports: niemals pauschal „trust überall“.
  • Rate Limiting aktivieren: schützt vor Flooding und Fehlverhalten.
  • Option 82 bewusst behandeln: Server-Kompatibilität prüfen, dokumentieren.
  • Persistenz einplanen: Database speichern, wenn DAI/IP Source Guard genutzt werden.
  • Dokumentation: welche VLANs geschützt sind, welche Ports trusted sind, welche Limits gelten.
  • Monitoring: Drops/Counters beobachten und bei Auffälligkeiten alarmieren.

Als herstellerneutrale Orientierung für Sicherheitsgrundlagen (Access-Layer-Härtung, Change-Management, Monitoring) eignet sich der Anchor-Text CIS Controls.

Zusammenspiel mit weiteren Schutzfunktionen

DHCP Snooping ist besonders stark, wenn es Teil eines abgestimmten Schutzpakets ist. Zwei Funktionen werden in Cisco-Campus-Netzen häufig gemeinsam eingesetzt:

  • Dynamic ARP Inspection (DAI): verhindert ARP-Spoofing, indem ARP-Claims gegen die Snooping Binding Table geprüft werden.
  • IP Source Guard: erlaubt IP-Traffic nur, wenn er zur bekannten IP/MAC/Port-Zuordnung passt.

Wichtig ist, diese Funktionen erst nach sauberer Snooping-Grundlage einzuführen, weil sie ohne Bindings schnell zu „mysteriösen“ Blockings führen können.

Praxis-Checkliste: Vor dem Go-Live

  • DHCP Snooping ist global aktiv und für alle relevanten Client-VLANs eingeschaltet.
  • Uplinks/Port-Channels zur Distribution bzw. Ports zum DHCP-Server sind trusted.
  • Access-Ports sind untrusted und haben sinnvolle Rate-Limits.
  • Option 82 Verhalten ist bekannt und mit DHCP-Server/Relay kompatibel.
  • Bindings werden korrekt aufgebaut und sind über show ip dhcp snooping binding sichtbar.
  • Bei Einsatz von DAI/IP Source Guard ist die Snooping Database persistent konfiguriert.
  • Rollout ist dokumentiert (VLANs, trusted Ports, Limits, Verantwortlichkeiten).

Konfiguration speichern und Betrieb absichern

Nachdem DHCP Snooping in den Ziel-VLANs aktiv ist und Sie die Funktion mit echten Clients verifiziert haben, sollten Sie die Konfiguration speichern:

copy running-config startup-config

Für weiterführende Cisco-spezifische Details, Plattformunterschiede und Troubleshooting-Hinweise ist der Anchor-Text Cisco DHCP Snooping Überblick eine hilfreiche Ergänzung, insbesondere wenn Sie Option-82-Verhalten, Datenbankpersistenz oder das Zusammenspiel mit DAI/IP Source Guard im Detail planen.

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.

 

Related Articles