Step-by-Step-Anleitung: Einrichtung von Access Lists (ACL) zur “Isolierung” der VLANs
Nachdem wir in den Artikeln 1 bis 4 erfolgreich VLANs konfiguriert haben, wollen wir nun voneinander isolieren – dies ist ja schließlich Zweck der Umstellung auf VLANs.
(Ohne Access Lists [ACL] sind VLANs nur der halbe Spass – es wird lediglich das Broadcasting stark reduziert, was zu einem Performancegewinn führt;
aus Sicherheitstechnischem Blickwinkel haben wir aber ohne ACLs noch nichts erreicht!
Für Access Lists gilt: die beiden Zauberwörter lauten: PERMIT und DENY
generell kann von Folgendem ausgegangen werden:
1.) man definiert den ungewünschen Traffic in der ACL mit DENY
2.) man definiert den erwünschten Traffic in der ACL mit PERMIT
3.) es gilt immer der first Hit, danach wird die ACL nicht mehr weiter abgearbeitet ! Deshalb muss der DENY Traffic immer zuerst kommen !
Da die Hersteller hier doch sehr unterschiedliche Syntax verwenden, wird man ohne ein Studium des Manuals nicht herum kommen.
Ich kann hier lediglich ein Beispiel geben, das zum Grundverständnis beitragen sollte. Wieder – wie in der gesamten Artikelserie – behandle ich das Thema anhand eines 3COM 4500G
Anlegen einer Access List (ACL) – Grundüberlegungen:
Bevor man sich dem Anlegen von ACL widmet, müssen folgende Überlegungen angestellt werden:
- in welchen VLANs sind Resourcen, auf die von anderen VLANs aus zugegriffen werden muss?
In den meisten Fällen werden nur folgende VLANs “offen” sein müssen:
- VLAN, in dem die Server (Domänencontroller, etc) sind
- VLAN, in dem die Administratoren sind (damit diese Remote auf die Clients zugreifen können)
- VLAN, in dem der Zugang zum Internet Service Provider angesiedelt ist
Anlegen einer ACL – die Syntax
Üblicherweise werden ACLs über das CLI (Command Line Interface) definiert.
Nachfolgend ein Codebeispiel, das zu unserer Grafik aus Teil 3 passt:
Annahmen:
Admins “sitzen” im VLAN 1, DCs im VLAN 101
ACL für das VLAN 102
rule 1 deny ip source any destination 172.16.3.0 0.0.0.255
rule 2 deny ip source any destination 172.16.4.0 0.0.0.255
[rule 3 permit ip source any destination any << NICHT noetig beim 4500G, da dies per default passiert]
ACL für das VLAN 103
rule 1 deny ip source any destination 172.16.2.0 0.0.0.255
rule 2 deny ip source any destination 172.16.4.0 0.0.0.255
[rule 3 permit ip source any destination any << NICHT noetig beim 4500G, da dies per default passiert]
ACL für das VLAN 104
rule 1 deny ip source any destination 172.16.2.0 0.0.0.255
rule 2 deny ip source any destination 172.16.3.0 0.0.0.255
[rule 3 permit ip source any destination any << NICHT noetig beim 4500G, da dies per default passiert]
für VLAN 101 bzw. VLAN 1 ist KEINE ACL beim 4500G nötig, da hier nur die
rule 1 permit ip source any destination any << NICHT noetig beim 4500G, da dies per default passiert]
einzutragen wäre, diese wird beim 4500G aber per default als vorhandene (letzte) Rule ergänzt!
Nur zur Veranschaulichung, wie unterschiedlich hier die einzelne Syntax sein kann:
Für Cisco würde eine ACL wie folgt aussehen:
access-list vlan102u103 deny ip 172.16.2.0 0.0.0.255 172.16.3.0 0.0.0.255
access-list vlan102u103 deny ip 172.16.2.0 0.0.0.255 172.16.4.0 0.0.0.255
access-list vlan102u103 permit ip 172.16.2.0 0.0.0.255 any
bzw. mit der umgekehrten Idee (ausgewählte erlauben, rest verbieten):
access-list vlan101u1only permit ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list vlan101u1only permit ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255
access-list vlan101u1only deny ip 172.16.2.0 0.0.0.255 any
daher, ich wiederhole mich: Um das lesen des Manuals wird man nicht herumkommen!!!
Nun müssen diese ACL nocht den einzelnen VLAN zugewiesen werden
hier unterscheiden sich die Hersteller nun sehr deutlich voneinander! Daher:
alles Folgende gilt [getestet] NUR für 3COM (HP) 4500G 48-Port (3CR17762-91) [PWR] - vorausgesetzt, die aktuellste Firmware ist eingespielt!!!
- Time-Range definieren
auch wenn die ACL rund um die Uhr gelten, verlangt dieser Switch nach der Definition eines Time-Ranges
time-range fuer-immer from 15:00 2000/1/28 to 15:00 2090/1/28 - eine ACL – Liste anlegen
diese MUSS eine Advanced IPv4 ACL mit einer ID zwischen 3000 und 3999 sein!
acl number 3002
rule 1 deny ip source any destination 172.16.3.0 0.0.0.255
rule 2 deny ip source any destination 172.16.4.0 0.0.0.255
quit
acl number 3003
rule 1 deny ip source any destination 172.16.2.0 0.0.0.255
rule 2 deny ip source any destination 172.16.4.0 0.0.0.255
quit
acl number 3004
rule 1 deny ip source any destination 172.16.2.0 0.0.0.255
rule 2 deny ip source any destination 172.16.3.0 0.0.0.255
quit
[display acl 3001 << zeigt die Einstellungen an]
- ein Verhalten festlegen, was mit dem gefilterten Traffic passieren soll
traffic behavior deny
filter deny
quit
(erst dadurch wird der Traffic, der als “deny” in der ACL gekennzeichnet ist, auch gefiltert!) - einen Classifier festlegen und diesen mit den ACL “zusammenhängen”
traffic classifier denyVLAN2
if-match acl 3002
quit
traffic classifier denyVLAN3
if-match acl 3003
quit
traffic classifier denyVLAN4
if-match acl 3004
quit
Anmerkung:
denyVLAN2 verhindert über ACL 3002 Traffic mit 172.16.2.0/24
denyVLAN3 verhindert über ACL 3003 Traffic mit 172.16.3.0/24
denyVLAN4 verhindert über ACL 3004 Traffic mit 172.16.4.0/24 - eine Policy definieren und diese mit dem classifier und dem behavior zusammenhängen
qos policy pol2
classifier denyVLAN2 behavior deny
quit
qos policy pol3
classifier denyVLAN3 behavior deny
quit
qos policy pol4
classifier denyVLAN4 behavior deny
quit - die Policy den einzelnen VLAN zuweisen
qos vlan-policy pol2 VLAN 102 inbound
qos vlan-policy pol3 VLAN 103 inbound
qos vlan-policy pol4 VLAN 104 inbounddamit wären wir eigentlich schon FERTIG
was nun noch folgt, ist ein Auszug aus der Befehlsreferenz
(damit ich ihn selbst nicht vergesse…)
- sonstige hilfreiche Befehle
Policy wieder vom VLAN entfernen:
undo qos vlan-policy VLAN 117 inboundAnzeige vorhandener ACL:
display acl all
display traffic behavior user-defined
display qos policy user-defined
display traffic classifier user-definedfalls ACLs gelöscht werden sollen, muss folgende Befehlsreihenfolge eingehalten werden:
undo qos policy [name der Policy]
undo traffic classifier [name des Classifiers]
undo traffic behavior [name des Behaviors]
undo acl number [ACL-Nummer]Anzeige des Time-Range:
[4500G]display time-range all
Current time is 14:52:42 5/6/2000 Saturday
Time-range : fuerimmer ( Active )
from 15:00 1/28/2000 to 15:00 1/28/2090
Zusammenfassung:
durch die Arbeiten aus diesem Kapitel haben wir es geschafft, dass nun nur noch Traffic aus und in das ServerVLAN bzw aus und in das Admin-VLAN möglich. Traffic zwischen den übrigen VLANs ist NICHT mehr möglich!!!
[EXKURS]
In einer Schule kommt man mit 5 VLANs nicht natürlich nicht aus!
Ich verwende in der BHAK Neusiedl am See beispielsweise 25 VLANs.
Ausgehend von 2 “offenen” VLANS (für die Server und Admins) bedeutet dies:
23 * 22 / 2 – 3*23 = 184 ACL-Rules
diese manuell per CLI (telnet) einzugeben, war mir zuviel Arbeit!
also habe ich mir ein 2 Scripts geschrieben:
Tool #1
- verbindet Euch mit dem Switch per Telnet auf die CLI
- zeigt Euch die bestehenden ACLs an
- fragt nach einer kurzen Pause, für wieviel VLANs eine ACL erstellt werden soll
- legt anschließend mit ACL Number 300n beginnend die jeweiligen ACLs an (es bleibt die
deny-Regel für das jeweilige Netz ausgespart)
- zeigt Euch abschließend alle vorhandenen ACLs an
Achtung: bestehende ACLs mit der selben Nummer werden überschrieben – daher die Anzeige aller bestehenden ACLs zu Beginn
daher: genau prüfen, bevor ihr die Anzahl der anzulegenden ACLs angebt
Die Auswahl der Schaltfläche “abbruch” legt KEINE ACLs an, dh, der Switch bleibt unverändert…
»download: 4500G_ACL_per_telnet_am_Switch_anlegen.vbs
set oShell = CreateObject("WScript.Shell") oShell.run "cmd.exe" WScript.Sleep 1000 ' ' ' oShell.SendKeys"telnet 172.16.19.254" oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"admin" oShell.SendKeys("{Enter}") WScript.Sleep 1000 ' ' ' oShell.SendKeys"password" 'HIER MUESST IHR EUER ADMIN-PASSWORT EINTRAGEN oShell.SendKeys("{Enter}") WScript.Sleep 500 oShell.SendKeys"system-view" oShell.SendKeys("{Enter}") WScript.Sleep 500 ' ' ' oShell.SendKeys"display acl all" oShell.SendKeys("{Enter}") WScript.Sleep 5000 Anzahl_der_VLANs=InputBox ("ACL für wie viele VLANs?","Input","VLAN")*1 'Annahme: Die Server haben 172.16.0.0/24 er Adressen AdminNetz = 19 'Annahme: Die Admins sitzen in 172.16.19.0/24 er Netz Set fs = CreateObject("Scripting.FileSystemObject") for k = 1 to Anzahl_der_VLANs oShell.SendKeys"acl number " & 3000+k oShell.SendKeys("{Enter}") WScript.Sleep 500 n=0 for i = 1 to Anzahl_der_VLANs if i = k then i=i+1 if i = AdminNetz then i=i+1 if i <= Anzahl_der_VLANs Then oShell.SendKeys"rule " & n & " deny ip source any destination 172.16." & i & ".0 0.0.0.255" oShell.SendKeys("{Enter}") WScript.Sleep 500 end if n=n+1 next oShell.SendKeys"quit" oShell.SendKeys("{Enter}") WScript.Sleep 5000 Next oShell.SendKeys"display acl all" oShell.SendKeys("{Enter}") WScript.Sleep 500
Tool #2 wendet die ACLs auf die VLANs an:
Prämissen:
VLAN-ID und IP hängen wie folgt zusammen:
VLAN ID 10 –> 172.16.0.0/24
VLAN ID 11 –> 172.16.1.0/24
VLAN ID 12 –> 172.16.2.0/24
…
VLAN ID 19 –> 172.16.9.0/24
VLAN ID 110 –> 172.16.10.0/24
VLAN ID 111 –> 172.16.11.0/24
sprich: die erste Ziffer der VLAN ID ist Schall und Rauch, die restlichen Ziffern geben Aufschluss über das IP-Subnetz
Anmerkung: es wird KEINE ACL für VLAN ID 119 angewendet, weil dieses ja das Admin-Netz ist bzw. KEINE ACL für VLAN ID 10, da dort die Server stehen…
»download: 4500G_ACL_per_telnet_auf_VLAN_anwenden.vbs
set oShell = CreateObject("WScript.Shell") oShell.run "cmd.exe" WScript.Sleep 1000 ' ' ' oShell.SendKeys"telnet 172.16.19.254" oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"admin" oShell.SendKeys("{Enter}") WScript.Sleep 1000 ' ' ' oShell.SendKeys"Urobe" oShell.SendKeys("{Enter}") WScript.Sleep 500 oShell.SendKeys"system-view" oShell.SendKeys("{Enter}") WScript.Sleep 500 ' ' ' Anzahl_der_VLANs=InputBox ("ACL für wie viele VLANs?","Input","VLAN")*1 'Annahme: Die Server haben 172.16.0.0/24 er Adressen AdminNetz = 19 Set fs = CreateObject("Scripting.FileSystemObject") for k = 1 to Anzahl_der_VLANs if k <> AdminNetz then oShell.SendKeys"traffic classifier CL" & k oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"if-match acl " & 3000+k oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"quit" oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"qos policy p" & k oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"classifier CL" & k & " behavior deny" oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"quit" oShell.SendKeys("{Enter}") WScript.Sleep 1000 oShell.SendKeys"qos vlan-policy p" & k & " VLAN 1" & k & " inbound" oShell.SendKeys("{Enter}") oShell.SendKeys("{Enter}") oShell.SendKeys("{Enter}") oShell.SendKeys("{Enter}") WScript.Sleep 5000 end if Next
That’s it!
Im nächsten Artikel beschäftige ich mich damit, wie wir ins Internet kommen
Hallo,
nachdem ich in Teil 1-4 schon glaubte, den Sinn von VLANs endlich begriffen zu haben – nämlich den Netzwerkverkehr von und in die einzelnen Subnetze ohne viel Aufwand zu isolieren, da jedes Paket ja sowieso nur in die zugeordneten VLANs gelangt – verstehe ich den Zweck dieser ACLs nicht so ganz.
Wenn diese Beschränkung des Verkehrs jedoch NUR MIT solchen ACLs funktioniert, hat sich das Thema eigentlich schon erledigt.
Zumal ich nicht glaube, dass sich jemals ein normaler Mensch freiwillig antun sollte, überhaupt solche Regeln zu schreiben, wird das ganze noch lustiger, wenn ich nachträglich noch ein weiteres VLAN erzeugen will – denn dann muss ich ja sämtliche hunderte Regeln ändern (am besten noch auf 4 oder 5 Switchen), oder nicht?
Hallo Hubert,
grundsätzlich ist es so, dass der Traffic das jeweilige VLAN nicht verlassen kann…
Dadurch ist aber auch kein Zugriff auf das Internet möglich, auch ein gemeinsamer Server kann so nicht erreicht werden.
Wenn nun doch ein gemeinsamer Server bzw. Internetzugang gewährleistet sein soll, dann muss der Traffic “geroutet” werden.
Routing funktioniert (im Gegensatz zu VLANs) auf Layer3 im ISO/OSI-Modell…
Das schöne ist nun, dass durch das Anlegen eines Interfaces (= Gateway) für das jeweilige VLAN am Layer3-Switch automatisch auch eine Route für das jeweilige VLAN erstellt wird.
Der Nachteil dieser Automatisierung ist allerdings, dass nun auch wieder jeglicher Traffic zwischen den VLANs möglich ist (Anmerkung: das Broadcasting bleibt weiterhin innerhalb des jeweiligen VLANs).
Um nun Traffic zwischen den VLANs zu unterbinden, sodass eine Verbindung wirklich nur mehr von einem VLAN zu den Servern, den Admins und ins Internet möglich ist, braucht man diese ACLs.
Diese ACLs sind aber lediglich am Layer3-Switch anzulegen, wodurch sich der Arbeitsaufwand stark dezimiert.
Weiters braucht man – je nach Anzahl der VLANs – auch nicht allzuviele Regeln.
Je nach Hersteller reichen je VLAN meist 3 bis 4 Regeln:
DENY nach überall
permit zu den Servern
permit zu den Admins
permit ins Internet
Was das Nacharbeiten betrifft, würde ich bereits beim Anlagen der VLANs am Layer3-Switch großzügig planen (ich lege jeweils immer 10 VLANs mehr an), dann musst Du im Bedarfsfall nur noch am Layer2-Switch das VLAN anlegen und den Switchport ins VLAN konfigurieren…
Ich hoffe, ich habe etwas Licht in die Sache gebracht…
lg und gutes Gelingen
Edi
Verstehe ich nicht, in Teil 2 schreibt ihr doch, dass man mit Membership der VLANs Traffic routen kann… Wenn ich 4 VLANs anlege, und etwa der Port mit VLAN01 am Internet hängt, und VLAN03 die Server und VLAN04 die Bürorechner, und die Ports für Server und Büro Members ins VLAN01 setze, kommen die doch auch ins Internet oder nicht?
servus!
Artikel 2 befasst sich mit VLANs auf Layer2-Ebene im ISO/OSI Modell…
Damit Clients ohne Routing kommunizieren können, müssen sie aber im selben Subnetz sein… (zb alle Clients haben 10.0.x.y mit Subnetzmaske 255.255.0.0)
Nachdem “das Internet” aber nicht in Deinem Subnetz ist, brauchst du zwingend Routing…
(Layer3 ISO/OSI)
Und wenn jetzt ins Internet geroutet werden soll, aber NICHT in die Nachbarklasse/abteilung, musst Du dies durch AccessLists verhindern…
Hoffe, etwas Licht in die Sache gebracht zu haben…
Falls Dir geholfen ist: Benutz doch den Spenden-Button…
Hallo,
würde es nicht das Problem lösen einfach keine Routen für die einzelnen VLAN (außer DC etc) einzutragen. Der Traffic würde ja dann an die Firewall geroutet und dort verworfen ?
(Nur als Überlegung, Sinn macht das natürlich keinen.
Wäre natürlich auch eine Idee… Zwecks Feinjustierung würde ich aber dennoch zum Einsatz von ACLs tendieren…