ACE-Definitionen zwischen zwei VLANs (Cisco SG250-08)
Hallo,
wenn ich es richtig verstanden habe, erlaube oder verbiete ich mit der ACE-Definition nur den eingehenden Datenverkehr. Wenn nun die Kommunikation zwischen zwei VLANs über einen definierten Port erfolgen darf, habe ich dies bisher immer wie folgt definiert:
Im nachfolgenden Beispiel dürfen alle Geräte aus dem VLAN 160 (192.168.160.0/24) mit der IP 192.168.180.50 (VLAN180) über Port 8701 Daten austauschen.
Nun frage ich mich, ob es nicht sinnvoller ist, anstatt für die Ports any : 8701 bzw. 8701 : any immer 8701 : 8701 anzugeben. Wie ist hier Eure Empfehlung.
Es würde dann so aussehen:
Viele Grüße
Jürgen
wenn ich es richtig verstanden habe, erlaube oder verbiete ich mit der ACE-Definition nur den eingehenden Datenverkehr. Wenn nun die Kommunikation zwischen zwei VLANs über einen definierten Port erfolgen darf, habe ich dies bisher immer wie folgt definiert:
Im nachfolgenden Beispiel dürfen alle Geräte aus dem VLAN 160 (192.168.160.0/24) mit der IP 192.168.180.50 (VLAN180) über Port 8701 Daten austauschen.
permit tcp 192.168.160.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 ace-priority 170
und
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 any ace-priority 140
Nun frage ich mich, ob es nicht sinnvoller ist, anstatt für die Ports any : 8701 bzw. 8701 : any immer 8701 : 8701 anzugeben. Wie ist hier Eure Empfehlung.
Es würde dann so aussehen:
permit tcp 192.168.160.0 0.0.0.255 8701 192.168.180.50 0.0.0.0 8701 ace-priority 170
und
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701 ace-priority 140
Viele Grüße
Jürgen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666312
Url: https://administrator.de/contentid/666312
Ausgedruckt am: 06.11.2024 um 01:11 Uhr
17 Kommentare
Neuester Kommentar
über Port 8701 Daten austauschen....
Wenn du mit dem Port "TCP" meinst ist das richtig. Allerdings ist das "UND" etwas unsinnig in der Regel, denn wenn diese nur inbound gilt ist das zusätzliche Regelwerk:"permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701 ace-priority 140"
mit der höheren Priority Blödsinn, denn am VLAN 160 IP Interface kann es inbound ja niemals IP Pakete mit einer Absender IP 192.168.180.x geben ! Das wäre völlig unsinnig. Diese Regel stört zwar nicht hat aber keinerlei Effekt weil sie völlig sinnfrei ist, da diese Regel Bedingungen dort niemals eintreten.
Hier kann einmal ein Blick mit dem Wireshark wie so der Paket Flow einer solchen Verbindung aussieht sehr sehr erhellend sein !!
Wie ist hier Eure Empfehlung.
Das Regelwerk ist unsinnig, denn wie du sicher selber als guter Netzwerker weisst ist der Source Port im TCP immer Random, also zufällig !Wenn du jetzt sowas angibst wie "permit tcp 192.168.160.0 0.0.0.255 8701 ..." erlaubst du nur noch Absender Pakete mit einem Source Port von TCP 8701. Da kannst du dann vermutlich warten bis du schwarz bist bevor so ein Paket mal an der Filterregel vorbeikommt. 6 Richtige im Lotto plus Zusatzzahl sind da sicher häufiger. 🤣
Diese Regel wird dir dann natürlich den gesamten Traffic blockieren.
Die 2te Regel ist wie oben auch wieder überflüssig da nutzlos.
Zeigt leider das du nicht so richtig blickst wie eine TCP Kommunikation im Netz funktioniert.
Deshalb nochmals der dringende Rat dir so eine Connection mal mit dem Wireshark anzusehen. Das bewirkt Wunder im Durchblick wie IP Pakte sich im Netzwerk bewegen !! 😉
alles wichtige von Dir gelernt habe
Oha...das wird ein hartes Stück Arbeit dann bis dahin ! 🤣Ich hätte vieleicht dazu schreiben sollen
Oha, ja. Dann wären wir alle nicht so blindlinks in dein offenes ACL Messer gerannt. Es ist IMMER essentiell wichtig zu wissen auf WELCHEM IP Interface diese ACL definiert ist !!!dass ich per https aus dem IP-Bereich 192.168.160.0/24 über den Port 8701 Webseiten auf dem Gerät 192.168.180.50 aufrufen kann
Nein das ist falsch. Wenn man davon ausgeht das HTTPS immer TCP 443 ist. Aber auch sonst stimmen deine Schlussfolgerungen nicht da du hier immer Source und Destination IP verwechselst.Die Regel ist so ausgebaut:
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701
Sprich also
permit <protokoll> <source_ip> <source_mask> <source_port> <destination_ip> <destination_mask> <desination_port>
Also besagt diese Regel:
"Erlaube eingehend ein TCP Paket mit der Absender IP 192.168.180.50 und dem Absenderport TCP 8701 und der Ziel IP 192.168.160.x (alles im Netzwerk .160.x ist erlaubt) und Zielport TCP 8701
Aus mehreren Gründen wird diese Regel scheitern wenn sie INBOUND am IP Interface .160.x definiert ist.
- Im .160.x VLAN Netz wird es niemals ein Gerät geben was eine Absender IP 192.168.180.50 hat, denn das ist eine IP aus dem .180er VLAN
- Niemals hat ein TCP Packet den gleichen Source und Destination Port
- der Source Port eines TCP Paketes ist immer Random also eine Zufallszahl !
Da sie eine völlig falsche Logik hat und diese .180.50er IP Adresse dort niemals auftreten wird, wird sie auch niemals greifen. Sie schadet also glücklicherweise nicht ist aber vollkommen nutzlos.
Deshalb greift hier primär immer deine Regel: "permit tcp 192.168.160.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 auch wenn sie eine höhere Regelpriorität hat, also in der Regelwerk Reihenfolge hinter der ersten steht die ja niemals wirken wird.
Diese erlaubt dann allen TCP Traffic mit jeder Absender IP aus dem .160er VLAN Netz und jedem Absender Port (richtig, denn der ist ja Zufall) auf die Zieladresse 192.168.180.50 mit dem Zielport TCP 8701.
Diese Regel greift also weil sie logisch richtig ist und folglich können die TCP Pakete mit der der Ziel IP und Port 8701 passieren.
Die andere mit der höheren Prio ist nur ein reiner, überflüssiger Durchlauferhitzer die niemals einen positiven Hit ergibt. Das kannst du auch am Hit Counter der ACL ablesen.
Das bedeutet doch dann, dass die Kommunikation aus dem VLAN immer funktioniert, aber in das VLAN nur was erlaubt wurde.
Absolut richtig.Aus dem VLAN Segment .160.0 können so nur TCP 8701 Pakete zum Host .180.50 durchkommen mit Zielport TCP 8701 sollte das deine einzige Regel sein inbound am .160er IP Interface.
Dann muss ich meine Regeln noch etwas überarbeiten.
Das wäre anzuraten... Ich bin erstaunt, dass trotzdem bisher so viel funktionier hat
Das liegt daran das einige der Regeln wie z.B. die mit der .180er Absender IP zwar syntaktisch vollkommen falsch sind aber auch nicht schaden. Der PERMIT würde ja niemals eintreten und dann gilt weiter des implizite DENY was du ohne diese ja Regel auch hättest. In sofern richtet die Regel also nie einen merkbaren Schaden an weil sie gänzlch ohne jegliche Funktion ist an der Stelle.Hast also Glück gehabt...
habe ich nun folgende Einträge in der VLAN200-ACL vorgesehen:
WAS für ein IP Netz hat das 200er VLAN ?? .70.0 ??Wenn es .70.0 ist dann ist die Hälfte dieser Regeln wieder Unsinn.
- Erste Regel (Prio 10) ist OK für DHCP
- Die .70.x Regeln stimmen auch weil dort ja nur Absender IP aus .70.x kommen
- Die Regeln die Absender IPs von .180.0 betreffen sind wieder Unsinn, denn die können da ja niemals auftauchen.
Das Regelwerk greift INBOUND also alle Pakete vom VOM Netzwerk Draht IN das VLAN IP Interface hineingehen.
Gehen wir also mal logisch davon aus das dein VLAN 200 auch die IP .200.0 hat. Folglich haben also ALLE Absender IPs immer eine 192.168.200.x Adresse.
Wenn das Regelwerk nun so funktioniert:
PERMIT|DENY <protokoll> <ABSENDER_ip> <source_mask> <source_port> <ZIEL_ip> <destination_mask>
und du am 200er Interface sagst
"Filter alles was hier reinkommt und eine Absender IP von ....70.x hat und....
Filter alles was hier reinkommt und eine Absender IP von ....180.x hat und..."
dann fragt man sich WIE du auf die Idee kommst das am 192.168.200er IP Interface jemals Absenderpakete mit der Adresse .70.x oder .180.x ankommen soll wie du es definiert hast ???
Diese Regeln sind wieder völlig wirkungslos. Wenn du sie so implementierst wird lediglich DHCP funktionieren alles andere wird weiter geblockt weil du nach völlig falschen Absender IPs blockst.
Das ist doch vollkommen unmöglich ! Es können doch nur Absender IPs aus dem 200er VLAN dort ankommen.
Du hast wieder nicht geschnallert das das Regelwerk INBOUND gilt.
Der zweite Kardinalsfehler ist das du gleiche Priorities vergeben hast. Wie soll das bitte gehen wenn das Regelwerk eine strike Hierarchie haben muss (Reihenfolge). Priority Werte sollten dann in 3er oder 5er Schritten inkrementieren. Der intelligente Netzwerk Admin lässt Zwischenschritte damit er später in jedem Punkt des Regelwerkes Regeln zwischenschieben kann OHNE das er die ganzen Prio Werte neu ordnen muss.
Hier mal ein Beispiel wie ein Regelwerk an VLAN 200 auszusehen hat was nur DHCP, DNS, HTTP und HTTPS nach Überall durchlässt:
permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10
permit udp 192.168.200.0 0.0.0.255 any any 53 ace-priority 15
permit tcp 192.168.200.0 0.0.0.255 any any 53 ace-priority 20
permit tcp 192.168.200.0 0.0.0.255 any any 80 ace-priority 25
permit tcp 192.168.200.0 0.0.0.255 any any 443 ace-priority 30
Beispiel wenn VLAN 200 Traffic nur DHCP und DNS nach Überall durchlässt und HTTP und HTTPS nur in die VLANs .70.0 und .180.0
permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10
permit udp 192.168.200.0 0.0.0.255 any any 53 ace-priority 15
permit tcp 192.168.200.0 0.0.0.255 any any 53 ace-priority 20
permit tcp 192.168.200.0 0.0.0.255 any 192.168.70.0 0.0.0.255 80 ace-priority 25
permit tcp 192.168.200.0 0.0.0.255 any 192.168.180.0 0.0.0.255 443 ace-priority 30
Ich denke mal nun hast du vermutlich diese einfache Logik durchschaut, oder ?
Tip:
Tu dir doch wirklich mal selber den Gefallen und installier dir mal den Wireshark auf dem Rechner und sieh dir damit mal deine Pakete im Netz an. Das wird Wunder und mit einmal verstehst du sofort wie die Pakete mit Absneder und Ziel IP ausgebaut sind !!! 😉
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
und hätte nur die Outbound-Regeln löschen müssen.
Richtig ! Die erste Zeile war immer in der ACL-160 und die 2. Zeile in der ACL-180.
Genau DAS hatte wohl alle verwirrt. Du hast gedacht das du den Rückweg auch angeben musst, war aber Unsinn, denn das wäre dann Outbound was das regelwerk gar nicht beachtet...Ich baue noch einmal um.
Besser iss das... Ich melde mich morgen mit den nächsten Versuch.
Wir sind gespannt...erreiche ich den Drucker nicht über die Web-Oberfläche (Port 80)
Ist aber selber so gewollt oder siehst du in deiner VLAN140-ACL oben das irgendwas anderes außer DHCP, DNS und Ping Replies erlaubt ist ??? Ich jedenfalls nicht.Wie dachtest du dir denn soll da HTTP Traffic durchkommen ?!
Wenn ich hier aber in der ACE-140 diesen Eintrag hinzufüge, geht es
Auch logisch... Das erlaubt dann allen HTTP Traffic vom Drucker mit der .140.1 ins .100.0er Netz wo vermutlich dein Konfig PC steht ?!Also...Works as designed !
Wenn du nicht willst das ALLE aus dem 100er Netz das können musst du das noch dichtmachen auf deinen Rechner und ggf. HTTP
permit tcp 192.168.140.1 0.0.0.0 80 192.168.100.23 0.0.0.0 any ace-priority 200
Aus meiner Sicht fehlt bei meinen Definitionen aktuell jeweils der "Antwort-Port".
Der Port nicht aber das Netz. Das ist richtig weil ACLs im Gegensatz zu einer Firewall nicht stateful sind. 😉Ich würde jetzt ungerne per "Gieskanne" alle Ports, über die eine Anfrage kommt, auch als "Antwort-Port" wieder frei geben,
Da musst du mal checken ob du im Regelwerk TCP Pakete mit gesetztem ACK Bit passieren lassen kannst ala:permit tcp 192.168.140.1 0.0.0.0 any 192.168.100.0 0.0.0.255 any established ace-priority 200
Bei Catalysten geht das.
Das würde dann quasi stateful sein und allen Paketen die nach einer Connection auf den Drucker .140.1 wieder ins .100er Netz rauskommen UND ein gesetztes TCP ACK Bit haben den Weg freimachen. Das wäre dann zumindestens für TCP die "Giesskanne" die du benötigst.