10.4 ACLs richtig platzieren im Netzwerk

ACLs richtig im Netzwerk zu platzieren ist eine der wichtigsten Voraussetzungen dafür, dass Zugriffskontrolle nicht nur technisch vorhanden, sondern auch wirksam, übersichtlich und betrieblich sinnvoll ist. Viele Einsteiger lernen zunächst, wie eine Standard ACL oder eine erweiterte ACL aufgebaut wird und welche Regeln mit permit oder deny formuliert werden können. In der Praxis reicht dieses Wissen allein jedoch nicht aus. Eine ACL kann inhaltlich korrekt geschrieben sein und trotzdem am falschen Ort hängen. Dann blockiert sie zu viel, zu wenig oder an der falschen Stelle. Genau deshalb ist die Platzierung einer ACL ein zentrales Thema für CCNA, Netzwerkpraxis und Netzwerksicherheit. Ob eine Regel nah an der Quelle, nah am Ziel, eingehend oder ausgehend angewendet wird, beeinflusst direkt die Sicherheit, die Fehlersuche, die Netzlast und die Verständlichkeit des Designs. Wer ACLs richtig platziert, schafft kontrollierte Kommunikationsgrenzen, reduziert unnötigen Verkehr frühzeitig und baut ein Netz, das nicht nur funktioniert, sondern sich auch sauber absichern und warten lässt.

Table of Contents

Warum die Platzierung von ACLs so wichtig ist

Eine gute Regel kann am falschen Ort wirkungslos oder problematisch werden

Eine ACL besteht aus Regeln, die Datenverkehr erlauben oder blockieren. Diese Regeln wirken aber nie im luftleeren Raum. Sie werden an einer Schnittstelle, an einem VLAN-Interface oder an einem Managementzugang angewendet. Erst dort entscheidet sich, welche Pakete überhaupt von der ACL gesehen werden und in welchem Moment des Verkehrsflusses gefiltert wird.

  • Eine zu früh platzierte ACL kann legitimen Verkehr unnötig blockieren.
  • Eine zu spät platzierte ACL lässt unerwünschten Verkehr zu weit durchs Netz laufen.
  • Eine falsch gerichtete ACL greift möglicherweise gar nicht wie beabsichtigt.
  • Eine unklare Platzierung erschwert Audit und Troubleshooting erheblich.

Deshalb ist die Frage „Wo platziere ich die ACL?“ fast genauso wichtig wie „Wie schreibe ich die ACL?“.

ACL-Platzierung ist eine Designentscheidung, keine reine Syntaxfrage

Viele Anfänger konzentrieren sich verständlicherweise zuerst auf die Syntax. In realen Netzen ist die Syntax aber nur ein Teil der Aufgabe. Die eigentliche Netzwerksicherheit entsteht erst durch das Zusammenspiel aus Regelinhalt, Interface, Richtung und Zonenlogik. Gute ACL-Platzierung ist daher immer auch Netzdesign.

Wie ACLs grundsätzlich angewendet werden

ACLs wirken an Interfaces oder Zugängen

In Cisco-Umgebungen werden ACLs typischerweise an Layer-3-Interfaces, an SVIs oder an Managementzugängen wie VTY-Leitungen angewendet. Das bedeutet, dass sie nicht „irgendwo im Gerät“ aktiv sind, sondern immer an einem konkreten Kontrollpunkt.

Typische Einsatzorte sind:

  • physische Router-Interfaces
  • Subinterfaces bei Router-on-a-Stick
  • SVIs auf Layer-3-Switches
  • VTY-Leitungen für SSH-Zugriff

Diese Stellen definieren, an welchem Punkt des Datenpfads der Verkehr gefiltert wird.

Die Richtung entscheidet über den Prüfzeitpunkt

ACLs können eingehend oder ausgehend angewendet werden. „Eingehend“ bedeutet, dass Pakete beim Eintritt in das Interface geprüft werden. „Ausgehend“ bedeutet, dass sie beim Verlassen des Interfaces geprüft werden. Das ist mehr als ein technisches Detail, denn dieselbe ACL kann je nach Richtung völlig unterschiedlich wirken.

Beispiele:

interface gigabitethernet0/0
 ip access-group 110 in

interface gigabitethernet0/1
 ip access-group 120 out

Im ersten Fall wird Verkehr geprüft, sobald er am Interface ankommt. Im zweiten Fall wird er erst beim Verlassen des Interfaces bewertet.

Ingress und Egress im Netzwerk verstehen

Ingress bedeutet eingehender Verkehr

Ingress oder eingehend meint den Verkehr, der in ein Interface hineinkommt. Wird dort eine ACL angewendet, sieht sie das Paket in einem sehr frühen Stadium. Das ist besonders nützlich, wenn unerwünschter Verkehr möglichst früh verworfen werden soll.

  • Pakete werden direkt beim Eintritt gefiltert.
  • Unerwünschter Verkehr wird nicht weiter durchs Netz transportiert.
  • Ressourcen auf nachgelagerten Segmenten werden geschont.

Egress bedeutet ausgehender Verkehr

Egress oder ausgehend meint den Verkehr, der ein Interface verlässt. Diese Richtung ist nützlich, wenn man gezielt kontrollieren will, was zu einem Zielnetz oder in einen bestimmten Bereich hinausgeht. Ausgehende ACLs werden oft dann gewählt, wenn mehrere Quellen auf dasselbe Zielnetz zulaufen und dort ein gemeinsamer Filterpunkt sinnvoll ist.

  • Verkehr wird vor dem Verlassen des Interfaces geprüft.
  • Ein Zielsegment kann zentral geschützt werden.
  • Mehrere Quellen lassen sich an einer Stelle zusammenfassen.

Die klassische Platzierungsregel: Standard ACL nahe am Ziel

Warum Standard ACLs eher in Zielnähe sitzen sollten

Standard ACLs prüfen im Wesentlichen nur die Quelladresse eines Pakets. Sie wissen nicht, wohin das Paket eigentlich will und unterscheiden auch nicht nach Diensten oder Protokollen. Genau deshalb sind sie relativ grob. Wenn eine Standard ACL zu früh im Pfad angewendet wird, blockiert sie möglicherweise Verkehr einer Quelle zu vielen verschiedenen Zielen, obwohl vielleicht nur ein bestimmter Zielbereich geschützt werden sollte.

Deshalb gilt die klassische Empfehlung:

  • Standard ACLs möglichst nah am Ziel platzieren.
  • So wird nur der Verkehr blockiert, der dieses Ziel tatsächlich erreichen soll.
  • Andere legitime Ziele für dieselbe Quelle bleiben erreichbar.

Diese Regel ist im CCNA-Kontext besonders wichtig, weil sie den Zusammenhang zwischen Präzision und Platzierung sehr gut erklärt.

Ein einfaches Beispiel

Angenommen, das Netz 192.168.10.0/24 soll nicht in ein Managementnetz gelangen, darf aber andere interne Ziele weiterhin erreichen. Eine Standard ACL nahe am Managementziel ist hier sinnvoller als eine frühe Blockade direkt am Ursprung.

access-list 10 deny 192.168.10.0 0.0.0.255
access-list 10 permit any

Wird diese ACL am Interface in Richtung des Zielbereichs angewendet, blockiert sie nur den Zugriff dorthin, nicht aber den gesamten übrigen Verkehr dieser Quelle.

Die klassische Platzierungsregel: Erweiterte ACL nahe an der Quelle

Warum erweiterte ACLs früh greifen sollten

Erweiterte ACLs können Quelle, Ziel, Protokoll und Ports prüfen. Dadurch wissen sie viel genauer, welcher Verkehr gemeint ist. Genau diese Präzision erlaubt es, unerwünschten Verkehr möglichst früh zu stoppen, bevor er unnötig durch Teile des Netzes läuft.

  • Unerwünschte Pakete werden schnell verworfen.
  • Bandbreite und Routingressourcen werden geschont.
  • Angriffsverkehr dringt weniger weit ins Netz vor.
  • Segmentgrenzen werden näher am Ursprung gezogen.

Deshalb lautet die klassische Empfehlung:

  • Erweiterte ACLs möglichst nah an der Quelle platzieren.

Ein typisches Beispiel

Wenn ein Benutzer-VLAN nur HTTPS zu einem bestimmten Server senden darf, ist es sinnvoll, genau diesen nicht erlaubten Restverkehr möglichst früh am Ausgang des Benutzerbereichs zu filtern.

access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
access-list 110 deny ip any any

Wird diese ACL eingehend am Interface des Benutzer-VLANs gesetzt, verlässt unerlaubter Verkehr das VLAN gar nicht erst in Richtung anderer Zonen.

Warum diese Platzierungsregeln sinnvoll sind

Frühe Filter sparen Ressourcen und reduzieren Risiko

Vor allem bei erweiterten ACLs ist frühes Filtern sinnvoll, weil präzise definierter unerwünschter Verkehr nicht quer durch das Netz transportiert werden muss. Das spart Bandbreite, reduziert unnötige Last und erschwert interne Aufklärung durch kompromittierte Hosts.

  • weniger unnötiger Ost-West-Verkehr
  • weniger Belastung auf Uplinks und Routingpunkten
  • schnellere Begrenzung von Malware- oder Scan-Verkehr

Spätere Filter erlauben grobe Quellsteuerung ohne Kollateralschäden

Bei Standard ACLs ist die spätere Platzierung sinnvoll, weil sie grob filtern. Ein zu früher Grobfilter kann viele legitime Kommunikationspfade einer Quelle unbeabsichtigt abschneiden. In Zielnähe bleibt die Wirkung fokussierter.

Platzierung an Router-Interfaces und Subinterfaces

Router-on-a-Stick als typisches Beispiel

In kleineren Netzen oder im CCNA-Labor wird Inter-VLAN-Routing oft über Router-on-a-Stick realisiert. Dabei terminieren mehrere Subinterfaces verschiedene VLANs. Genau an diesen Subinterfaces können ACLs gezielt greifen.

Beispiel:

interface gigabitethernet0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
 ip access-group 110 in

Hier wirkt die ACL 110 eingehend auf den Verkehr aus VLAN 10. Das ist eine klassische Platzierung für eine erweiterte ACL nahe an der Quelle.

Subinterfaces sind logische Zonengrenzen

Gerade bei Router-on-a-Stick sind Subinterfaces sehr gute Kontrollpunkte, weil sie exakt definieren, von welchem VLAN der Verkehr kommt oder in welches VLAN er hineinläuft. Das macht ACLs an diesen Stellen besonders nachvollziehbar.

Platzierung an SVIs auf Layer-3-Switches

SVIs als zentrale Kontrollstellen zwischen VLANs

In modernen Unternehmensnetzen übernehmen oft Layer-3-Switches das Routing zwischen VLANs. Jedes VLAN besitzt ein SVI, also ein Switch Virtual Interface, das als Gateway dient. Genau dort können ACLs sehr gezielt für Inter-VLAN-Sicherheit eingesetzt werden.

Ein Beispiel:

interface vlan 10
 ip address 192.168.10.1 255.255.255.0
 ip access-group 110 in

Damit wird Verkehr aus VLAN 10 direkt an seinem Layer-3-Übergang gefiltert.

SVIs verbessern Übersicht bei segmentierten Netzen

Die Platzierung an SVIs ist besonders nützlich, weil sie Zonenlogik und Regelwirkung gut zusammenführt. Ein Benutzer-VLAN, ein Server-VLAN oder ein Gast-VLAN kann jeweils eigene Kontrollpunkte besitzen. Dadurch lässt sich das Netzdesign klarer dokumentieren und prüfen.

ACLs für Managementzugänge richtig platzieren

VTY-Leitungen sind keine normalen Datenpfade

Managementzugänge wie SSH auf Cisco-Geräten werden nicht wie normaler Datenverkehr über Routing-Interfaces kontrolliert. Hier ist der geeignete Kontrollpunkt häufig direkt die VTY-Leitung. Deshalb wird für den Schutz administrativer Zugriffe oft eine ACL über access-class verwendet.

Beispiel:

access-list 10 permit 192.168.99.0 0.0.0.255

line vty 0 4
 access-class 10 in
 login local
 transport input ssh

Diese Platzierung ist ideal, weil der Zugriff direkt dort gefiltert wird, wo die Managementsitzung ankommt.

Managementschutz sollte möglichst nah an der Managementfunktion liegen

Wenn ein Gerät nur aus einem Admin-Netz administrierbar sein soll, ist es meist besser, dies direkt am Managementzugang durchzusetzen als indirekt irgendwo tief im Routingpfad. So bleibt die Regel logisch klar und betrieblich einfacher nachvollziehbar.

Quellnah oder zielnah ist wichtig, aber nicht absolut

Design und Betriebsrealität können Ausnahmen erfordern

Die klassischen Regeln – Standard ACL nahe am Ziel, erweiterte ACL nahe an der Quelle – sind sehr gute Leitlinien, aber keine starren Gesetze. In realen Netzen kann es sinnvoll sein, aus Gründen der Übersicht, der Konsistenz oder der Topologie davon abzuweichen. Wichtig ist dann, dass die Entscheidung bewusst getroffen und sauber dokumentiert wird.

  • Mehrere Quellen laufen auf ein gemeinsames Ziel zu.
  • Ein Firewall- oder Routerpunkt dient als zentrale Zonengrenze.
  • Ein gemeinsamer Ausgang soll ein Zielnetz schützen.
  • Organisatorische Klarheit ist an einer anderen Stelle höher.

Regeln dürfen nicht nur „technisch passen“, sondern müssen wartbar bleiben

Eine ACL an der theoretisch perfekten Stelle ist wenig hilfreich, wenn sie später im Betrieb niemand mehr sauber versteht. Gute Platzierung bedeutet daher immer auch Lesbarkeit, Nachvollziehbarkeit und Dokumentierbarkeit.

Typische Fehler bei der ACL-Platzierung

Standard ACL zu früh im Pfad einsetzen

Ein klassischer Fehler ist, eine Standard ACL direkt am Ursprung zu platzieren. Weil sie nur nach der Quelle filtert, blockiert sie dann oft mehr als gewollt. Dieselbe Quelle kann andere Ziele vielleicht legitim benötigen, verliert aber durch die frühe Blockade unnötig viele Kommunikationsmöglichkeiten.

Erweiterte ACL zu spät platzieren

Der umgekehrte Fehler besteht darin, eine sehr präzise erweiterte ACL erst spät im Pfad anzuwenden. Dadurch läuft unerwünschter Verkehr zunächst weit durchs Netz, belegt Ressourcen und erhöht die Reichweite potenzieller Angriffe oder Scans.

Ingress und Egress verwechseln

Ein weiterer häufiger Fehler ist die falsche Richtung. Eine ACL, die ausgehend statt eingehend gesetzt wird, kann ganz andere Ergebnisse liefern als beabsichtigt. Deshalb sollte bei jeder ACL immer ausdrücklich geklärt werden: Wo kommt das Paket her, und wann soll es geprüft werden?

ACL an mehreren Stellen duplizieren, ohne klare Logik

In gewachsenen Netzen kommt es vor, dass ähnliche ACLs mehrfach an verschiedenen Stellen auftauchen. Das kann im Einzelfall sinnvoll sein, führt aber oft zu Inkonsistenzen, schwerer Fehlersuche und unklarer Verantwortlichkeit. Besser ist eine klare Regelstrategie pro Zonenübergang.

Praktische Leitfragen für die richtige Platzierung

Wo entsteht der unerwünschte Verkehr?

Eine gute erste Frage ist: Wo kommt der Verkehr her, den ich kontrollieren will? Wenn die Quelle klar bekannt ist und die Regel präzise formuliert werden kann, spricht viel für eine quellennahe Platzierung mit einer erweiterten ACL.

Welches Ziel soll geschützt werden?

Wenn ein bestimmtes Zielnetz oder eine Managementfunktion geschützt werden soll und die Filterung eher grob auf Quellbasis erfolgt, ist eine zielnahe Platzierung oft sinnvoller. Genau hier zeigt sich die Stärke klassischer Standard ACLs.

Wo ist die Regel für Betrieb und Audit am klarsten?

Auch die betriebliche Perspektive ist wichtig. Eine ACL sollte an einer Stelle sitzen, an der ihre Funktion logisch verständlich bleibt. Gute Sicherheitsarchitektur ist immer auch gute Dokumentierbarkeit.

Prüfen, ob ACLs richtig platziert sind

Relevante Show-Befehle auf Cisco-Geräten

Zur Überprüfung von ACL-Platzierungen sind einige Cisco-Befehle besonders hilfreich:

show access-lists
show running-config
show ip interface brief
show ip route

show access-lists zeigt die ACLs und oft ihre Trefferzähler. show running-config macht sichtbar, an welchen Interfaces oder Leitungen sie angewendet sind. show ip interface brief zeigt die relevanten Layer-3-Schnittstellen, und show ip route hilft, die Verkehrswege im Netz besser zu verstehen.

Trefferzähler und Verkehrswege gemeinsam betrachten

Eine ACL ist nicht nur dann korrekt platziert, wenn sie konfiguriert ist, sondern wenn sie an der richtigen Stelle den erwarteten Verkehr trifft. Trefferzähler, Interface-Kontext und Routingpfad sollten deshalb zusammen analysiert werden.

Beispiel für gute und schlechte Platzierung

Schlechte Platzierung einer Standard ACL

Angenommen, ein Quellnetz 192.168.10.0/24 soll nur kein Managementnetz erreichen, aber andere Serverbereiche weiterhin nutzen dürfen. Wird eine Standard ACL direkt am Quellinterface gesetzt, blockiert sie unter Umständen die gesamte Kommunikation dieses Netzes zu vielen Zielen.

access-list 10 deny 192.168.10.0 0.0.0.255
access-list 10 permit any

Diese ACL wäre am Ursprungsinterface der Quelle meist zu grob.

Bessere Platzierung derselben ACL

Wird dieselbe ACL dagegen in Richtung des Managementnetzes angewendet, blockiert sie nur den Verkehr zu diesem Zielbereich, nicht aber zu anderen legitimen Zielen. Genau deshalb ist die Platzierung in Zielnähe hier sinnvoller.

Warum ACL-Platzierung für CCNA und Netzwerksicherheit unverzichtbar ist

Sie verbindet Theorie, Routing und Sicherheitslogik

Die richtige Platzierung von ACLs ist ein Thema, das viele Grundlagen zusammenführt: Verkehrsrichtung, Routingpfad, VLAN-Grenzen, Managementzugänge und Sicherheitszonen. Erst dadurch wird aus einer Liste von Regeln echte Netzwerksicherheit.

  • Standard ACLs zeigen, warum grobe Filter zielnah sinnvoll sind.
  • Erweiterte ACLs zeigen, warum präzise Filter früh greifen sollten.
  • Interfaces und Richtungen machen Sicherheitslogik praktisch sichtbar.

Eine ACL ist nur so gut wie ihr Platz im Design

Am Ende ist die wichtigste Erkenntnis sehr klar: Eine ACL schützt nicht allein durch ihren Inhalt, sondern durch ihren Inhalt an der richtigen Stelle. Wer ACLs richtig platzieren kann, versteht Netzkommunikation nicht nur funktional, sondern sicherheitstechnisch. Genau dieses Verständnis ist ein zentraler Schritt zu professioneller Cisco-Administration und sauber segmentierten Unternehmensnetzen.

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.

Related Articles