VLAN – Teil 5: Access Lists


sehr verwirrender ArtikelNaja, ganz OKbrauchbar für Checker...guter Artikelsehr guter Artikel - Danke [3 Bewertung, Durchschnitt: 5,00]

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

  1. 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
  2. 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]
  3. 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!)
  4. 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
  5. 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
  6. 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…)
     

     

  7. sonstige hilfreiche Befehle
    Policy wieder vom VLAN entfernen:
    undo qos vlan-policy VLAN 117 inbound

    Anzeige vorhandener ACL:
    display acl all
    display traffic behavior user-defined
    display qos policy user-defined
    display traffic classifier user-defined

    falls 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


This entry was posted in Netzwerk, VBScript, VLAN. Bookmark the permalink.

6 Responses to VLAN – Teil 5: Access Lists

  1. Hubert says:

    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?

    • Edi Pfisterer says:

      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

      • Jehrek says:

        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?

        • Edi Pfisterer says:

          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…

  2. Stone says:

    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.

Hinterlasse eine Antwort