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
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