Site icon bintorosoft.com

14.10 ACLs richtig platzieren im Netzwerk

Red Snapper

Network engineer working with tablet in server data center room, professional skilled technician

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

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

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:

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

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

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

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.

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

Wann outbound sinnvoll sein kann

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

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

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

Zentrale Platzierung am Ziel oder Core

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:

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

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:

Praktische Denkfolge

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

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

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:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version