philipp711
Jul 17, 2017, updated at 14:03:15 (UTC)
view9775
view9
0
Goto Top

Switch ACL-Konfiguration

GermansolvedQuestionNetwork ManagementNetworks
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"  
     10 permit ip 172.16.218.0 0.0.0.255 172.16.107.100 0.0.0.255
     11 permit ip 172.16.107.100 0.0.0.255 172.16.218.0 0.0.0.255
     12 permit ip 172.16.218.0 0.0.0.255 172.16.107.101 0.0.0.255
     13 permit ip 172.16.107.101 0.0.0.255 172.16.218.0 0.0.0.255
     
     100 permit ip 172.16.218.0 0.0.0.255 172.16.201.0 0.0.0.255
     101 permit ip 172.16.201.0 0.0.0.255 172.16.218.0 0.0.0.255
     
     200 permit ip 172.16.218.0 0.0.0.255 172.16.202.0 0.0.0.255
     201 permit ip 172.16.202.0 0.0.0.255 172.16.218.0 0.0.0.255
     
     300 permit ip 172.16.218.0 0.0.0.255 172.16.203.0 0.0.0.255
     301 permit ip 172.16.203.0 0.0.0.255 172.16.218.0 0.0.0.255
     
     400 permit ip 172.16.218.0 0.0.0.255 172.16.109.0 0.0.0.255
     401 permit ip 172.16.109.0 0.0.0.255 172.16.218.0 0.0.0.255
     
     500 deny ip 172.16.218.0 0.0.0.255 172.16.0.0 0.0.255.255
     
     600 permit ip 172.16.218.0 0.0.0.255 0.0.0.0 255.255.255.255
     601 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
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 343629

Url: https://administrator.de/contentid/343629

Printed on: April 20, 2024 at 01:04 o'clock

9 Comments
Latest comment
Goto Top
Member: chgorges
chgorges Jul 17, 2017 updated at 14:39:03 (UTC)
Goto Top
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
heart1
Member: Philipp711
Philipp711 Jul 17, 2017 updated at 15:44:28 (UTC)
Goto Top
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...
Member: chgorges
chgorges Jul 17, 2017 at 17:01:49 (UTC)
Goto Top
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.
Member: Philipp711
Philipp711 Jul 17, 2017 at 19:15:33 (UTC)
Goto Top
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...
Member: Philipp711
Philipp711 Jul 17, 2017 updated at 19:28:43 (UTC)
Goto Top
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?!
Member: chgorges
Solution chgorges Jul 18, 2017 at 08:35:47 (UTC)
Goto Top
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.
Member: aqui
Solution aqui Jul 18, 2017 updated at 11:26:24 (UTC)
Goto Top
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 face-sad

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 !
Member: Philipp711
Philipp711 Jul 21, 2017 updated at 07:49:52 (UTC)
Goto Top
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 face-wink


--> Wichtig ist: Es funktioniert jetzt und ich hab es verstanden! Allerdings: Was ist denn ressourcenschonend - In- oder Outbound??
Member: aqui
aqui Jul 27, 2017 updated at 14:31:37 (UTC)
Goto Top
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...
GermansolvedQuestionNetwork ManagementNetworks
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 3 CommentsAlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment