Step-by-Step-Anleitung: Umstrukturierung eines 172.16.x.y/16 Netzes in viele VLANs mit 172.16.x.0/24
Viele SchuladministratorInnen (zumindest in Österreich) haben ihr Netz einst nach der Step-by-Step-Anleitung von Koll. Georg Steingruber (dem dafür aufrichtiger Dank gebührt) konfiguriert…(hier die Links dazu)
Damit haben sie ein [riesiges] Netz mit der Adressierung 172.16.x.y mit der Subnetzmaske 255.255.0.0
Nachdem die meisten Schulen in der Zwischenzeit auch Notebookklassen haben (in der BHAK Neusiedl am See gibt es z. B. zwischen 7 und 9 Klassen mit je ca. 25 Notebooks), ist es keine Seltenheit, wenn im Schulnetz an die 350 PCs (Schulungsraum u Notebooks) “unterwegs” sind.
Wenn KEINE Umstellung in VLANs erfolgt, dann kann dies folgende Probleme nach sich ziehen:
- enormer Traffic durch Broadcasting
- falls es zu “Sabotage-Akten” kommt (ich hatte z. B. einmal Alufolie in einer Netzwerkdose…), dann steht das gesamte Netzwerk!!!
- bei Schularbeiten / Matura in den Schulungsräumen ist es NICHT zu verhindern, dass SchülerInnen auf Netzwerkfreigaben ihres Notebook zugreifen (in der sie die Lösung austauschen…)
- Der Netzwerk-Administrator hat KEINE CHANCE gegen den einfachsten aller Sabotageakte:
Ein Tu-Nicht-Gut bringt einen WLAN-Router von zu Hause mit und hängt ihn mit einer LAN-Schnittstelle in das Schulnetzwerk
[ was passiert dadurch:
» jeder WLAN-Router hat einen DHCP - Server an Board;
» damit habt ihr nun 2 DHCP-Server in eurem Netz;
» es hängt vom Zufall ab, an welchen Server die Clients den DHCP-Request senden;
» der WLAN-Router lässt sich UNMÖGLICH bei einem einzigen Subnetz lokalisieren!!!
» der Administrator ist dem Agressor völlig ausgeliefert (klingt schiach, ist es auch
Und es gilt Wagners Weisheit #1: "Was nicht lange gut gehen kann, wird es auch nicht!"
Das gute daran:
Eine Aufteilung in Subnetze bzw. die Einführung von VLANs ist auch in einem bestehenden Infrastruktur möglich!!!
Was es zu beachten gilt:
die IP-Adressen von Domänencontrollern dürfen unter keinen Umständen geändert werden!!! (ok, es ist zwar prinzipiell schon möglich, aber nicht sonderlich ratsam...)
Jedoch: die Subnetzmasken können von ALLEN Clients im Netzwerk OHNE PROBLEME jederzeit geändert werden!!!
Dadurch ergibt sich folgende Vorgangsweise für die Umstellung:
- Alle Artikel dieser Serie durcharbeiten, einen Netzwerkplan skizzieren
- die Layer-2-Switches umkonfigurieren, dh, die jeweiligen VLAN-IDs eintragen und Ports zuweisen
- den Layer-3-Switch konfigurieren, dh, die VLAN-Interfaces definieren; Routen eintragen; DHCP-Helper (= DHCP-Relay) eintragen
- alle ACLs konfigurieren
- das System mit Clients, die statische Adressen haben (aus dem jeweiligen VLAN natürlich mit SN 255.255.255.0) ausgiebig testen
- die Subnetzmasken ALLER Server auf 255.255.255.0 ändern (mit den DCs beginnen, damit diese wieder replizieren können)
- die Replizierung der DCs kontrollieren (zb mit replmon)
- DHCP-Scope am bisherigen DHCP-Server in eine .txt exportieren [172.16.0.1 = IP des DHCP-Servers]
netsh dhcp server 172.16.0.1 dump >DHCPdump.txt - diesen (alten) Scope löschen, neue Scopes für jedes VLAN neu erstellen; ACHTUNG auf die Einstellung bei Router (= default Gateway = Adresse des VLAN-Interfaces)
- aus der exportierten DHCPdump.txt alles ausser der Reservierungen löschen;
in die neuen Scopes importieren mit dem Befehl
netsh exec DHCPdump.txt - die default Route am Layer-3-Switch für den Internetzugang eintragen
- die statische Route am ISA-Server eintragen
einige dieser Schritte lassen sich in aller Ruhe vorbereiten:
- Layer-3-Switch konfigurieren;
- DHCP-Scopes können auf einem (virtualisierten) Testserver eingerichtet und dann exportiert werden
dadurch bleibt für die eigentliche Umstellung nur noch:
Layer-2-Switches umkonfigurieren
DHCP-Scopes importieren
Subnetzmasken der Server umschreiben
ISA-Server umkonfigurieren
mein Zeitaufwand für die eigentliche Umstellung in der BHAK Neusiedl (10 Server, 24 Layer-2-Switches): 8h
Zusammenfassung:
Je eher man umstellt, desto früher kann man Angriffen gelassener entgegen sehen…
Alles hat ein Ende, so auch diese Serie:
Im letzten Artikel beschäftige ich mich noch damit, wie man die Umsetzung der Strukturierung in VLANs nun sehr effektiv und einfach kontrollieren kann

[5 Bewertung, Durchschnitt: 4,00]
hallo,
ein paar Anmerkungen zur Absicherung von DHCP auf Switches:
das Problem mit dem fremden DHCP-Server (rogue DHCP) lässt sich mit DHCP-Snooping vermeiden.
Über DHCP-Snooping wird auf jedem Switch definiert über welchen Port der DHCP-Server erreichbar ist (bei einem Layer-2 Switch ist das in der Regel der Uplink-Port). Der Switch-Port des rogue-DHCP wird heruntergefahren.
Die gängigen professionellen Switche beherrschen das Feature dhcp snooping.
Auch ohne DHCP-Snooping würde sich so ein Tu-nicht-Gut mit dem rogue DHCP manuell lokalisieren lassen. Dazu verwendet man die ARP-Table und MAC-Adress-Table (bzw. Switch-Port-Mapper-Tools).
D.h. man wäre dem “Angreifer” mit dem WLAN-Router nicht ausgeliefert.
Auch nach VLAN-Einführung macht DHCP-Snooping natürlich Sinn. Durch die VLANs wird das Problem lediglich etwas entschärft weil die Anzahl der betroffenen Clients kleiner wird.
Gruss
Matthias