bintorosoft.com

IP Source Guard konfigurieren: Zugriffskontrolle auf Ports

Secure Data Sharing Protocol

Im Access-Layer entscheidet sich oft, wie sicher ein Netzwerk wirklich ist. Selbst wenn Firewalls, VLANs und Routing sauber geplant sind, kann ein einzelner kompromittierter Client im falschen Moment Schaden anrichten – etwa indem er sich eine fremde IP-Adresse gibt, den Gateway-ARP-Cache manipuliert oder versucht, mit gespooften Quelladressen Zugriff auf Ressourcen zu bekommen. Genau hier setzt IP Source Guard konfigurieren an: Diese Cisco-Sicherheitsfunktion kontrolliert auf Switch-Ports, ob die Quell-IP-Adresse eines Pakets überhaupt zu dem Endgerät passt, das an diesem Port angeschlossen ist. Praktisch bedeutet das: Ein Client darf nur mit „seiner“ IP-Adresse sprechen – und idealerweise nur mit „seiner“ MAC-Adresse. Damit verhindert IP Source Guard eine ganze Klasse typischer Layer-2/Layer-3-Angriffe wie IP-Spoofing, viele ARP-bedingte Umgehungsversuche und auch „kleine“ Fehler im Alltag (z. B. wenn Nutzer statisch eine falsche IP setzen). In Cisco-Designs arbeitet IP Source Guard besonders effektiv zusammen mit DHCP Snooping (für die Binding Table) und Dynamic ARP Inspection (DAI) (gegen ARP-Spoofing). Dieser Leitfaden erklärt die Funktionsweise, zeigt Schritt für Schritt die Konfiguration auf Cisco Switches, liefert praxistaugliche Best Practices und hilft Ihnen dabei, typische Rollout-Fallen zu vermeiden – damit die Zugriffskontrolle auf Ports mehr Sicherheit bringt, ohne den Betrieb zu stören.

Was ist IP Source Guard und welches Problem löst es?

IP Source Guard (oft kurz „IPSG“) ist eine Port-basierte Sicherheitsfunktion auf Cisco Switches. Sie erzwingt, dass auf einem Access-Port nur IP-Pakete akzeptiert werden, deren Quelladresse zu einer bekannten, vertrauenswürdigen Zuordnung (Binding) passt. Diese Zuordnung stammt in der Regel aus der DHCP Snooping Binding Table, kann aber je nach Design auch durch statische Bindings ergänzt werden.

Als Cisco-Einstiegspunkt eignet sich der Anchor-Text Cisco DHCP Snooping Überblick, weil DHCP Snooping die Grundlage für IPSG bildet. Für DAI als ergänzende ARP-Schutzschicht ist der Anchor-Text Cisco Dynamic ARP Inspection (DAI) hilfreich.

Wie funktioniert IP Source Guard technisch?

Damit IP Source Guard effizient arbeiten kann, braucht der Switch eine Zuordnung, welche IP-Adresse an welchem Port „legitim“ ist. In vielen Cisco Campus-Designs entsteht diese Zuordnung dynamisch:

Kommt nun ein Paket auf dem Port an, dessen Quell-IP nicht zur Binding passt, wird es gedroppt. Das ist eine wirkungsvolle Zugriffskontrolle auf Ports, weil sie direkt am Eintrittspunkt (Access-Port) greift.

Voraussetzungen: Ohne DHCP Snooping wird IPSG schnell schwierig

In der Praxis scheitert IP Source Guard nicht am Feature selbst, sondern an fehlenden oder falschen Bindings. Daher gilt als Grundregel: DHCP Snooping zuerst sauber implementieren, dann IP Source Guard aktivieren.

Für den Protokollhintergrund zu DHCP ist der Anchor-Text RFC 2131 (DHCP) sinnvoll, insbesondere um zu verstehen, wann Bindings entstehen und wie Leases erneuert werden.

Typische Use Cases: Wann IP Source Guard besonders sinnvoll ist

IP Source Guard ist kein „nice to have“, sondern in vielen Access-Layer-Szenarien ein sehr pragmatischer Schutz. Besonders sinnvoll ist IPSG in diesen Umgebungen:

Schritt 1: DHCP Snooping aktivieren und verifizieren

Da IPSG in den meisten Designs auf DHCP Snooping basiert, beginnen Sie mit der Snooping-Grundlage. Beispiel: VLAN 10 und VLAN 20 sollen geschützt werden.

DHCP Snooping global und VLAN-basiert aktivieren

configure terminal
ip dhcp snooping
ip dhcp snooping vlan 10,20
end

Uplink(s) trusted setzen

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

Bindings prüfen

show ip dhcp snooping binding

Wenn hier keine Einträge entstehen, ist IPSG-Rollout riskant, weil Ports dann legitimen Traffic blocken könnten (je nach Plattformverhalten und Konfiguration).

Schritt 2: IP Source Guard auf Access-Ports aktivieren

IP Source Guard wird typischerweise auf Endgeräteports eingeschaltet – also dort, wo Clients angeschlossen sind. Die konkrete Syntax kann je nach Catalyst-Modell und IOS/IOS XE-Version variieren, das Grundprinzip ist jedoch: „IP Source Guard einschalten und optional MAC-Prüfung erzwingen“.

Beispiel: IPSG auf einem Client-Port aktivieren

configure terminal
interface gigabitethernet1/0/10
description Client-Port
ip verify source
end

Beispiel: IPSG mit Port-Security/MAC-Logik kombinieren

In vielen Umgebungen wird IPSG zusammen mit MAC-basierter Kontrolle genutzt, damit nicht nur die IP stimmt, sondern auch die MAC-Adresse am Port stabil bleibt. Ein typisches Muster ist die Ergänzung über Port-Security (plattformabhängig) und/oder erweiterte IPSG-Optionen. Der Kern bleibt: Sie wollen verhindern, dass ein Client sowohl IP als auch MAC „frei“ wählen kann.

Statische IPs: Die häufigste Rollout-Falle bei IP Source Guard

IP Source Guard stützt sich in vielen Designs auf DHCP-Bindings. Geräte mit statischer IP (z. B. Drucker, OT/IoT, Spezialhardware) erscheinen nicht automatisch in der DHCP Snooping Binding Table. Das führt dazu, dass IPSG deren Traffic blockieren kann – und das wirkt dann wie „Port kaputt“.

Sie haben drei praxistaugliche Strategien:

Best Practice: Reduzieren Sie statische IPs im Client-Layer. Reservierungen sind in der Regel wartbarer, erzeugen Bindings und harmonieren mit DAI/IPSG deutlich besser.

IP Source Guard im Kontext: DHCP Snooping, DAI und IPSG als Schutzkette

In Cisco Campus-Designs werden diese drei Features häufig als abgestimmtes Paket genutzt:

Damit schließen Sie typische Angriffsvektoren im Access-Layer: falsche IP, falsches ARP, falsche DHCP-Quelle. Diese Schutzkette ist besonders wirksam, weil sie direkt am Switchport greift – dort, wo der untrusted Bereich beginnt.

Verifikation: So prüfen Sie, ob IPSG wirklich greift

Nach der Aktivierung ist Verifikation entscheidend. Ziel: Legitimer Client-Traffic läuft, Spoofing wird blockiert, und Sie können den Zustand nachvollziehen.

Ein pragmatischer Funktionstest im Pilot: Client bekommt per DHCP eine IP, kann Gateway/DNS erreichen. Danach ändern Sie auf dem Client testweise die IP manuell auf eine „falsche“ Adresse – IPSG sollte den Traffic blockieren (in kontrollierter Testumgebung).

Troubleshooting: Wenn nach IPSG-Aktivierung Clients „kein Netz“ haben

Wenn IP Source Guard den Betrieb stört, ist die Ursache fast immer in der Binding-Logik oder in Sonderfällen am Port zu finden. Die häufigsten Fehlerbilder:

Keine DHCP-Binding vorhanden

Prüfen:

Port hängt an einem Gerät mit mehreren Clients (AP/Hypervisor/Sonderverkabelung)

Fix: Für solche Ports ist IPSG oft nur sinnvoll, wenn das Design dafür vorgesehen ist (z. B. spezielle Trunk-/Access-Strategien, höhere Limits, andere Kontrollmechanismen wie 802.1X/MAB). In vielen Netzen ist der Access-Port für APs/Hosts nicht „klassischer Client-Port“, sondern ein Sonderfall, der dokumentiert und gezielt behandelt werden muss.

Bindings gehen nach Reboot verloren

Fix: DHCP Snooping Database persistieren und Rollout so planen, dass nach Reboots ein kontrollierter Re-Learn stattfindet.

Best Practices: Zugriffskontrolle auf Ports ohne Kollateralschäden

Für herstellerneutrale Sicherheits- und Betriebsprinzipien (Access-Layer-Härtung, Change-Management, Monitoring) eignet sich der Anchor-Text CIS Controls.

Praxis-Checkliste: Rollout von IP Source Guard

Konfiguration speichern und Betrieb absichern

Wenn IP Source Guard auf den Ziel-Ports stabil läuft und Sie die Bindings sowie die Client-Konnektivität verifiziert haben, speichern Sie die Konfiguration:

copy running-config startup-config

Für plattformspezifische Details, Syntaxvarianten und die exakten Verhaltensweisen Ihrer Catalyst-Serie ist die Cisco-Dokumentation zur Access-Layer-Security ein guter Ausgangspunkt. Starten Sie dafür über den Anchor-Text Cisco DHCP Snooping Überblick und ergänzen Sie mit Cisco DAI, weil IPSG in der Praxis nahezu immer im Zusammenspiel mit diesen Funktionen geplant wird.

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:

Lieferumfang:

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.

 

Exit mobile version