12
ACLs für VLAN - Eure Meinung
Hallo zusammen,
ich habe unser Netzwerk in diverse VLANs unterteilt und bin nun an dem Thema ACLs dran.
Wir haben für das VLAN 10 (als Beispiel) diese wie folgt gebaut:
In diesem VLAN (10) sind einige Netzwerkgeräte, zu denen oder von denen Verbindungen aus / hin initiiert werden.
Regel 10 - 60 wäre nur dafür da, dass sich die Geräte in dem VLAN mit unseren zwei DCs connecten können (DNS, NTP & LDAP). DHCP ist in diesem VLAN nicht angewendet.
Regel 70 lässt die Verbindung zu einem unserer Servern auf Port 8005 zu.
Regel 80 lässt unsere QNAP einen Sync mit einer anderen QNAP in einem anderen VLAN zu.
Regel 90 lässt den von den Clients initiierten Traffic wieder zurückfließen, sollte er established sein.
Regel 100 untersagt VLAN 10 die Kommunikation zu allen anderen VLANs.
Regel 110 lässt sonstigen Verkehr (bspw. Internet) zu.
Ist das so alles in Ordnung, oder habe ich hier einen groben Schnitzer drin?
Freue mich über Euer Feedback!
VG Fred
ich habe unser Netzwerk in diverse VLANs unterteilt und bin nun an dem Thema ACLs dran.
Wir haben für das VLAN 10 (als Beispiel) diese wie folgt gebaut:
SEQ Source Maske Target Maske EQ Permit/Deny
10 any 172.16.40.1 0.0.0.0 NTP Permit
20 any 172.16.40.1 0.0.0.0 DNS Permit
30 any 172.16.40.1 0.0.0.0 LDAP Permit
40 any 172.16.40.2 0.0.0.0 NTP Permit
50 any 172.16.40.2 0.0.0.0 DNS Permit
60 any 172.16.40.2 0.0.0.0 LDAP Permit
70 172.16.10.0 0.0.0.255 172.16.40.14 0.0.0.0 8005 Permit
80 172.16.10.251 0.0.0.0 172.16.40.3 0.0.0.0 873 Permit
90 any 172.16.0.0 0.0.255.255 TCP (est.) Permit
100 any 172.16.0.0 0.0.255.255 ip Deny
110 any any ip PermitIn diesem VLAN (10) sind einige Netzwerkgeräte, zu denen oder von denen Verbindungen aus / hin initiiert werden.
Regel 10 - 60 wäre nur dafür da, dass sich die Geräte in dem VLAN mit unseren zwei DCs connecten können (DNS, NTP & LDAP). DHCP ist in diesem VLAN nicht angewendet.
Regel 70 lässt die Verbindung zu einem unserer Servern auf Port 8005 zu.
Regel 80 lässt unsere QNAP einen Sync mit einer anderen QNAP in einem anderen VLAN zu.
Regel 90 lässt den von den Clients initiierten Traffic wieder zurückfließen, sollte er established sein.
Regel 100 untersagt VLAN 10 die Kommunikation zu allen anderen VLANs.
Regel 110 lässt sonstigen Verkehr (bspw. Internet) zu.
Ist das so alles in Ordnung, oder habe ich hier einen groben Schnitzer drin?
Freue mich über Euer Feedback!
VG Fred
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5122675628
Url: https://administrator.de/forum/acls-fuer-vlan-eure-meinung-5122675628.html
Ausgedruckt am: 21.04.2025 um 13:04 Uhr
12 Kommentare
Neuester Kommentar
unser Netzwerk in diverse VLANs unterteilt und bin nun an dem Thema ACLs dran.
Sehr löblich!Einen groben Kardinalsfehler den du begangen hast ist das du als Source "any" beim VLAN 10 angegeben hast. Das bewirkt das jede beliebige Absender IP Adresse hier aus dem VLAN 10 passieren kann was sicher nicht deine Intention ist, oder?
Das ist natürlich ein sträfliches Sicherheitsloch, denn du willst ja, wenn du schon ACLs nutzt, diese auch sicher machen!
Hier sollte als Source also immer "vlan10_net" stehen sofern du einen Alias benutzt oder eben 172.16.10.0 mask 0.0.0.255 sofern dein VLAN 10 Netz 172.16.10.0 /24 lautet. So können auch nur Clients die korrekte Absender IPs aus dem VLAN 10 nutzen die ACL auch passieren, andere nicht.
Etwas wirr bzw. logisch unverständlich ist auch dein "permit any" Statement am Schluss. Damit führst du die vorherigen Protokoll spezifischen DNS, LDAP und NTP Permits am Anfang völlig ad absurdum wenn du nachträglich so oder ja ala Scheunentor alles erlaubst. Die wären damit dann komplett überflüssig.
Versucht man sich den Sinn dieser ACL zu erschliessen geht es dir (geraten) ja nur darum VLAN 10 initiierten IP Traffic in alle ausgehenden 172.16.0.0 /16er Netz zu verbieten aber TCP Traffic der von außen ins VLAN 10 kommt (Established) aus den 172.16ern zu erlauben.
Das wäre dann ein simpler 3 Zeiler:
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255 EQ: TCP established
Deny = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: ANY
Müssen aus dem VLAN 10 Segment ggf. noch DHCP Request Frames passieren wenn kein lokaler DHCP Server vorhanden ist, musst du die ACL noch etwas anpassen.
DHCP nutzt initial beim Client Request als Absender IP 0.0.0.0 und als Destination einen all Net Broadcast 255.255.255.255 um eine Adresse zu requesten. Destination Port ist UDP 67. Wireshark ist hier, wie immer, dein bester Freund! 😉
Permit = Source: 0.0.0.0 mask: 0.0.0.0 Dest: 255.255.255.255 mask: 0.0.0.0 EQ: 67
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255 EQ: TCP established
Deny = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: ANY
Das bewirkt dann das DHCP und von außen initiierter TCP mit 172.16er Absender Adressen sowie aller anderer IP Verkehr aus dem VLAN 10 erlaubt ist. Nur initiierter IP Traffic in alle 172.16er Netze ist geblockt.
Fertisch...
Deine Logik scheint darauf aufzubauen, dass böse Kommunikation immer zu Standardports läuft.
Das ist richtig, aber anders als du dir das vorstellst.
Ein Angreifer wird über die Ports 21,22,53,80,443 usw kommunizieren und du musst dann sicherstellen, dass das auch der richtige Payload drin ist. Bei 53 fällt es auf, wenn viele Gigabyte hochgeladen werden.
Aber willst stellst du sicher, dass über 443 nicht eine Steuerung deiner IT samt Up- und Downloads deiner Daten läuft?
Fast jeder ernstzunehmende Angriff läuft über Schwachstellen in bestehender Software die bereits im Haus ist.
Das ist richtig, aber anders als du dir das vorstellst.
Ein Angreifer wird über die Ports 21,22,53,80,443 usw kommunizieren und du musst dann sicherstellen, dass das auch der richtige Payload drin ist. Bei 53 fällt es auf, wenn viele Gigabyte hochgeladen werden.
Aber willst stellst du sicher, dass über 443 nicht eine Steuerung deiner IT samt Up- und Downloads deiner Daten läuft?
Fast jeder ernstzunehmende Angriff läuft über Schwachstellen in bestehender Software die bereits im Haus ist.
Zitat von @aqui:
Einen groben Kardinalsfehler den du begangen hast ist das du als Source "any" beim VLAN 10 angegeben hast. Das bewirkt das jede beliebige Absender IP Adresse hier aus dem VLAN 10 passieren kann was sicher nicht deine Intention ist, oder?
Einen groben Kardinalsfehler den du begangen hast ist das du als Source "any" beim VLAN 10 angegeben hast. Das bewirkt das jede beliebige Absender IP Adresse hier aus dem VLAN 10 passieren kann was sicher nicht deine Intention ist, oder?
Danke, ja, war nicht gewollt.
Versucht man sich den Sinn dieser ACL zu erschliessen geht es dir (geraten) ja nur darum VLAN 10 initiierten IP Traffic in alle ausgehenden 172.16.0.0 /16er Netz zu verbieten aber TCP Traffic der von außen ins VLAN 10 kommt (Established) aus den 172.16ern zu erlauben.
Das wäre dann ein simpler 3 Zeiler:
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255 EQ: TCP established
Deny = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: ANY
Das wäre dann ein simpler 3 Zeiler:
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255 EQ: TCP established
Deny = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: ANY
Müsste die Deny Rule, nicht mit Source `any` starten, um alles was in dem VLAN 10 unterwegs ist, das passieren zu untersagen?
Müssen aus dem Segment ggf. noch DHCP Frames passieren wenn kein lokaler DHCP Server vorhanden ist, musst du die ACL noch etwas anpassen. DHCP nutzt initial als Absender IP 0.0.0.0 und als Destination einen all Net Broadcast 255.255.255.255 um eine Adresse zu requesten. Destination Port ist UDP 67. Wireshark ist hier, wie immer, dein bester Freund! 😉
Permit = Source: 0.0.0.0 mask: 0.0.0.0 Dest: 255.255.255.255 mask: 0.0.0.0 EQ: 67
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255 EQ: TCP established
Deny = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: ANY
Permit = Source: 0.0.0.0 mask: 0.0.0.0 Dest: 255.255.255.255 mask: 0.0.0.0 EQ: 67
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255 EQ: TCP established
Deny = Source: 172.16.10.0 mask: 0.0.0.255 Dest: 172.16.0.0 mask: 0.0.255.255
Permit = Source: 172.16.10.0 mask: 0.0.0.255 Dest: ANY
Gebe ich Dir Recht, aber in dem VLAN 10 muss in diesem Fall kein DHCP Traffic durch.
VG Fred
Müsste die Deny Rule, nicht mit Source `any` starten, um alles was in dem VLAN 10 unterwegs ist, das passieren zu untersagen?
Jein!Das kommt immer ganz darauf an WELCHE explizite Default ACL Regel dein Endgerät aktiv hat.
Generell ist es so das wenn nicht anders definiert, immer ein explizites deny any any am Interface aktiv ist sofern dort eine ACL vorhanden ist. Auch wenn diese leer ist gilt am Ende dann immer deny any any.
Wie du siehst inkludiert das ja immer ein "deny any" der Absender IP generell. Das muss man dann nicht mehr explizit angeben.
aber in dem VLAN 10 muss in diesem Fall kein DHCP Traffic durch.
Dann bleibt es bei dem einfachen Dreizeiler. 😉
Vielen Dank!
Vielen Dank!
Zitat von @aqui:
Das kommt immer ganz darauf an WELCHE explizite Default ACL Regel dein Endgerät aktiv hat.
Generell ist es so das wenn nicht anders definiert, immer ein explizites deny any any am Interface aktiv ist sofern dort eine ACL vorhanden ist. Auch wenn diese leer ist gilt am Ende dann immer deny any any.
Wie du siehst inkludiert das ja immer ein "deny any" der Absender IP generell. Das muss man dann nicht mehr explizit angeben.
Müsste die Deny Rule, nicht mit Source `any` starten, um alles was in dem VLAN 10 unterwegs ist, das passieren zu untersagen?
Jein!Das kommt immer ganz darauf an WELCHE explizite Default ACL Regel dein Endgerät aktiv hat.
Generell ist es so das wenn nicht anders definiert, immer ein explizites deny any any am Interface aktiv ist sofern dort eine ACL vorhanden ist. Auch wenn diese leer ist gilt am Ende dann immer deny any any.
Wie du siehst inkludiert das ja immer ein "deny any" der Absender IP generell. Das muss man dann nicht mehr explizit angeben.
aber in dem VLAN 10 muss in diesem Fall kein DHCP Traffic durch.
Dann bleibt es bei dem einfachen Dreizeiler. 😉Vielen Dank!
Immer gerne!
Und...bitte beim nächsten Mal nicht immer alles komplett zitieren. Wir alle hier haben ein gutes Gedächtnis und wissen ja immer was wir geschrieben haben! 😉
Und...bitte beim nächsten Mal nicht immer alles komplett zitieren. Wir alle hier haben ein gutes Gedächtnis und wissen ja immer was wir geschrieben haben! 😉
Ich würde die Frage ob Switch ACL oder doch lieber Firewall in den Raum werfen. Je mehr VLANs, Switche, Server und Protokolle dazu kommen, desto komplexer und unübersichtlicher wird das Ganze.
Bedenke, du musst das auf jedem Switch umsetzen damit es funktioniert. Oft ist die Steuerung der Zugriffe mit einer Firewall leichter und effizienter, vor allem bei der Fehlersuche.
Bedenke, du musst das auf jedem Switch umsetzen damit es funktioniert. Oft ist die Steuerung der Zugriffe mit einer Firewall leichter und effizienter, vor allem bei der Fehlersuche.
1Bedenke, du musst das auf jedem Switch umsetzen damit es funktioniert.
Das ist so nicht ganz richtig. Er nutzt ja IP basierte ACLs also Layer 3 ACLs an L3 VLAN IP Interfaces.Die müssen lediglich immer nur auf dem zentralen Core Switch aktiv sein der die VLANs routet und keineswegs auf allen Switches. Dies würde nur für Mac basierte Layer 2 ACLs gelten die der TO ja aber nicht hat.
Für eine überschaubare Anzahl an VLANs bzw. Security Regeln ist das also ein durchaus gangbarer Weg.
@aqui ich kann keine Info darüber finden, wie das Netzwerk bei dem TO aufgebaut ist. IP basierte ACL können auch viele L2-Switche verarbeiten, zumindest die, die ein "+" oder "Smart" im Namen haben. Dazu bedarf es also keines "vollwertigen" L3-Switches/Routers.
Da hast du zweifelsohne Recht was den Aufbau anbetrifft. Dann hoffen wir mal des Beste das er das wirklich an den L3 Interfaces implementiert hat was in der Tat eine Annahme war.
Für den anderen Fall hast du recht. Da müsste er es dann an jedem Switch und je nach Regelwerk dann auch an mehreren Ports umsetzen. Normal macht das aber kein verantwortungsvoller Netzwerk Admin. 😉
Für den anderen Fall hast du recht. Da müsste er es dann an jedem Switch und je nach Regelwerk dann auch an mehreren Ports umsetzen. Normal macht das aber kein verantwortungsvoller Netzwerk Admin. 😉
Um Euch zu beruhigen, @aqui, deine Annahme war richtig ;) Die ACLs werden am L3-Core Switch konfiguriert.
Und die Frage Firewall oder ACL stellt sich bei uns nicht, da wir es kombiniert einsetzen. Wir möchten nur nicht, dass der ganze Traffic ungefiltert an der Firewall ankommt. Die Firewall filtert alles was von außen reinkommt und nach außen will, interner Traffic wird durch den Core Switch geroutet und gefiltert.
Und die Frage Firewall oder ACL stellt sich bei uns nicht, da wir es kombiniert einsetzen. Wir möchten nur nicht, dass der ganze Traffic ungefiltert an der Firewall ankommt. Die Firewall filtert alles was von außen reinkommt und nach außen will, interner Traffic wird durch den Core Switch geroutet und gefiltert.
Wir möchten nur nicht, dass der ganze Traffic ungefiltert an der Firewall ankommt.
Da sind ACLs dann auch immer der richtige Weg! 👍
