5
ACL-Design - Deny in mehreren VLANs
Hallo zusammen,
ich habe zum ACL-Design auf einem Aruba 3810M eine Verständnisfrage.
Wir verwenden Inbound-ACLs je VLAN und eine ACL, die den Clients nur den Zugriff auf das Subnetz 10.10.100.0/24 nicht erlaubt sieht dann so aus:
Das Subnetz 10.10.100.0/24 ist ebenfalls ein VLAN, jedoch sieht unsere Konfiguration vor, dass wir bereits an der Quelle die Kommunikation unterbinden (Inbound im Source-VLAN). Ist das so korrekt?
Wir haben nun mehrere VLANs die mit diesem Subnetz nicht kommunizieren sollen, ist hier der einzig sinnvolle weg je VLAN dieses Subnetz mit deny zu verbieten?
ich habe zum ACL-Design auf einem Aruba 3810M eine Verständnisfrage.
Wir verwenden Inbound-ACLs je VLAN und eine ACL, die den Clients nur den Zugriff auf das Subnetz 10.10.100.0/24 nicht erlaubt sieht dann so aus:
ip access-list extended "ACL-In-Client"
permit tcp any any established
deny ip any 10.10.100.0/24
permit ip any any
exitDas Subnetz 10.10.100.0/24 ist ebenfalls ein VLAN, jedoch sieht unsere Konfiguration vor, dass wir bereits an der Quelle die Kommunikation unterbinden (Inbound im Source-VLAN). Ist das so korrekt?
Wir haben nun mehrere VLANs die mit diesem Subnetz nicht kommunizieren sollen, ist hier der einzig sinnvolle weg je VLAN dieses Subnetz mit deny zu verbieten?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2465980678
Url: https://administrator.de/forum/acl-design-deny-in-mehreren-vlans-2465980678.html
Ausgedruckt am: 24.12.2024 um 16:12 Uhr
5 Kommentare
Neuester Kommentar
Ich hätte hier auch nochmal gerne einen Ratschlag, wie man die ACLs am besten konstruiert. Erstelle ich besser eine ACL für gleichartige VLANs (z.B. WLAN-Clients, LAN-Clients, etc.) und arbeite in den VLANs dann mit Quellnetzen, um die Unterschiede zwischen den VLANs konfigurieren zu können?
Ist das so korrekt?
Ja, das ist korrekt und auch best Practise. Es wäre ja auch unsinnig nicht gewollten Traffic in den Switch zu lassen um ihn dann da wieder umständlich rauszufiltern. Abgesehen davon sind outbound ACLs oftmal Process switched, werden also in CPU abgearbeitet anstatt in Silizium in den Asics. Ganz besonders bei Billigheimern ist das der Fall. Oftmal supporten die auch deshalb keine outbound ACLs.ist hier der einzig sinnvolle weg je VLAN dieses Subnetz mit deny zu verbieten?
Ja, wie sollte es auch anders gehen?! Ist bei Firewalls ja identisch.Ich hätte hier auch nochmal gerne einen Ratschlag
Das ist nicht zu beantworten ohne deine genauen Anforderungen ans Regelwerk zu kennen. Meistens sind ja die Filter Anforderungen pro Router IP Interface individuell so das es auch individuelle ACLs sind.
1
Vielen Dank, mir ist klar geworden, dass unser Konzept so Best Practice ist.
Ergänzend habe ich noch ein paar Detailfragen, über ein Feedback würde ich mich freuen
1. UDP bei RDP
Ich habe die Anforderung in einigen VLANs eingehendes RDP zuzulassen, hier wird UDP und TCP verwendet. Die UDP-Antwortpakete werden standardmäßig geblockt, kann/sollte ich diese so freigeben:
Mir fehlt hier die Einschränkung, denn theoretisch könnte ja jeder über 3389/UDP mit jedem kommunizieren, andererseits gibt es bei UDP kein established und es sind viele Subnetze die in Frage kommen.
2. ACL-Handling
Bisher bin ich so vorgegangen, dass ich die ACLs in einer Textdatei in "gewöhnlicher" Notation pflege:
Und dann jedesmal die ACL neu anlege:
Gibt es irgendein Tool, womit man die ACLs übersichtlicher dokumentieren kann?
Ergänzend habe ich noch ein paar Detailfragen, über ein Feedback würde ich mich freuen
1. UDP bei RDP
Ich habe die Anforderung in einigen VLANs eingehendes RDP zuzulassen, hier wird UDP und TCP verwendet. Die UDP-Antwortpakete werden standardmäßig geblockt, kann/sollte ich diese so freigeben:
permit udp any eq 3389 anyMir fehlt hier die Einschränkung, denn theoretisch könnte ja jeder über 3389/UDP mit jedem kommunizieren, andererseits gibt es bei UDP kein established und es sind viele Subnetze die in Frage kommen.
2. ACL-Handling
Bisher bin ich so vorgegangen, dass ich die ACLs in einer Textdatei in "gewöhnlicher" Notation pflege:
deny tcp any 10.1.1.0/24 eq 3389 logUnd dann jedesmal die ACL neu anlege:
no ip access-list extended "In-Client"
ip access-list extended "In-Client" Gibt es irgendein Tool, womit man die ACLs übersichtlicher dokumentieren kann?
1.)
Wenn du Interface oder IP spezifische ACLs vermeiden willst ala "permit udp <souce_host/network> eq 3389 any (oder <destination_host/network> " die diesbezüglich sicherer sind weil sie Allerwelts Absender- und Zieladressen ausschliessen die es in dem jeweiligen Netz natürlich nicht geben sollte, dann ist diese "Schrotschuss" Variante für alle IP Interfaces deine einzige Option. Wie sollte es auch anders gehen...?!
Hier musst du also selber nach deiner Security Policy entscheiden welchen Weg du da gehst bzw. ob dir Einfachheit mehr wert ist als Sicherheit oder umgekehrt. Nur deine eigene Policy schreibt dir vor was wie zu regeln ist und bestimmt dann die ACL Umsetzung.
2.)
Sinnvoll wäre bei ACLs immer eine Sequence Number zu verwenden sofern die HP Gurken sowas überhaupt supporten. Damit ist eine Steuerung der Reihenfolge deutlich einfacher.
Ein "ACL Tool" ist mir nicht bekannt.
Wenn du Interface oder IP spezifische ACLs vermeiden willst ala "permit udp <souce_host/network> eq 3389 any (oder <destination_host/network> " die diesbezüglich sicherer sind weil sie Allerwelts Absender- und Zieladressen ausschliessen die es in dem jeweiligen Netz natürlich nicht geben sollte, dann ist diese "Schrotschuss" Variante für alle IP Interfaces deine einzige Option. Wie sollte es auch anders gehen...?!
Hier musst du also selber nach deiner Security Policy entscheiden welchen Weg du da gehst bzw. ob dir Einfachheit mehr wert ist als Sicherheit oder umgekehrt. Nur deine eigene Policy schreibt dir vor was wie zu regeln ist und bestimmt dann die ACL Umsetzung.
2.)
Sinnvoll wäre bei ACLs immer eine Sequence Number zu verwenden sofern die HP Gurken sowas überhaupt supporten. Damit ist eine Steuerung der Reihenfolge deutlich einfacher.
Ein "ACL Tool" ist mir nicht bekannt.
Zitat von @aqui:
2.)
Sinnvoll wäre bei ACLs immer eine Sequence Number zu verwenden sofern die HP Gurken sowas überhaupt supporten. Damit ist eine Steuerung der Reihenfolge deutlich einfacher.
Ein "ACL Tool" ist mir nicht bekannt.
2.)
Sinnvoll wäre bei ACLs immer eine Sequence Number zu verwenden sofern die HP Gurken sowas überhaupt supporten. Damit ist eine Steuerung der Reihenfolge deutlich einfacher.
Ein "ACL Tool" ist mir nicht bekannt.
Die HP Gurken können das, so handhabe ich das auch bisher.
Danke für dein Feedback!
