Hilfe bei der ACL-Definition für Transfer-VLAN und Management-VLAN
Hallo,
um meine VLANs bestmöglich abzusichern, benötige ich Eure Unterstützung.
Aktueller Aufbau:
FB über Transfer-VLAN an CBS350 angebunden. auf dem CBS350 diverse VLANs definiert, die auch per ACLs abgesichert sind. Soweit ist alles erledigt.
Nun möchte ich das Management-VLAN weitestgehend abschotten. Allerdings benötigen die Switche in diesem VLAN einen Internetzugang für die Zeitserver und der L3-Switch ist gleichzeitig der DHCP-Server. Somit benötigen alle VLANs Zugriff auf die DHCP-Funktion. Und ich benötige den Zugriff auf die DNS-Server (Namensauflösung der Zeitserver und der Switch-Namen). Der Zugriff auf die Switche erfolgt nur über ein Gerät, dass im gleichen VLAN hängt.
Ich habe die ACLs nun wie folgt definiert :
Passt das so, oder habe ich einen Denkfehler. Ich habe die ACLs noch nicht dem VLAN zugeordnet.
Für das Transfer-VLAN benötige ich die Zugriffe auf den DHCP-Server und zwei weitere VLANs (140+180). Hier habe ich die ACLs wie folgt definiert:
Passt das so, oder "säge ich dann einen wichtigen Ast ab"?
Viele Grüße
Jürgen
um meine VLANs bestmöglich abzusichern, benötige ich Eure Unterstützung.
Aktueller Aufbau:
FB über Transfer-VLAN an CBS350 angebunden. auf dem CBS350 diverse VLANs definiert, die auch per ACLs abgesichert sind. Soweit ist alles erledigt.
Nun möchte ich das Management-VLAN weitestgehend abschotten. Allerdings benötigen die Switche in diesem VLAN einen Internetzugang für die Zeitserver und der L3-Switch ist gleichzeitig der DHCP-Server. Somit benötigen alle VLANs Zugriff auf die DHCP-Funktion. Und ich benötige den Zugriff auf die DNS-Server (Namensauflösung der Zeitserver und der Switch-Namen). Der Zugriff auf die Switche erfolgt nur über ein Gerät, dass im gleichen VLAN hängt.
Ich habe die ACLs nun wie folgt definiert :
ip access-list extended VLAN070-ACL
permit udp 0.0.0.0 0.0.0.0 bootps 255.255.255.255 0.0.0.0 bootpc ace-priority 10 DHCP-Anfragen erlauben
permit udp 192.168.70.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 20 DNS-Abfrage bei 192.168.180.50
permit tcp 192.168.70.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 30 DNS-Abfrage bei 192.168.180.50
permit udp 192.168.70.0 0.0.0.255 any 192.168.255.250 0.0.0.0 domain ace-priority 40 DNS-Abfrage bei 192.168.255.250
permit tcp 192.168.70.0 0.0.0.255 any 192.168.255.250 0.0.0.0 domain ace-priority 50 DNS-Abfrage bei 192.168.255.250
permit ip 192.168.70.0 0.0.0.255 192.168.70.0 0.0.0.255 ace-priority 1000 Zugriffe innerhalb des VLAN070 erlauben
deny ip 192.168.70.0 0.0.0.255 192.168.0.0 0.0.255.255 ace-priority 1100 Zugriff auf andere VLANs verbieten
permit udp 192.168.70.0 0.0.0.255 ntp any any ace-priority 1200 Zugriff auf Zeitserver im Internet
exit
Passt das so, oder habe ich einen Denkfehler. Ich habe die ACLs noch nicht dem VLAN zugeordnet.
Für das Transfer-VLAN benötige ich die Zugriffe auf den DHCP-Server und zwei weitere VLANs (140+180). Hier habe ich die ACLs wie folgt definiert:
ip access-list extended VLAN255-ACL
permit udp 0.0.0.0 0.0.0.0 bootpc 255.255.255.255 0.0.0.0 bootps ace-priority 10 gesendete DHCP-Anfragen erlauben
permit ip 192.168.255.0 0.0.0.255 192.168.140.0 0.0.0.255 ace-priority 400 Vollzugriff auf VLAN140
permit ip 192.168.255.0 0.0.0.255 192.168.180.0 0.0.0.255 ace-priority 600 Vollzugriff auf VLAN180
permit ip 192.168.255.0 0.0.0.255 192.168.255.0 0.0.0.255 ace-priority 1000 Zugriffe innerhalb des VLAN255 erlauben
deny ip 192.168.255.0 0.0.0.255 192.168.0.0 0.0.255.255 ace-priority 1100 Zugriff auf andere VLANs verbieten
permit ip 192.168.255.0 0.0.0.255 any ace-priority 1200 Zugriff auf das Internet erlauben
exit
Passt das so, oder "säge ich dann einen wichtigen Ast ab"?
Viele Grüße
Jürgen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1750545529
Url: https://administrator.de/forum/hilfe-bei-der-acl-definition-fuer-transfer-vlan-und-management-vlan-1750545529.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
13 Kommentare
Neuester Kommentar
Passt das so, oder "säge ich dann einen wichtigen Ast ab"?
Warum probierst du es dann nicht einfach einmal an einem Test VLAN Segment aus. Wäre doch das Intelligenteste um die Funktion zu verifizieren, oder ? Zumindestens Zeile 2 solltest du auf permit udp any any eq bootpc korrigieren sonst erleidest du Schiffbruch.
Außerdem ist permit ip 192.168.255.0 0.0.0.255 192.168.255.0 0.0.0.255 ziemlicher Blödsinn den du besser entsorgen solltest ! Ebenso das Pendant am 70er VLAN. Was sollte der tiefere Sinn dieser sinnfreien ACL sein ?? Lokaler Traffic rennt doch niemals über den Router !
Der Rest ist soweit OK. Zumindestens dann wenn es eine inbound ACL für das 70er und 255er VLAN ist.
Bedenke aber das dann Rückrouten Traffic via 255 rein nur in das 255er, das 140er und das 180er Netz kommt. Alle anderen VLANs sind mit der ACL vom Internet dann geblockt.
Sinnvoller wäre es wenn du in der 255er ACL den restlichen VLAN Inbound Traffic über eine Summary ACL mit Established Bit passieren lässt. So stellst du sicher das aller initiierter Traffic aus den VLANs passieren kann. Ist viel effizienter...
Hi Jürgen
Die einfache Variante filtert halt nicht nach Quellport.
Man kann das aber auch auf Blacklistung umstellen dann ist ein permit any any gültig.
Die Inverse Maske musst du so setzen das sie alle deine VLANs inkludiert.
Dadurch kommen nur TCP Frames mit gesetztem Established Bit durch also nur Rücktraffic von Sessions die in den VLANs initiiert wurden.
Hier musst du aber etwas aufpassen wenn du UDP auch durchlassen willst/musst. Das musst du getrennt mit zusätzlichen Regeln dort handhaben, denn ACLs sind nicht stateful.
Bisher scheint dies auch zu funktionieren.
Ist logisch auch das gleiche wie permit udp any any eq bootpc. Deine Variante ist etwas dichter was die IP Adressen betrifft und Sourc e und Destination Port betrifft. Wird Port 68 hier nicht benötigt?
Doch. Guckst du hier: https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Ablauf ...Die einfache Variante filtert halt nicht nach Quellport.
das die Kommunikation der Geäte untereinander nicht funktioniert
Das ist eigentlich Unsinn. Zieh einfach mal den Router ab oder setze den Port auf shutdown nachdem die IPs bezogen haben. Die können auch ohne kommunizieren. Der L3 Port wird doch nur dann benutzt wenn ein Client IP Pakete in andere Netze routen muss. Wireshark ist hier wieder dein bester Freund !! Der zeigt dir doch die Client Kommunikation mit dem Switch IP Port genau an ! Hiermit will ich intern verbieten, was vorher nicht erlaubt war.
Das musst du nicht bzw. kommt darauf an WAS für eine Default Logik du aktiviert hast. Normal ist immer ein impliziertes deny any any in der Liste. (Whitelisting)Man kann das aber auch auf Blacklistung umstellen dann ist ein permit any any gültig.
dass im 255-Netz alle VLANs, für die es erlaubt ist,
permit tcp any 192.168.0.0 0.0.255.255 eq establishedDie Inverse Maske musst du so setzen das sie alle deine VLANs inkludiert.
Dadurch kommen nur TCP Frames mit gesetztem Established Bit durch also nur Rücktraffic von Sessions die in den VLANs initiiert wurden.
Hier musst du aber etwas aufpassen wenn du UDP auch durchlassen willst/musst. Das musst du getrennt mit zusätzlichen Regeln dort handhaben, denn ACLs sind nicht stateful.
versuche, bekomme ich die Info "Unrecognized command".
Warum hangelst du dich dann nicht mit dem "?" mal durch ??? Das ist doch das Naheliegenste und kommt jeder sofort selber drauf ?!Der Cisco hat doch die Hilfe für dich immer gleich an Bord, du musst ihn nur danach fragen mit dem "?"
https://www.coufal.info/cisco_ios/basis.shtml
An jeder Stelle der Syntax kannst du ein "?" eingeben und der Cisco sagt dir dann immer was er von dir möchte !
Also vielleicht einmal permit tcp any 192.168.0.0 0.0.255.255 ? versuchen.
Das ist aber auch eine schwere Geburt mit dir....
<cody>HV-Stack(config)#ip access-list ?
extended Create an extended ACL.
WORD<1-32> The IP standard access list name.
Du siehst hier will er wissen ob du eine extend List oder eine Simple List haben willst. Simple will er die ACL Nummer extended <name_acl> legt diese Liste an !
Logischerweise musst du dann immer erst den Namen angeben wenn du eine Extended List bearbeitest.
Ausnahme natürlich du nutzt lokale L2 Funktionen auf dem Switch wie DHCP usw. Aber die fragen ja dann imemr die Switch IP und niemals ihre eigenen IPs bei Kommunikation untereinander.
Das kannst du einfach nachvollziehen indem du den lokalen Clients einmal statische IPs verpasst. Dann kannst du ein deny any any an der ACL eingeben und diese Clients können trotzdem lokal kommunizieren was ja auch aus L3 Sicht logisch nachvollziehbar ist.
<cody>HV-Stack(config)#ip access-list ?
extended Create an extended ACL.
WORD<1-32> The IP standard access list name.
Du siehst hier will er wissen ob du eine extend List oder eine Simple List haben willst. Simple will er die ACL Nummer extended <name_acl> legt diese Liste an !
Logischerweise musst du dann immer erst den Namen angeben wenn du eine Extended List bearbeitest.
- permit ? zeigt dir dann welche Protokolle die ACL supportet
- z.B. permit tcp ? erklärt sich selber... Sequence fpr die Reihenfolge usw.
- usw. usw
permit tcp any 192.168.0.0 0.0.255.255 eq established
Nichts anderes wurde dir ja oben schon erklärt ! 😉sondern in der Form
Das ist richtig. Oben war nur der grobe Rahmen der dich auf diese Spur bringen sollte... Bleibt noch die Frage, warum die Zugriffe innerhalb eines VLANs nicht funktioieren, wenn ich dies nicht explizit erlaube.
Das ist richtig. Habe das hier auf einem SG300 mit aktueller Firmware mal versucht zu reproduzieren. Passiert erwartbar nicht... Ist auch klar, denn lokaler L2 Traffic innerhalb eines VLANs "sieht" den L3 Switch niemals.Ausnahme natürlich du nutzt lokale L2 Funktionen auf dem Switch wie DHCP usw. Aber die fragen ja dann imemr die Switch IP und niemals ihre eigenen IPs bei Kommunikation untereinander.
Das kannst du einfach nachvollziehen indem du den lokalen Clients einmal statische IPs verpasst. Dann kannst du ein deny any any an der ACL eingeben und diese Clients können trotzdem lokal kommunizieren was ja auch aus L3 Sicht logisch nachvollziehbar ist.
Fernseher und GigaTV-Box melden weiterhin "kein Internet". Beide sind im VLAN160.
Die machen garantiert irgendwie so eine "Nach Hause telefonier" Schnüffel Schweierei wie alle diese Fernseher. Die melden bekanntlich alle deinen TV Gewohnheiten an Hersteller und andere Interessierte. Damit verdienen die Hersteller mehr Geld als mit den TV allein.https://www.welt.de/wirtschaft/webwelt/article220724198/Smart-TV-So-hind ...
https://www.kaspersky.de/blog/shopping-und-online-banking-mit-dem-smart- ...
Belausche den am besten mal mit dem Kabelhai oder dem hier.
So erkennst du WO die genau hinfunken und was sie erwarten um ein funktionierendes Internet anzuzeigen. Das kannst du dann entsprechend mit den ACLs customizen.
Wenn die Giga TV Box eine Settop Box für IP TV ist macht die Mukticast. Da geht es dann wiede rum ganz andere IP Adressen.
Da hilft nur der Wireshark um genau rauszubekommen was die da machen im Netz und daraus dann die ACLs maßzuschneidern.
Erst einmal vielen Dank für Deine Hilfe.
Immer gerne ! 🙂Wenn's das denn war bitte den Thread auch als erledigt markieren.
Wie kann ich einen Beitrag als gelöst markieren?