11
Verwendung von statischen IPs in bestimmten IP-Bereichen verhindern
Der Titel beschreibt meine Frage schon mal grundsätzlich.
Mein Ziel ist es, IP-Konflikte und "unautorisierte" Verwendung von IP-Adressen zu verhindern.
Ich besitze einen Cisco Switch (CBS350), der gleichzeitig als DHCP-Server dient. Der Switch stellt mehrere VLANS zur Verfügung. Manche Clients werden per Port einem VLAN zugeordnet, andere Clients (Wifi) werden per MAC-Adresse dem entsprechenden VLAN zugeordnet. Jedes VLAN besitzt einen eigenen DHCP-Pool. Zudem gibt es in jedem VLAN / Netzbereich eine Unterteilung in (a) IP-Adressen, die frei verwendet werden können (Client wählt statische IP) und (b) Adressen die per DHCP vergeben werden.
Im Bereich (a) sollen nur bestimmte IPs statisch vom Client verwendet werden dürfen und die restlichen IPs im Bereich (a) sollen "geschützt" sein. Ich denke an "IP X darf nur an Gerät mit MAC-Adresse Y vergeben werden. Ist das der richtige Ansatz und wenn ja, wie kann ich das realisieren?
Im Bereich (b) sollen nur vom DHCP-Server vergebene IP-Adressen "akzeptiert" werden. Ich denke auch hier wieder an die Verknüpfung von MAC- und IP-Adresse aber dieses mal gebunden, an den DHCP-Lease. Auch hier wieder die Frage, ob der Ansatz richtig ist und wenn ja, wie ich das realisieren kann?
Gibt es mit meinem Switch eine Lösung für das Problem?
Ich wäre Euch für Euren Input sehr dankbar.
Mein Ziel ist es, IP-Konflikte und "unautorisierte" Verwendung von IP-Adressen zu verhindern.
Ich besitze einen Cisco Switch (CBS350), der gleichzeitig als DHCP-Server dient. Der Switch stellt mehrere VLANS zur Verfügung. Manche Clients werden per Port einem VLAN zugeordnet, andere Clients (Wifi) werden per MAC-Adresse dem entsprechenden VLAN zugeordnet. Jedes VLAN besitzt einen eigenen DHCP-Pool. Zudem gibt es in jedem VLAN / Netzbereich eine Unterteilung in (a) IP-Adressen, die frei verwendet werden können (Client wählt statische IP) und (b) Adressen die per DHCP vergeben werden.
Im Bereich (a) sollen nur bestimmte IPs statisch vom Client verwendet werden dürfen und die restlichen IPs im Bereich (a) sollen "geschützt" sein. Ich denke an "IP X darf nur an Gerät mit MAC-Adresse Y vergeben werden. Ist das der richtige Ansatz und wenn ja, wie kann ich das realisieren?
Im Bereich (b) sollen nur vom DHCP-Server vergebene IP-Adressen "akzeptiert" werden. Ich denke auch hier wieder an die Verknüpfung von MAC- und IP-Adresse aber dieses mal gebunden, an den DHCP-Lease. Auch hier wieder die Frage, ob der Ansatz richtig ist und wenn ja, wie ich das realisieren kann?
Gibt es mit meinem Switch eine Lösung für das Problem?
Ich wäre Euch für Euren Input sehr dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13476880751
Url: https://administrator.de/contentid/13476880751
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
11 Kommentare
Neuester Kommentar
Ich sag mal "hallo"...
So, wie die Frage gestellt ist, lautet die Antwort "nein". Um mal die Möglichkeiten abzuklären:
Wie sieht der Rest der Umgebung aus? Firewall (Next-Gen, WAF, etc.), Router, Access Points, WLAN Authentifizierung, Server, Hypervisor, verwendete Betriebssysteme und Clients, Management der Clients, AD / PKI vorhanden, 802.1x, NPS, NAC, Verkabelung fest oder für jeden zugänglich, Capture Portal, Gastnetze, SDN, etc.
Optionen können beliebige Kombinationen aus Access Controll Lists, DHCP-Reservierungen, "sticky MAC addresses", MAC-Adresslimits, DHCP Snooping, Firewall-Regeln, Deep Packet Inspection und so weiter sein. Dafür brauchen wir natürlich mehr Informationen ;)
Die von dir erstellten DHCP Scopes umfassen also nicht das jeweils gesamte Netz, sondern nur einen Teilbereich. So weit, so gut, so gängig. Die IPs, die per DHCP vergeben werden, kannst du halbwegs kontrollieren - DHCP-Reservierung und DHCP Snooping. Ein Host, der seine IP selbst bestimmt (z. B. statisch eingetragen) und nicht per DHCP bezieht, kann erst mal tun und lassen, was er will. Auf reiner Switch-Basis wirst du dem nicht beikommen.
Auf dem Switch kannst du noch mit "Sticky MAC Addresses" arbeiten. Recht viel mehr kann der CBS350 selbst nicht, meine ich. (Ich hatte aber auch nur die Vorgänger in der Hand.)
Es mag auch an der Uhrzeit liegen, aber irgendwie verstehe ich nur die Hälfte deines Posts. Das übergeordnete Ziel ist klar. Das wollen wir Admins nämlich alle.
So, wie die Frage gestellt ist, lautet die Antwort "nein". Um mal die Möglichkeiten abzuklären:
Wie sieht der Rest der Umgebung aus? Firewall (Next-Gen, WAF, etc.), Router, Access Points, WLAN Authentifizierung, Server, Hypervisor, verwendete Betriebssysteme und Clients, Management der Clients, AD / PKI vorhanden, 802.1x, NPS, NAC, Verkabelung fest oder für jeden zugänglich, Capture Portal, Gastnetze, SDN, etc.
Optionen können beliebige Kombinationen aus Access Controll Lists, DHCP-Reservierungen, "sticky MAC addresses", MAC-Adresslimits, DHCP Snooping, Firewall-Regeln, Deep Packet Inspection und so weiter sein. Dafür brauchen wir natürlich mehr Informationen ;)
Die von dir erstellten DHCP Scopes umfassen also nicht das jeweils gesamte Netz, sondern nur einen Teilbereich. So weit, so gut, so gängig. Die IPs, die per DHCP vergeben werden, kannst du halbwegs kontrollieren - DHCP-Reservierung und DHCP Snooping. Ein Host, der seine IP selbst bestimmt (z. B. statisch eingetragen) und nicht per DHCP bezieht, kann erst mal tun und lassen, was er will. Auf reiner Switch-Basis wirst du dem nicht beikommen.
Auf dem Switch kannst du noch mit "Sticky MAC Addresses" arbeiten. Recht viel mehr kann der CBS350 selbst nicht, meine ich. (Ich hatte aber auch nur die Vorgänger in der Hand.)
Es mag auch an der Uhrzeit liegen, aber irgendwie verstehe ich nur die Hälfte deines Posts. Das übergeordnete Ziel ist klar. Das wollen wir Admins nämlich alle.
Moin,
Was sind das für Kisten, die statische Einträge "frei wählen" dürfen? Normalerweise macht das ein Admin und der sollte wissen was er tut. Aber Standard ist eher, daß man die statische n Adressen auch per DHCP vergibt, indem man eine Reservierung macht und alles vorgibt. Und wenn User das selbstständig machen, gibt man denen klare Regeln vor, die dann mit einem LART wie z.B. CAT9 auch durchgesetzt werden.
lks
Was sind das für Kisten, die statische Einträge "frei wählen" dürfen? Normalerweise macht das ein Admin und der sollte wissen was er tut. Aber Standard ist eher, daß man die statische n Adressen auch per DHCP vergibt, indem man eine Reservierung macht und alles vorgibt. Und wenn User das selbstständig machen, gibt man denen klare Regeln vor, die dann mit einem LART wie z.B. CAT9 auch durchgesetzt werden.
lks
3
Also wenn selbst Mikrotik das beherrscht sollte sich bei einem Cisco doch auch das automatische ARP Learning deaktivieren und die ARP-Tabelle nur mit DHCP Leases füllen lassen.
Bei Mikrotik stellt man für sowas einfach auf dem Interface ARP auf "reply-only" und im DHCP auf "add ARP for leases". Dann ist die statische Vergabe durch Clients die nicht statisch im Switch hinterlegt wurden Geschichte und nur die MACs die man manuell in die ARP Tabelle des Switches einträgt können die dort hinterlegte statische IP dann auch benutzen.
Gruß
Bei Mikrotik stellt man für sowas einfach auf dem Interface ARP auf "reply-only" und im DHCP auf "add ARP for leases". Dann ist die statische Vergabe durch Clients die nicht statisch im Switch hinterlegt wurden Geschichte und nur die MACs die man manuell in die ARP Tabelle des Switches einträgt können die dort hinterlegte statische IP dann auch benutzen.
Gruß
Auch kein Hallo...
So können nur Mac Adress registrierte Clients ins Netz und bekommen dann vom DHCP Server über diese Client spezifische Mac Adresse auch eine spezifische IP Adresse die du dann bei Bedarf wieder über ein IP basiertes ACL Regelwerk am CBS steuern kannst. Der Cisco supportet sowas natürlich.
Die vom Kollegen @Benandi genannten "sticky" Macs wären eine andere Options erzwingen aber dann immer einen dedizierten Kupferport für diese Clients. Flexibles Umstecken ist damit nicht, oder nur mit Einschränkungen möglich.
Wenn du eh schon eine Radius basierte Mac Authentisierung mit dynamischer VLAN Zuweisung im WLAN benutzt ist es doch ein Leichtes dies auch auf die Kupferports zu erweitern.
andere Clients (Wifi) werden per MAC-Adresse dem entsprechenden VLAN zugeordnet.
Per Radius (MAB) und auf dem AP selber oder dem Switchport an dem der AP angeschlossen ist?Ich denke an "IP X darf nur an Gerät mit MAC-Adresse Y vergeben werden. Ist das der richtige Ansatz und wenn ja, wie kann ich das realisieren?
Das wäre ein Ansatz, erzwingt aber das du an den Kupferports auch eine Mac Adress basierte Port Authentisierung machst (MAB).So können nur Mac Adress registrierte Clients ins Netz und bekommen dann vom DHCP Server über diese Client spezifische Mac Adresse auch eine spezifische IP Adresse die du dann bei Bedarf wieder über ein IP basiertes ACL Regelwerk am CBS steuern kannst. Der Cisco supportet sowas natürlich.
Die vom Kollegen @Benandi genannten "sticky" Macs wären eine andere Options erzwingen aber dann immer einen dedizierten Kupferport für diese Clients. Flexibles Umstecken ist damit nicht, oder nur mit Einschränkungen möglich.
Wenn du eh schon eine Radius basierte Mac Authentisierung mit dynamischer VLAN Zuweisung im WLAN benutzt ist es doch ein Leichtes dies auch auf die Kupferports zu erweitern.
Wechsel auf IPv6 und du hast so viele IPs zur Verfügung, dass es dir schlicht egal ist.
So, erst mal Hallo an alle. Ich wollte nicht unhöflich sein.
Danke für die zahlreichen Antworten!
Ich erzähle noch mal kurz was zum Kontext: Es geht um das Heimnetzwerk in unserem Haus. Alle Clients hängen entweder per Kabel direkt am CBS350 oder über einen der 5 im Haus verteilten Accesspoints (Mischung aus WAX214 und WAX610 von Netgear), die wiederum am CBS hängen. Alle Geräte sind unter unserer Kontrolle außer den Geräten, die sich über das Gästenetzwerk anmelden. Das Gästenetzwerk (WLAN, eigene SSID) wird durch ein eigenes VLAN definiert, wobei kein Routing zwischen Gäste-VLAN und anderen VLANs erlaubt wird. Das Routing übernimmt ein RV340 von Cisco.
Ich denke, mir ist inzwischen klar geworden, dass die Sorge vor "unautorisierter" Verwendung von IP-Adressen wahrscheinlich nicht begründet ist.
Gibt es - nach den genannten Punkten - überhaupt einen Fall, wegen dem ich mir sorgen machen müsste, dass IP-Konflikte von dritten (gewollt oder ungewollt) provoziert werden?
Grüße
Danke für die zahlreichen Antworten!
Ich erzähle noch mal kurz was zum Kontext: Es geht um das Heimnetzwerk in unserem Haus. Alle Clients hängen entweder per Kabel direkt am CBS350 oder über einen der 5 im Haus verteilten Accesspoints (Mischung aus WAX214 und WAX610 von Netgear), die wiederum am CBS hängen. Alle Geräte sind unter unserer Kontrolle außer den Geräten, die sich über das Gästenetzwerk anmelden. Das Gästenetzwerk (WLAN, eigene SSID) wird durch ein eigenes VLAN definiert, wobei kein Routing zwischen Gäste-VLAN und anderen VLANs erlaubt wird. Das Routing übernimmt ein RV340 von Cisco.
Ich denke, mir ist inzwischen klar geworden, dass die Sorge vor "unautorisierter" Verwendung von IP-Adressen wahrscheinlich nicht begründet ist.
- Wenn man per Wifi ins Netzwerk möchte, muss man die Zugangsdaten kennen
- Kontrollierte Geräte oder Gäste, wobei mir im Gästenetzwerk erst mal "egal" ist, ob es da Konflikte gibt.
- Wenn man per Kabel am Netzerk angeschlossen ist, muss man eine bekannte MAC-Adresse vorweisen
- Kontrollierte Geräte
Gibt es - nach den genannten Punkten - überhaupt einen Fall, wegen dem ich mir sorgen machen müsste, dass IP-Konflikte von dritten (gewollt oder ungewollt) provoziert werden?
Grüße
Hey @aqui,
Radius habe ich nicht im Einsatz. Ich wollte schon einen ellenlangen Post dazu verfassen, was mich bei dem Thema umtreibt, aber ich lasse das der Einfachheit halber an der Stelle erst mal.
Die Zuordnung zum VLAN passiert auf dem Switch. Man kann im CBS350 im "VLAN Management" Gruppen von MAC-Adressen definieren. Ich habe für jedes VLAN eine Gruppe definiert, der die jeweiligen MAC-Adressen zugeordnet sind. Jede Gruppe wiederum wird mit ihrem entsprechenden VLAN und einem Interface verknüpft, auf dem die Verknüpfung zwischen Gruppe und VLAN gilt. Das Interface / der Port muss dann im General Mode laufen, es müssen die auf dem Interface erlaubten VLANs definiert werden und Ingress Filtering aktiviert sein.
So können nur Mac Adress registrierte Clients ins Netz und bekommen dann vom DHCP Server über diese Client spezifische Mac Adresse auch eine spezifische IP Adresse die du dann bei Bedarf wieder über ein IP basiertes ACL Regelwerk am CBS steuern kannst. Der Cisco supportet sowas natürlich.
Ich habe tatsächlich entgegen meiner ursprünglichen Behauptung bereits MAC basierte Zugriffskontrolle bei einigen kabelgebundenen Clients. Das Verfahren ist das Selbe, wie ich deine erste Frage beantwortet habe. Ich habe allerdings noch ein paar Ports die reine Access-Ports sind, wo noch kein Ingress-Filtering greift. Bei denen denke ich grade darüber nach, sie auch auf MAC-basierte Zugriffskontrolle umzustellen.
Die vom Kollegen @Benandi genannten "sticky" Macs wären eine andere Options erzwingen aber dann immer einen dedizierten Kupferport für diese Clients. Flexibles Umstecken ist damit nicht, oder nur mit Einschränkungen möglich.
Wenn du eh schon eine Radius basierte Mac Authentisierung mit dynamischer VLAN Zuweisung im WLAN benutzt ist es doch ein Leichtes dies auch auf die Kupferports zu erweitern.
Ich habe leider den Unterschied zwischen dem von mir genannten Verfahren "Ingress-Filtering" und dem von dir genannten Verfahren Radius mit MAB noch nicht verstanden. Wo liegt da der Unterschied? (Abgesehen davon, dass ich bei Radius eine dedizierte Maschine bräuchte und Ingress-Filtering im CBS schon eingebaut ist)
andere Clients (Wifi) werden per MAC-Adresse dem entsprechenden VLAN zugeordnet.
Per Radius (MAB) und auf dem AP selber oder dem Switchport an dem der AP angeschlossen ist?Die Zuordnung zum VLAN passiert auf dem Switch. Man kann im CBS350 im "VLAN Management" Gruppen von MAC-Adressen definieren. Ich habe für jedes VLAN eine Gruppe definiert, der die jeweiligen MAC-Adressen zugeordnet sind. Jede Gruppe wiederum wird mit ihrem entsprechenden VLAN und einem Interface verknüpft, auf dem die Verknüpfung zwischen Gruppe und VLAN gilt. Das Interface / der Port muss dann im General Mode laufen, es müssen die auf dem Interface erlaubten VLANs definiert werden und Ingress Filtering aktiviert sein.
Ich denke an "IP X darf nur an Gerät mit MAC-Adresse Y vergeben werden. Ist das der richtige Ansatz und wenn ja, wie kann ich das realisieren?
Das wäre ein Ansatz, erzwingt aber das du an den Kupferports auch eine Mac Adress basierte Port Authentisierung machst (MAB).So können nur Mac Adress registrierte Clients ins Netz und bekommen dann vom DHCP Server über diese Client spezifische Mac Adresse auch eine spezifische IP Adresse die du dann bei Bedarf wieder über ein IP basiertes ACL Regelwerk am CBS steuern kannst. Der Cisco supportet sowas natürlich.
Die vom Kollegen @Benandi genannten "sticky" Macs wären eine andere Options erzwingen aber dann immer einen dedizierten Kupferport für diese Clients. Flexibles Umstecken ist damit nicht, oder nur mit Einschränkungen möglich.
Wenn du eh schon eine Radius basierte Mac Authentisierung mit dynamischer VLAN Zuweisung im WLAN benutzt ist es doch ein Leichtes dies auch auf die Kupferports zu erweitern.
Ich habe leider den Unterschied zwischen dem von mir genannten Verfahren "Ingress-Filtering" und dem von dir genannten Verfahren Radius mit MAB noch nicht verstanden. Wo liegt da der Unterschied? (Abgesehen davon, dass ich bei Radius eine dedizierte Maschine bräuchte und Ingress-Filtering im CBS schon eingebaut ist)
Radius habe ich nicht im Einsatz.
Dann war aber deine Beschreibung (Zitat) "...andere Clients (Wifi) werden per MAC-Adresse dem entsprechenden VLAN zugeordnet." schlicht falsch oder zumindestens irreführend, denn das ist ein Feature was in der Regel MAB über einen Radius am AP macht. Aber nundenn...Der Unterschied ist das die Radius Option eine zentrale Verwaltung ALLER Benutzer egal ob MAB (Mac Adresse), 802.1x usw. anstatt einer pro User pro Port Frickelei mit dem Switchsetup. Wie gesagt in einem Heimnetz sicher noch tolerabel bei einem einzigen Switch und 5 Usern. Bei 50 Usern und 5 Switches sieht sowas aber schnell ganz anders aus.
Abgesehen davon, dass ich bei Radius eine dedizierte Maschine bräuchte
Nein, das ist Unsinn, denn z.B. alle Switches von Mikrotik bringen einen onboard Radius Server mit mit dem sowas auch in einem Gerät im Handumdrehen erledigt ist. Siehe hier und auch hier.Alles in allem hast du aber sehr Vieles sehr richtig gemacht in Bezug auf die Security. Da gehörst du sicher zu den 5% die überhaupt auf so etwas achten. Insofern musst du dir also sicher nicht allzuviele Sorgen machen bei einem Heimnetz.
Danke Euch allen für den Input und die Denkanstöße!
Danke @aqui, dass Du mich darin bekräftigt hast, dass ich wahrscheinlich schon ganz gut aufgestellt bin. Besser geht immer, aber wie steht der Nutzen in Relation zum Aufwand. Da kann ich die Zeit wahrscheinlich an anderer Stelle besser investieren. Ich werde aber noch schauen, ob ich das Thema Radius nicht doch noch gemeistert bekomme, um mir langfristig hier das Leben zu erleichtern.
Wie auch immer: Vielen Dank noch mal für Euren Input!
Danke @aqui, dass Du mich darin bekräftigt hast, dass ich wahrscheinlich schon ganz gut aufgestellt bin. Besser geht immer, aber wie steht der Nutzen in Relation zum Aufwand. Da kann ich die Zeit wahrscheinlich an anderer Stelle besser investieren. Ich werde aber noch schauen, ob ich das Thema Radius nicht doch noch gemeistert bekomme, um mir langfristig hier das Leben zu erleichtern.
Wie auch immer: Vielen Dank noch mal für Euren Input!
1ob ich das Thema Radius nicht doch noch gemeistert bekomme, um mir langfristig hier das Leben zu erleichtern.
Mit den hiesigen Tutorials zu der Thematik ist das ja dann ein Kinderspiel! 😉
Danke! Wenn ich soweit bin, schaue ich was ich hier finde, bzw. hoffe auf Eure kompetente Unterstützung 😅
