Die korrekte Platzierung von ACLs gehört zu den wichtigsten Grundlagen in Cisco-Netzwerken. Eine Access Control List kann technisch vollkommen korrekt geschrieben sein und trotzdem unerwünschte Ergebnisse liefern, wenn sie am falschen Interface oder in der falschen Richtung eingesetzt wird. Genau deshalb reicht es nicht aus, nur die Syntax von Standard- und Extended-ACLs zu kennen. Entscheidend ist auch, wo eine ACL im Netzwerk wirkt. In der Praxis beeinflusst die Platzierung nicht nur die Sicherheit, sondern auch Performance, Fehlersuche, Übersichtlichkeit und das gesamte Verhalten des Datenverkehrs. Wer ACLs richtig platzieren kann, setzt Traffic-Kontrolle nicht nur technisch, sondern auch logisch sauber um.
Warum die Platzierung von ACLs so wichtig ist
Eine ACL filtert Pakete nicht irgendwo abstrakt im Netzwerk, sondern immer an einer ganz konkreten Stelle: an einem Interface, in einer bestimmten Richtung oder bei speziellen Diensten wie den VTY-Lines. Genau diese Position entscheidet darüber, wann ein Paket geprüft wird und welcher Traffic davon betroffen ist.
Wird eine ACL zu früh eingesetzt, kann sie mehr Verkehr blockieren als geplant. Wird sie zu spät platziert, läuft unerwünschter Traffic möglicherweise bereits durch mehrere Netzwerksegmente, bevor er überhaupt gefiltert wird. Im schlimmsten Fall entsteht dadurch unnötige Last, unübersichtliches Troubleshooting oder eine Sicherheitslücke.
Auswirkungen einer falschen Platzierung
- Legitimer Traffic wird versehentlich blockiert
- Unerwünschter Traffic wird zu spät oder gar nicht gefiltert
- Bandbreite und Router-Ressourcen werden unnötig belastet
- Fehlersuche wird deutlich komplizierter
- ACL-Regeln wirken unlogisch oder schwer nachvollziehbar
Grundprinzip: ACLs wirken immer an einer konkreten Stelle
Eine ACL wird in Cisco-Netzwerken typischerweise an einem Layer-3-Interface angewendet. Dabei muss nicht nur das richtige Interface gewählt werden, sondern auch die Richtung: inbound oder outbound. Dieselbe ACL kann je nach Richtung völlig unterschiedliche Auswirkungen haben.
Was inbound bedeutet
Eine inbound angewendete ACL prüft Pakete, sobald sie ein Interface betreten. Die Filterentscheidung fällt also früh, noch bevor der Router das Paket weiterverarbeitet oder eine Routing-Entscheidung trifft.
interface GigabitEthernet0/0
ip access-group 101 in
In diesem Beispiel wird ACL 101 auf eingehenden Verkehr an GigabitEthernet0/0 angewendet.
Was outbound bedeutet
Eine outbound angewendete ACL prüft Pakete erst, bevor sie ein Interface verlassen. Der Router hat das Paket dann bereits verarbeitet und entschieden, über welches Interface es weitergeleitet wird.
interface GigabitEthernet0/1
ip access-group 101 out
Hier filtert dieselbe ACL den ausgehenden Traffic auf GigabitEthernet0/1.
Warum diese Unterscheidung entscheidend ist
- Inbound filtert früh im Pfad
- Outbound filtert spät im Pfad
- Je nach Richtung kann die ACL mehr oder weniger Traffic erfassen
- Die gleiche Regel kann an anderer Stelle völlig anders wirken
Die wichtigste Cisco-Regel zur ACL-Platzierung
Für die Platzierung von ACLs gibt es in Cisco-Netzwerken eine klassische Designregel, die jeder Network Engineer kennen sollte:
- Standard ACLs möglichst nah am Ziel platzieren
- Extended ACLs möglichst nah an der Quelle platzieren
Diese Regel ist keine willkürliche Lernhilfe, sondern ergibt sich direkt aus der Funktionsweise der beiden ACL-Typen.
Warum Standard ACLs nahe am Ziel platziert werden
Eine Standard ACL kann nur die Quell-IP-Adresse prüfen. Sie weiß also nicht, wohin das Paket eigentlich gehen soll, welches Protokoll verwendet wird oder ob nur ein bestimmter Dienst betroffen sein sollte. Genau deshalb ist sie relativ grob.
Wenn man eine Standard ACL zu nah an der Quelle platziert, kann sie unbeabsichtigt sämtlichen Traffic eines Quellnetzes blockieren, auch wenn eigentlich nur ein bestimmtes Ziel geschützt werden sollte. Platziert man sie dagegen näher am Ziel, wird nur der Verkehr gefiltert, der dieses Ziel tatsächlich erreichen möchte.
Beispiel zur Logik
Angenommen, das Netz 192.168.10.0/24 soll nicht auf Servernetz A zugreifen dürfen, aber weiterhin auf andere Netze. Eine Standard ACL direkt am Ausgang des Quellnetzes wäre problematisch, weil sie nicht unterscheiden kann, ob das Paket zu Servernetz A oder zu einem anderen Ziel geht.
Besser ist eine Platzierung näher am Zielnetz, sodass nur der Verkehr in Richtung dieses Zielnetzes gefiltert wird.
Typische Regel für Standard ACLs
- Quellenfilterung möglichst nah am geschützten Ziel
- Vermeidung unnötiger Seiteneffekte auf andere Kommunikationspfade
- Einsatz vor allem für einfache Zugriffsbeschränkungen oder Management-Schutz
Warum Extended ACLs nahe an der Quelle platziert werden
Eine Extended ACL kann deutlich präziser filtern. Sie kennt Quelle, Ziel, Protokoll und Port. Dadurch kann sie sehr genau festlegen, welcher Traffic blockiert oder erlaubt werden soll. Diese Präzision macht es sinnvoll, unerwünschten Verkehr möglichst früh im Netzwerk zu stoppen.
Wird eine Extended ACL nahe an der Quelle eingesetzt, läuft unerwünschter Traffic gar nicht erst durch das restliche Netzwerk. Das spart Bandbreite, reduziert Last auf Zwischenstationen und sorgt für ein klareres Sicherheitsdesign.
Typische Vorteile dieser Platzierung
- Unerwünschter Traffic wird früh gestoppt
- Netzwerkressourcen werden geschont
- Die Policy ist oft leichter verständlich
- Fehlersuche wird einfacher, weil der Blockpunkt logisch nahe an der Quelle liegt
Beispiel
Wenn Clients aus 192.168.20.0/24 keinen SSH-Zugriff auf ein Servernetz erhalten sollen, ist es meist sinnvoll, diesen SSH-Traffic bereits am Eingang vom Clientnetz zu filtern, statt erst kurz vor dem Zielserver.
ip access-list extended BLOCK-SSH
deny tcp 192.168.20.0 0.0.0.255 192.168.100.0 0.0.0.255 eq 22
permit ip any any
ACL-Platzierung in typischen Netzwerkszenarien
Zwischen zwei VLANs auf einem Layer-3-Switch
In VLAN-Umgebungen mit Inter-VLAN-Routing auf einem Layer-3-Switch werden ACLs häufig direkt auf SVI-Interfaces angewendet. Dort muss genau entschieden werden, auf welchem VLAN-Interface und in welcher Richtung gefiltert wird.
Wenn ein Client-VLAN nur eingeschränkt auf ein Server-VLAN zugreifen darf, ist eine Extended ACL meist auf dem SVI des Client-VLANs inbound sinnvoll. So wird der unerwünschte Traffic schon beim Eintritt in das Routing gestoppt.
interface Vlan20
ip access-group CLIENT-FILTER in
Warum diese Platzierung sinnvoll ist
- Verkehr wird früh im Routing-Prozess gefiltert
- Nur das betreffende Quell-VLAN wird kontrolliert
- Die ACL bleibt logisch dem Ursprungssegment zugeordnet
Vor einem sensiblen Servernetz
Wenn mehrere Quellnetze auf ein sensibles Zielnetz zugreifen, kann eine Platzierung nah am Ziel sinnvoll sein, insbesondere bei Standard ACLs oder bei Schutzlogik, die sich klar auf das Zielsegment bezieht.
In diesem Fall wird die ACL oft outbound auf dem Interface zum Servernetz oder inbound auf dem Ziel-SVI angewendet, je nach Topologie und gewünschter Logik.
Am WAN- oder Internet-Edge
ACLs am WAN-Edge werden oft eingesetzt, um ein- oder ausgehenden Traffic gegenüber dem Internet einzuschränken. Hier ist die Platzierung besonders sensibel, weil falsche Regeln schnell große Auswirkungen auf den Standort haben können.
- Eingehende ACLs am Internet-Interface können unerwünschten Traffic früh blockieren
- Ausgehende ACLs können definieren, welche internen Dienste das WAN verlassen dürfen
- Bei NAT-Umgebungen muss die ACL-Platzierung sauber mit Routing und NAT-Logik abgestimmt werden
Inbound oder outbound richtig wählen
Die Frage nach inbound oder outbound ist oft wichtiger als die Frage nach dem Interface selbst. In vielen Fällen wäre dieselbe ACL technisch auf mehreren Interfaces anwendbar, aber nur eine Richtung ergibt logisch Sinn.
Wann inbound meist sinnvoll ist
- Wenn unerwünschter Traffic möglichst früh gestoppt werden soll
- Bei Extended ACLs nahe an der Quelle
- Wenn klar ist, welches Quellsegment kontrolliert werden soll
- Wenn Bandbreite und CPU geschont werden sollen
Wann outbound sinnvoll sein kann
- Wenn gezielt ein Zielinterface geschützt werden soll
- Bei Standard ACLs nahe am Ziel
- Wenn dieselbe Policy für mehrere eingehende Pfade auf ein Ziel zusammenlaufen soll
- Wenn der Datenverkehr erst nach der Routing-Entscheidung sinnvoll filterbar ist
Praxisgedanke
Inbound ist oft effizienter, outbound kann aber logischer sein, wenn ein bestimmtes Zielsegment geschützt werden soll. Die korrekte Wahl hängt immer vom Designziel ab.
Standard ACLs richtig platzieren
Da Standard ACLs nur die Quelle kennen, sollten sie mit besonderer Vorsicht eingesetzt werden. Sie eignen sich nicht für feingranulare Steuerung zwischen mehreren Zielen. Ihr typischer Platz ist dort, wo eine reine Quellenkontrolle ausreicht.
Typische sinnvolle Platzierungen
- Auf VTY-Lines für Management-Zugriff
- Nah am Zielnetz, wenn nur bestimmte Quellen dieses Ziel nicht erreichen dürfen
- In NAT-Konfigurationen als Matching-Kriterium
Beispiel für VTY-Schutz
access-list 15 permit 10.10.10.0 0.0.0.255
line vty 0 4
access-class 15 in
transport input ssh
Hier ist die ACL nicht auf einem Routing-Interface platziert, sondern direkt auf den VTY-Lines. Das ist eine sehr typische und korrekte Anwendung für eine Standard ACL.
Typischer Fehler bei Standard ACLs
Eine Standard ACL wird direkt am Quellinterface platziert, obwohl nur ein bestimmtes Ziel geschützt werden sollte. Dadurch wird sämtlicher Traffic der Quelle blockiert, auch zu anderen legitimen Zielen.
Extended ACLs richtig platzieren
Extended ACLs sind für präzise Segmentierungs- und Sicherheitsregeln gedacht. Daher werden sie meist nahe an der Quelle platziert. So wird genau der unerwünschte Traffic gestoppt, ohne unnötig viele andere Kommunikationspfade zu beeinflussen.
Typische sinnvolle Platzierungen
- Inbound auf dem Client-VLAN
- Ingress auf einem Router-Interface in Richtung Quellnetz
- Am Eintrittspunkt eines Gast- oder IoT-Netzes
- Früh im Pfad zu einem WAN- oder Serverzugriff
Beispiel: Gastnetz darf nicht ins interne Servernetz
ip access-list extended GUEST-BLOCK
deny ip 192.168.50.0 0.0.0.255 192.168.100.0 0.0.0.255
permit ip 192.168.50.0 0.0.0.255 any
interface Vlan50
ip access-group GUEST-BLOCK in
Diese Platzierung ist logisch sauber, weil der unerwünschte Traffic direkt aus dem Gastnetz heraus gestoppt wird.
ACLs in Hub-and-Spoke- und Campus-Designs
In größeren Netzwerken mit mehreren Standorten oder einer Campus-Struktur wird ACL-Platzierung schnell zu einer Designfrage. Hier reicht es oft nicht mehr, nur die Cisco-Grundregel auswendig zu kennen. Vielmehr muss überlegt werden, ob eine ACL lokal am Access-Layer, zentral am Distribution-Layer oder am WAN-Edge sinnvoller ist.
Lokale Platzierung im Access- oder Quellsegment
- Geeignet für segmentbezogene Policies
- Frühes Stoppen unerwünschten Traffics
- Oft gut für Gast-, IoT- oder Client-VLANs
Zentrale Platzierung am Ziel oder Core
- Geeignet für Schutz weniger zentraler Zielnetze
- Hilfreich, wenn viele Quellen auf dieselben Ziele zugreifen
- Kann die Policy zentralisieren, aber weniger effizient machen
Wichtiger Design-Hinweis
Je verteilter das Netzwerk ist, desto wichtiger wird eine klare Dokumentation. Eine ACL kann technisch korrekt platziert sein, aber ohne Designlogik und Dokumentation später schwer verständlich werden.
ACLs und NAT gemeinsam betrachten
In Cisco-Netzwerken spielen ACLs oft auch im Zusammenhang mit NAT eine Rolle. Dabei ist wichtig zu verstehen, dass eine ACL für NAT nicht zwingend denselben Zweck erfüllt wie eine ACL zur Sicherheitsfilterung. In NAT-Designs beschreibt eine ACL oft nur, welche Quellnetze übersetzt werden sollen.
Beispiel für ACL im NAT-Kontext
access-list 1 permit 192.168.10.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/1 overload
Diese ACL kontrolliert nicht direkt den Paketfluss auf einem Interface, sondern definiert die Quellen, die für NAT Overload verwendet werden.
Wichtige Folge für die Platzierung
Man muss klar trennen zwischen:
- ACLs als Matching-Kriterium für NAT
- ACLs als echte Sicherheits- oder Filterregel auf Interfaces
Beides sind ACLs, aber sie erfüllen unterschiedliche Aufgaben.
Häufige Fehler bei der ACL-Platzierung
Viele ACL-Probleme entstehen nicht durch die Regel selbst, sondern durch die falsche Platzierung. Gerade in Prüfungen und im Betrieb führt das immer wieder zu Fehlinterpretationen.
Typische Fehlerquellen
- Standard ACL zu nah an der Quelle platziert
- Extended ACL zu weit weg vom Quellsegment platziert
- Richtung in/out falsch gewählt
- ACL auf das falsche Interface angewendet
- Mehrere ACLs greifen ungewollt ineinander
- Die Designlogik ist nicht dokumentiert
Typischer Praxisfehler
Ein Administrator möchte nur den Zugriff eines Benutzer-VLANs auf einen Webserver blockieren, platziert aber eine Standard ACL direkt inbound auf dem Benutzer-SVI. Ergebnis: Das VLAN verliert unter Umständen den Zugriff auf viele weitere Netze, nicht nur auf den Webserver.
So findet man die richtige ACL-Platzierung
Bevor eine ACL geschrieben wird, sollte zuerst die Verkehrslogik geklärt werden. Die Frage lautet nicht nur „Was soll blockiert werden?“, sondern vor allem:
- Wo entsteht dieser Traffic?
- Welches Ziel soll geschützt werden?
- Reicht eine Quellenfilterung oder ist präzise Steuerung nötig?
- Soll unerwünschter Traffic früh oder zentral gestoppt werden?
Praktische Denkfolge
- Quellnetz identifizieren
- Zielnetz oder Zielsystem identifizieren
- Notwendige Genauigkeit festlegen: Standard oder Extended ACL
- Entscheiden, ob früh oder zielnah gefiltert werden soll
- Interface und Richtung bewusst auswählen
ACLs überprüfen und verifizieren
Nach der Platzierung muss immer kontrolliert werden, ob die ACL tatsächlich dort aktiv ist, wo sie vorgesehen war, und ob sie in der richtigen Richtung greift. Cisco IOS bietet dafür mehrere hilfreiche Show-Befehle.
Wichtige Befehle zur Kontrolle
show access-lists
show ip interface
show running-config | section access-list
show running-config | section ip access-group
Was damit geprüft werden sollte
- Ist die ACL inhaltlich korrekt?
- Ist sie dem richtigen Interface zugeordnet?
- Wurde die richtige Richtung gewählt?
- Treffen Pakete auf die erwarteten ACL-Zeilen?
- Blockiert die ACL genau den gewünschten Traffic?
show ip interface als Praxiswerkzeug
Dieser Befehl ist besonders hilfreich, weil er zeigt, ob auf einem Interface eine ACL inbound oder outbound aktiv ist. Gerade bei Platzierungsfehlern ist das oft der schnellste Kontrollpunkt.
show ip interface GigabitEthernet0/0
Best Practices für die Platzierung von ACLs im Netzwerk
Eine gute ACL-Platzierung folgt nicht nur Cisco-Grundregeln, sondern auch einem konsistenten Designansatz. Ziel ist, dass die Filterlogik technisch wirksam, ressourcenschonend und für andere Administratoren nachvollziehbar bleibt.
Bewährte Empfehlungen
- Standard ACLs möglichst nah am Ziel einsetzen
- Extended ACLs möglichst nah an der Quelle einsetzen
- Richtung inbound/outbound immer bewusst wählen
- ACLs nicht nur technisch, sondern logisch dokumentieren
- Trefferzähler und Show-Befehle zur Verifikation nutzen
- Bei komplexeren Designs zuerst den Verkehrsfluss skizzieren
Praxisnaher Denkansatz
Die beste ACL-Platzierung ist nicht automatisch die nächstliegende Stelle im Netzwerk, sondern die Position, an der die gewünschte Policy mit möglichst wenig Nebenwirkungen und möglichst hoher Klarheit umgesetzt wird. Genau dieser Unterschied trennt reine Syntax-Kenntnis von professionellem Netzwerkdesign.
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3
Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.
Meine Leistungen umfassen:
-
Professionelle Konfiguration von Routern und Switches
-
Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen
-
Erstellung von Topologien und Simulationen in Cisco Packet Tracer
-
Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG
-
Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible
-
Erstellung von Skripten für wiederkehrende Netzwerkaufgaben
-
Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege
-
Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting
Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.
