juemuc
Goto Top

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.

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

Content-ID: 666312

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

Ausgedruckt am: 24.11.2024 um 22:11 Uhr

aqui
aqui 02.05.2021 aktualisiert um 15:47:20 Uhr
Goto Top
ü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 !! face-wink
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. face-sad
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 !! 😉
juemuc
juemuc 02.05.2021 um 19:45:27 Uhr
Goto Top
Hallo aqui,

der Satz "...wie du sicher selber als guter Netzwerker weisst ..." war gut face-smile. Alles was ich über den Netzwerkkommunikation weiß, habe ich aus den Infos von Dir. Ich hoffe, dass ich in knapp einem Jahr, wenn ich dann in den Ruhestand gehe, alles wichtige von Dir gelernt habe face-wink

Ich hätte vieleicht dazu schreiben sollen, dass die beiden Regeln natürlich in zwei unterschiedlichen ACE-Tabellen enthalten sind und jeweils dem dazugehörigen VLAN zugeordnet sind.
Wenn ich Dich richtig verstanden habe, sorgt die Regel
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701 ace-priority 140
dafür, 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. Da kein "request" vom Gerät 192.168.180.50 erfolgt, funktioniert es. Die Regel
permit tcp 192.168.160.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 ace-priority 170
ist somit nutzlos.
Das bedeutet doch dann, dass die Kommunikation aus dem VLAN immer funktioniert, aber in das VLAN nur was erlaubt wurde.
Dann muss ich meine Regeln noch etwas überarbeiten. Ich bin erstaunt, dass trotzdem bisher so viel funktionier hat face-smile

Viele Grüße
Jürgen
aqui
aqui 03.05.2021 aktualisiert um 09:38:46 Uhr
Goto Top
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 !
Du erkennst vermutlich selber wie sinnfrei diese Regel ist.
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... face-wink
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... face-wink
juemuc
juemuc 04.05.2021 um 21:00:42 Uhr
Goto Top
Hallo aqui,

es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen face-smile

Ich hatte mich schon gewundert, warum Cisco die Definitionen so "quer" vorgenommen hat, dabei war meine Denke "quer" face-sad

Wenn ich die Regeln neu augebaut habe, werde ich Dich aber zur Sicherheit noch einmal drüber schauen lassen. Ich will ja noch vor dem Renteneintritt fertig werden face-smile

Viele Grüße
Jürgen
aqui
aqui 05.05.2021 um 11:20:57 Uhr
Goto Top
es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hoffe das ist positiv gemeint ?! 🧐
warum Cisco die Definitionen so "quer" vorgenommen hat, dabei war meine Denke "quer"
Es ist immer eine Frage des Standpunktes... face-wink
noch einmal drüber schauen lassen.
Immer gerne...
juemuc
juemuc 05.05.2021 um 20:20:02 Uhr
Goto Top
Zitat von @aqui:

es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hoffe das ist positiv gemeint ?! 🧐
Ja! Es war wirklich ernst gemeint.
noch einmal drüber schauen lassen.
Immer gerne...

Dann werde ich gleich mal loslegen face-smile

Für das Gast-VLAN (VLAN200) habe ich nun folgende Einträge in der VLAN200-ACL vorgesehen:

ip access-list extended VLAN200-ACL (Gast-LAN)

permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10				DHCP-Antworten zulassen

permit udp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 20			DNS-Antworten 1. DNS-Server
permit udp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 30		DNS-Antworten 1. DNS-Server
permit tcp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 40			DNS-Antworten 1. DNS-Server
permit tcp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 40		DNS-Antworten 1. DNS-Server
permit udp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 50			DNS-Antworten 2. DNS-Server
permit udp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 60		DNS-Antworten 2. DNS-Server
permit tcp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 70			DNS-Antworten 2. DNS-Server
permit tcp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 80		DNS-Antworten 2. DNS-Server


deny ip 192.168.0.0 0.0.255.255 192.168.200.0 0.0.0.255 ace-priority 400				Alle internen Zugriffe sperren, sofern vorher nicht erlaubt

permit ip any 192.168.200.0 0.0.0.255 ace-priority 500							Alle Zugriffe aus dem Internet erlauben

exit													"Default: Deny Any"  

Jetzt zu meinen Fragen:

Passen aus Deiner Sicht diese Einträge?
Kommen die "DNS-Antworten" wirklich über diese Ports? Es gibt zwei DNS-Server DNS2 = Backup.

Wäre es nicht sinnvoller nur bestimmte Ports für die IPs aus dem Internet freizugeben? Wenn ja, was wäre den sinnvoll?
Was benötige ich? Ich greife per Cisco-VPN-Client auf das Firmennetzwerk zu. Ansonsten sollen noch die Webseiten aufrufbar sein.

Wireshark habe ich noch nicht genutzt. Ich befürchte aber, dass hier meine Fragen noch unverständlicher klingen werden face-smile

Viele Grüße
Jürgen
aqui
aqui 05.05.2021 aktualisiert um 21:09:08 Uhr
Goto Top
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. face-sad
  • 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.
Ich befürchte das du weiterhin einen fatalen Denkfehler machst. face-sad
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
juemuc
juemuc 05.05.2021 um 22:52:03 Uhr
Goto Top
Gut das ich nachgefragt habe face-sad

Dann hatte ich es doch am Anfang richtig verstanden und hätte nur die Outbound-Regeln löschen müssen. Ich habe noch einmal meinen ersten Thread gelesen. Jetzt ist mir auch klar, warum Du das nicht verstehen konntest und mich damit dann auch wieder verwirrt hast. Die erste Zeile war immer in der ACL-160 und die 2. Zeile in der ACL-180.

Ich baue noch einmal um.

Das Thema Prio war nur ein Tipp-Fehler. Ich habe die Regeln ja aktuell nur auf "Papier" also in einem Dokument. Ich habe ja Deinen Tipp befolgt, das man das ganze erst einmal aufschreiben soll. Umgesetzt ist noch nichts face-smile

Ich melde mich morgen mit den nächsten Versuch.

Viele Grüße
Jürgen
aqui
aqui 06.05.2021 um 10:24:25 Uhr
Goto Top
und hätte nur die Outbound-Regeln löschen müssen.
Richtig ! face-wink
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... face-big-smile
Ich melde mich morgen mit den nächsten Versuch.
Wir sind gespannt...
juemuc
juemuc 08.05.2021 um 14:31:59 Uhr
Goto Top
Hallo aqui,

hier nun mein Ergebnis:

Aus dem VLAN 100 möchte ich auf alle VLANs zugreifen. Manche Zugriffe sind eingeschränkt. Die dedizierten DNS-Zugriffe sind zwar überflüssig, aber als Vorlage für die anderen VLANs auch hier definiert.

ip access-list extended VLAN100-ACL (Verwaltungs-Lan)

permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10				DHCP-Anfragen zulassen

permit udp 192.168.100.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 20			DNS-Anfragen 1. DNS-Server
permit tcp 192.168.100.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 30			DNS-Anfragen 1. DNS-Server
permit udp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 40			DNS-Anfragen 2. DNS-Server
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 50			DNS-Anfragen 2. DNS-Server

permit icmp 192.168.100.0 0.0.0.255 192.168.160.80 0.0.0.0 echo-reply any ace-priority 90		Ping-Anfrage FHEM beantworten

permit ip 192.168.100.0 0.0.0.255 192.168.70.0 0.0.0.255 ace-priority 100				uneingeschränkter Zugriffe in das VLAN 1 (192.168.70.0/24) erlauben 

permit ip 192.168.100.0 0.0.0.255 192.168.120.0 0.0.0.255 ace-priority 200				uneingeschränkter Zugriff in das VLAN 120 (192.168.120.0/24) erlauben 

permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 80 ace-priority 300				Zugriffe per http aus das Drucker-VLAN erlauben 
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 443 ace-priority 310				Zugriffe per https aus das Drucker-VLAN erlauben  
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 427 ace-priority 320				Zugriffe per SLP aus das Drucker-VLAN erlauben  
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 515 ace-priority 330				Zugriffe per LPD aus das Drucker-VLAN erlauben 
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 613 ace-priority 340				Zugriffe per IPP aus das Drucker-VLAN erlauben 
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 9100 ace-priority 350			Zugriffe per RAW aus das Drucker-VLAN erlauben 

permit ip 192.168.100.0 0.0.0.255 192.168.160.0 0.0.0.255 ace-priority 400				uneingeschränkter Zugriff auf IOT VLAN

permit udp 192.168.100.0 0.0.0.255 echo 192.168.180.50 0.0.0.0 echo ace-priority 510			Zugriff auf Cloud VLAN (Echo)
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 6690 ace-priority 520			Cloud Station
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 ace-priority 530			https
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8888 ace-priority 540			pi-hole - Docker

deny ip 192.168.0.0 0.0.255.255 192.168.100.0 0.0.0.255 ace-priority 800				Alle internen Zugriffe sperren, sofern vorher nicht erlaubt

permit ip 192.168.100.0 0.0.0.255 any ace-priority 900							Alle Zugriffe in das Internet erlauben 

exit													"Default: Deny Any"  

Aus dem Drucker-VLAN soll nur der "Ping" beantwortet werden. Allerdings vermute ich, dass ich noch noch weitere Ports frei geben muss, dass der Drucker auch die "Druckergebnisse" zurückmelden kann. Hier bitte ich um Hilfe.

ip access-list extended VLAN140-ACL (Drucker)

permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10				DHCP-Anfragen zulassen

permit udp 192.168.140.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 20			DNS-Anfragen 1. DNS-Server
permit tcp 192.168.140.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 30			DNS-Anfragen 1. DNS-Server
permit udp 192.168.140.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 40			DNS-Anfragen 2. DNS-Server
permit tcp 192.168.140.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 50			DNS-Anfragen 2. DNS-Server

permit icmp 192.168.140.0 0.0.0.255 192.168.160.80 0.0.0.0 echo-reply any ace-priority 90		Ping-Anfrage FHEM beantworten

deny ip 192.168.140.0 0.0.0.255 192.168.0.0 0.0.255.255 ace-priority 800				Alle internen Zugriffe sperren, sofern vorher nicht erlaubt

exit

Ich hoffe das passt so.

Viele Grüße
Jürgen
aqui
aqui 08.05.2021 um 15:59:04 Uhr
Goto Top
Ich hoffe das passt so.
Jupp, das sieht erheblich besser aus ! face-wink

Über die Drucker 800er Regel könnte man kosmetisch diskutieren, denn am Ende der Regel gilt so oder so immer ein impliziertes "DENY any any" was die 800er Regel dann eh inkludiert und überflüssig macht.
Aber sonst...alles Bella ! face-wink
juemuc
juemuc 08.05.2021 um 22:18:58 Uhr
Goto Top
Hallo aqui,

das passt aber leider noch nicht. In dieser Konstellation erreiche ich den Drucker nicht über die Web-Oberfläche (Port 80). Ich vermute, dass ich einen "Antwort-Port" vom 140-VLAN ins 100-VLAN frei geben muss.

Wenn ich hier aber in der ACE-140 diesen Eintrag hinzufüge, geht es. Dies wieder spricht aber Deiner Aussage.
permit tcp 192.168.140.1 0.0.0.0 80 192.168.100.0 0.0.0.255 any ace-priority 200

Wo liegt mein Denkfehler?

Aus meiner Sicht fehlt bei meinen Definitionen aktuell jeweils der "Antwort-Port".

Viele Grüße
Jürgen
aqui
aqui 09.05.2021 um 12:56:12 Uhr
Goto Top
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 ! face-wink
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. 😉
juemuc
juemuc 09.05.2021 um 13:30:55 Uhr
Goto Top
Und wieder kommt etwas Licht in meine Geankengänge face-smile

Gibt es eine Regel, welcher Port für die "Antworten" genutzt wird?

In meinem Beispiel erfolgt die Anfrage in der ACE-100 über
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 80 ace-priority 300

und die Antwort in der ACE-140 über
permit tcp 192.168.140.1 0.0.0.0 80 192.168.100.0 0.0.0.255 any ace-priority 200

Ich würde jetzt ungerne per "Gieskanne" alle Ports, über die eine Anfrage kommt, auch als "Antwort-Port" wieder frei geben, wenn dies nicht notwendig ist. Es sei denn, dies ist immer notwendig.

Ich weiß, Du empfiehlst das jetzt mit Wireshark zu prüfen, aber soweit bin ich noch nicht face-smile Ich hoffe, dies für meine Bedürfnisse noch einfacher möglich ist face-smile

Viele Grüße
Jürgen
aqui
aqui 09.05.2021 aktualisiert um 14:00:03 Uhr
Goto Top
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. face-wink
juemuc
juemuc 09.05.2021 um 14:55:41 Uhr
Goto Top
Ich kann die Flags zumindest setzen.
Ich habe die Möglichkeit zwischen "Set", "Unset" und "Don't care" (default).
Ich habe diese Möglichkeiten:
Urg:
	Set
	Unset
	Don't care  
	
Ack:
	Set
	Unset
	Don't care  
	
Psh:
	Set
	Unset
	Don't care  
	
Rst:
	Set
	Unset
	Don't care  
	
Syn:
	Set
	Unset
	Don't care  
	
Fin:
	Set
	Unset
	Don't care  

Ich werde das mal mit Port 80 testen.
juemuc
juemuc 09.05.2021 um 19:38:28 Uhr
Goto Top
Ich werde das mal mit Port 80 testen.

Mit diesen Einstellungen funktioniert es.
permit tcp 192.168.140.0 0.0.0.255 any 192.168.100.0 0.0.0.255 any match-all +ack ace-priority 300
permit udp 192.168.140.0 0.0.0.255 any 192.168.100.0 0.0.0.255 any ace-priority 310

Allerdings würde ich gerne noch die UDP-Freigabe (Abfrage Druckerstatus) noch weiter einschränken. Ist das möglich/sinnvoll?

Viele Grüße
Jürgen