17.07.2017, aktualisiert um 16:03:15 Uhr

10360

Switch ACL-Konfiguration

Hallo Leute,

ich habe eine kleine Frage zur Konfiguration von ACL's auf unserem Switch. Unsere Infrastruktur ist in verschiedene Netzwerke (VLAN's) aufgeteilt. Darunter befinden sich fünf Abteilungs- und drei Servernetzwerke sowie diverse andere wie z.B. Drucker, Sonstiges, WLAN etc.

Die VLAN's werden vom zentralen Switch auf die Access-Switche verteilt. Das Routing wird auch über das zentrale Switch abgefackelt. Alle Netzwerke sind mit 172.16.VLANID.X/24 definiert (Z.b. 172.16.218.0/24; 172.16.219.0/24 etc. & das dritte Oktett ist identisch mit der VLAN-ID)

Bisher wurden keine ACL's definiert und alle Netzwerke konnten sich ohne Probleme erreichen - Sicherheitstechnisch ist das natürlich ziemlich "doof".

Daher habe ich folgende ACL definiert und dem VLAN218 mit dem Subnetz 172.16.218.0/24 zugeordnet:

ip access-list extended "VLAN218"  
permit ip 172.16.218.0 0.0.0.255 172.16.107.100 0.0.0.255
permit ip 172.16.107.100 0.0.0.255 172.16.218.0 0.0.0.255
permit ip 172.16.218.0 0.0.0.255 172.16.107.101 0.0.0.255
permit ip 172.16.107.101 0.0.0.255 172.16.218.0 0.0.0.255
     
permit ip 172.16.218.0 0.0.0.255 172.16.201.0 0.0.0.255
permit ip 172.16.201.0 0.0.0.255 172.16.218.0 0.0.0.255
     
permit ip 172.16.218.0 0.0.0.255 172.16.202.0 0.0.0.255
permit ip 172.16.202.0 0.0.0.255 172.16.218.0 0.0.0.255
     
permit ip 172.16.218.0 0.0.0.255 172.16.203.0 0.0.0.255
permit ip 172.16.203.0 0.0.0.255 172.16.218.0 0.0.0.255
     
permit ip 172.16.218.0 0.0.0.255 172.16.109.0 0.0.0.255
permit ip 172.16.109.0 0.0.0.255 172.16.218.0 0.0.0.255
     
deny ip 172.16.218.0 0.0.0.255 172.16.0.0 0.0.255.255
     
permit ip 172.16.218.0 0.0.0.255 0.0.0.0 255.255.255.255
permit ip 0.0.0.0 255.255.255.255 172.16.218.0 0.0.0.255
   exit

Erläuterung:

Zu Regel 10-13 macht den Weg für die Administrationsnotebooks frei (Jeweils Hin- und Rückweg da stateless).
Zu Regel 100-401 definierte die drei Servernetzwerke die uneingeschränkt geroutet werden sollen (Jeweils Hin- und Rückweg da stateless).
Zu Regel 600+601 soll den Internetverkehr regeln - alles was oben nicht passt soll (ins Internet) geroutet werden (Jeweils Hin- und Rückweg da stateless) .
Zu Regel 500: Wie oben erwähnt sind alle anderen Netzwerkwerke ebenfalls mit 172.16.VLANID.X/24-Adressierung versehen. Dieses Schema werde ich auch bei zukünftigen Netzwerken beibehalten. Daher wollte ich mit dieser Regel bewirken, dass alle 172.16er Netzwerke, die in den vorhergehenden Regeln nicht beachtet werden, blockiert werden.

Leider scheint es so, also ob Regel 500 nicht funktioniert und alles durch die letzten beiden zugelassen wird - jedenfalls ist die Kommunikation zwischen den Netzen weiter uneingeschränkt möglich.

Wie definiere ich solch eine Regel oder muss ich jedes Netz explizit angeben??

P.S.: Ist ein Procurve 5412zl

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 343629

Url: https://administrator.de/forum/switch-acl-konfiguration-343629.html

Ausgedruckt am: 04.04.2025 um 09:04 Uhr

9 Kommentare

Neuester Kommentar

Grundsätzlich:

1) Die letzte Zeile einer ACL ist immer >deny any any<, oben drüber gibst du frei, was du benötigst
2) Bei HP musst du alles explizit angeben, also jeweils beide Richtungen (mein letzter Stand)

Dennoch sind das Problem, wieso es trotz Deny funktioniert, deine Wildcards.

Beispiel:

Eintrag 10:

10 permit ip 172.16.218.0 0.0.0.255 172.16.107.100 0.0.0.255

Mit der IP 172.16.107.100 meinst du sicherlich einen Host, und kein Netz. Mit der Wildcard 0.0.0.255 sagst du der ACL aber 24er-Netzwerk und nicht Host.
Das heißt, du sagst mit dem ACE 172.16.107.0/24 und nicht 172.16.107.100/32

Das bedeutet, dass du nicht nur IP .100 und .101 aus VLAN 107 aufmachst, sondern das komplette VLAN 107.

-> Wildcard der Host-IPs nach 0.0.0.0 ändern

10 permit ip 172.16.218.0 0.0.0.255 172.16.107.100 0.0.0.0

Zur Hilfe: http://www.subnet-calculator.com/wildcard.php

Zitat von @chgorges:

Grundsätzlich:

1) Die letzte Zeile einer ACL ist immer >deny any any<, oben drüber gibst du frei, was du benötigst

Deshalb habe ich ja auf Pos. 600 & 601 alles sonstige Freigegeben.

Mit der IP 172.16.107.100 meinst du sicherlich einen Host, und kein Netz. Mit der Wildcard 0.0.0.255 sagst du der ACL aber 24er-Netzwerk und nicht Host.

Korrekt meine den Host damit. War mein Fehler...die Wildcard der Regel 10-13 wurde geändert.

Trotzdem bleibt das Problem, dass die VLAN's untereinander weiterhin uneingeschränkt kommunizieren können. Testweise habe ich ein zweites VLAN (ID 219 mit dem Netz 172.16.219.0/24) mit einer ACL versehen. Die ACL aus VLAN219 ist identisch mit der aus VLAN218 (natürlich wurden die jeweiligen Netze von .218.0/24 auf .219.0/24 geändert). Laut Regelwerk sollte die Kommunikation zwischen 172.16.218.0 und 172.16.219.0 durch Regel 500 geblockt werden - wird sie aber nicht, die Kommunikation ist immer noch uneingeschränkt möglich - irgendwas mache ich falsch...

Und ganz banal, die ACLs sind auch korrekt auf die VLANs angewendet?

https://ictschule.com/2014/01/03/access-control-lists-acl-auf-hp-switch/ ganz unten.

Jop genau so habe ich die ACLs an die VLANs gebunden.

Die ACL's sind Outbound angewendet.

Die konfig bestätigt auch die korrekte Anwendung...

Macht es eigentlich einen Unterschied wenn ich bei der ACE-Definition keine Wildcard sondern CIDR-Masken angebe?

Ich habe die ACE's so definiert:

100 permit ip 172.16.218.0/24 172.16.201.0/24

Das Switch hat die Masken automatisch so umgewandelt...sollte doch trotzdem passen?!

Ich denke, dass du besser fährst, wenn du für jedes VLAN eine eigene ACL anlegst, anstatt eine Große.
Damit kannst du dann auch besser differenzieren, was wohin darf und was nicht.

wenn du für jedes VLAN eine eigene ACL anlegst,

Anders geht das auch gar nicht ! Die ACLs greifen immer nur am L3 Interface also muss auch pro L3 Interface dann eine ACL hin.
Die ACL ist grob gesehen syntaktisch korrekt hat aber ein paar gravierende Fehler in den Statements !
Bedenke das eine ACL bei Billigswitches immer nur inbound greift, also für Pakete die vom "Draht" in den Switch bzw. sein L3 Interface reinlaufen.
Deshalb sind die folgenden Filterstatements in der Liste Unsinn:

11 permit ip 172.16.107.100 0.0.0.255 172.16.218.0 0.0.0.255 Überflüssig, denn im 218er VLAN kann es ja nach deine durchaus sinnvollen IP Adressierung niemals Pakete mit einer Absender IP 172.16.107.x geben. D.h. diese Regel ist sinnfrei und wird nie greifen.
13 permit ip 172.16.107.101 0.0.0.255 172.16.218.0 0.0.0.255 Dto. Gleicher Unsinn wie "11"
Das wiederholt sich jetzt in den Regeln 101, 201, 301, 401 und 601 !! Alles überflüssig da sie niemals greifen.
Ganz besonders unsinnig ist die Regel 601 die ALLES auf das eigene Segment zulässt. Falscher und unlogischer als DAS kann man eine Regel gar nicht mehr definieren ! Überleg selber mal wie unsinnig das ist, denn eigene Pakete laufen ja niemals über den L3 Switch sondern verbleiben im Switch selber da rein Layer 2.

Zeigt eigentlich das du völligen Blindflug machst beim Thema ACLs

Beachte immer die Grundregeln:

Filter geht nur inbound !
"First match wins"... d.h. nach einem Regelhit wird der Rest der ACL NICHT mehr weiter abgearbeitet ! Reihenfolge zählt also auch !

Zitat von @aqui:

wenn du für jedes VLAN eine eigene ACL anlegst,

Ist so geplant...

Deshalb sind die folgenden Filterstatements in der Liste Unsinn:

11 permit ip 172.16.107.100 0.0.0.255 172.16.218.0 0.0.0.255 Überflüssig, denn im 218er VLAN kann es ja nach deine durchaus sinnvollen IP Adressierung niemals Pakete mit einer Absender IP 172.16.107.x geben. D.h. diese Regel ist sinnfrei und wird nie greifen.
13 permit ip 172.16.107.101 0.0.0.255 172.16.218.0 0.0.0.255 Dto. Gleicher Unsinn wie "11"
Das wiederholt sich jetzt in den Regeln 101, 201, 301, 401 und 601 !! Alles überflüssig da sie niemals greifen.
Ganz besonders unsinnig ist die Regel 601 die ALLES auf das eigene Segment zulässt. Falscher und unlogischer als DAS kann man eine Regel gar nicht mehr definieren ! Überleg selber mal wie unsinnig das ist, denn eigene Pakete laufen ja niemals über den L3 Switch sondern verbleiben im Switch selber da rein Layer 2.

War der Tatsache geschuldet, dass ich In- und Outbound falsch interpretiert habe. Die ACLs sind alle Outbound angewendet, dementsprechend sind die Regeln 10, 100, 200 etc. Sinnlos.

Für mich war Outbound quasi Inbound...dementsprechend habe ich die Regeln 10, 100, 200 etc. definiert und es hat nicht funktioniert. Als ich dann Regel 11,101,201 definiert habe (die ja faktisch richtig waren wenn man die ACL outbound an ein VLAN-Interface bindet) hat es dann funktioniert. War relativ verwirrend für mich - nach paar Tagen Abstand hat es dann *klick* gemacht! Vielen Dank dafür!

Beachte immer die Grundregeln:

Filter geht nur inbound !

Die Procurve-Gurke kann In- sowie Outbound

* "First match wins"... d.h. nach einem Regelhit wird der Rest der ACL NICHT mehr weiter abgearbeitet ! Reihenfolge zählt also auch !

Eins der wenigen Dinge dich ich vorher in die Planung mit einbezogen habe

--> Wichtig ist: Es funktioniert jetzt und ich hab es verstanden! Allerdings: Was ist denn ressourcenschonend - In- oder Outbound??

Die Procurve-Gurke kann In- sowie Outbound

Ja ja...aber Outbound geht nur über CPU und reisst den HP Billig Switch dann mit entsprechen Trafficvolumen in den Orkus wenn die ACL entsprechend dimensioniert ist.
Outbound ACL sind letztlich Blödsinn weil man ja immer generell verhindern will das ungewollte Pakete gar nicht erst in den Switch reinkommen.
Outbound ACL zeigen in der Regel das die Konfiug nicht richtig gemacht wurde...

gelöst Frage Netzwerke Netzwerkmanagement

Mehr von Philipp711

Built-In iOS-VPN Auto-Disconnect bei DisplaysperrePhilipp711 - 8 Kommentare

RAID Manager auf Ubuntu Server installieren (Fujitsu RX2540)Philipp711 - 6 Kommentare

Sophos UTM Mail Security - Empfängerverifizierung im ProfilmodusPhilipp711 - 6 Kommentare

Graylog-Sidecar - Filebeat konfigurationPhilipp711

Heiß diskutiert