14.11 ACL einfach erklärt mit Praxisbeispiel

ACLs gehören zu den wichtigsten Grundlagen in Cisco-Netzwerken, weil sie direkt beeinflussen, welcher Datenverkehr erlaubt oder blockiert wird. Sobald ein Administrator festlegen möchte, dass bestimmte Geräte, Netzwerke oder Dienste miteinander kommunizieren dürfen oder eben nicht, kommt häufig eine Access Control List zum Einsatz. Für Einsteiger wirken ACLs anfangs oft abstrakt, in der Praxis sind sie jedoch ein sehr logisches Werkzeug: Sie prüfen Pakete anhand definierter Regeln und treffen dann eine klare Entscheidung. Besonders hilfreich wird das Thema, wenn man es nicht nur theoretisch betrachtet, sondern mit einem konkreten Praxisbeispiel verbindet. Genau dann wird verständlich, wie ACLs tatsächlich im Alltag eines Network Engineers eingesetzt werden.

Was ist eine ACL?

ACL steht für Access Control List. Es handelt sich um eine Liste von Regeln, mit denen ein Router oder Layer-3-Switch entscheidet, ob ein bestimmtes Paket erlaubt oder verworfen wird. Jede Regel beschreibt, welcher Traffic betroffen ist und welche Aktion ausgeführt werden soll. Die beiden zentralen Aktionen heißen permit und deny.

Eine ACL arbeitet also wie ein Filter. Sobald ein Paket auf eine ACL trifft, wird geprüft, ob es zu einer der Regeln passt. Wenn ja, wird die festgelegte Aktion sofort angewendet. Passt das Paket zu keiner expliziten Regel, greift am Ende das sogenannte implizite Deny. Dadurch wird der Traffic verworfen.

Die Grundidee einer ACL

• Pakete werden anhand definierter Regeln geprüft
• Regeln können Traffic erlauben oder blockieren
• Die Auswertung erfolgt von oben nach unten
• Die erste passende Regel entscheidet

Warum ACLs in Netzwerken so wichtig sind

Ohne ACLs würde Routing in vielen Fällen einfach alles weiterleiten, solange ein Pfad vorhanden ist. Das ist in der Praxis oft nicht gewünscht. Nicht jedes Netz soll jedes andere Netz erreichen. Management-Zugänge sollen geschützt sein, Gastnetzwerke sollen keine Server erreichen und sensible Dienste sollen nur für bestimmte Administratoren verfügbar sein.

ACLs schaffen genau hier Kontrolle. Sie sind ein Werkzeug für Sicherheit, Segmentierung und sauberes Netzwerkdesign. Selbst in kleinen Umgebungen können ACLs sehr nützlich sein, etwa um Telnet zu blockieren, SSH nur aus einem Admin-Netz zu erlauben oder den Zugriff auf einen internen Server einzuschränken.

Typische Einsatzbereiche von ACLs

• Filtern von Traffic zwischen VLANs
• Schutz von Routern und Switches bei SSH-Zugriffen
• Blockieren unerwünschter Protokolle oder Ports
• Steuern, welche Netze NAT verwenden dürfen
• Segmentierung von Gast-, Client- und Servernetzwerken

Wie eine ACL arbeitet

Eine ACL wird immer in einer festen Reihenfolge verarbeitet. Das Gerät prüft die Regeln von oben nach unten. Sobald eine Regel passt, wird die zugehörige Aktion angewendet und das Paket nicht weiter mit späteren Zeilen verglichen. Diese Logik nennt man häufig top-down, first match.

Die Reihenfolge der Regeln ist deshalb entscheidend. Eine zu allgemeine Regel am Anfang kann spätere, eigentlich wichtigere Regeln komplett wirkungslos machen.

Verarbeitungsreihenfolge einer ACL

• Ein Paket trifft auf die ACL
• Die erste Zeile wird geprüft
• Wenn die Zeile passt, wird permit oder deny angewendet
• Wenn sie nicht passt, wird die nächste Zeile geprüft
• Am Ende greift bei fehlender Übereinstimmung das implizite Deny

Was das implizite Deny bedeutet

Jede ACL endet logisch mit einem unsichtbaren Block-Eintrag. Bei einer erweiterten ACL entspricht das sinngemäß deny ip any any. Alles, was nicht vorher ausdrücklich erlaubt wurde, wird blockiert.

Standard ACL und Extended ACL einfach erklärt

In Cisco-Netzwerken unterscheidet man grundsätzlich zwischen zwei ACL-Typen: Standard ACL und Extended ACL. Beide filtern Traffic, aber sie tun das mit unterschiedlicher Genauigkeit.

Standard ACL

Eine Standard ACL betrachtet nur die Quell-IP-Adresse. Sie ist deshalb einfach, aber relativ grob. Sie kann nicht unterscheiden, wohin ein Paket geht oder welcher Dienst genutzt wird.

access-list 10 permit 192.168.10.0 0.0.0.255

Diese Regel erlaubt Traffic aus dem Netz 192.168.10.0/24.

Extended ACL

Eine Extended ACL ist deutlich präziser. Sie kann Quelle, Ziel, Protokoll und Ports prüfen. Dadurch lassen sich sehr gezielte Regeln definieren.

access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 443

Diese Regel erlaubt TCP-Traffic aus 192.168.10.0/24 zu beliebigen Zielen, wenn der Zielport 443 ist, also HTTPS.

Wann welcher Typ sinnvoll ist

• Standard ACL für einfache Quellenfilterung
• Extended ACL für zielgerichtete Verkehrssteuerung
• In der Praxis sind Extended ACLs meist flexibler und häufiger relevant

Wichtige Begriffe bei ACLs

Bevor wir zum Praxisbeispiel kommen, sollten einige Grundbegriffe klar sein. Diese Begriffe tauchen in fast jeder ACL-Konfiguration auf.

permit

Mit permit wird passender Traffic erlaubt.

deny

Mit deny wird passender Traffic blockiert.

any

any steht für beliebige Quelle oder beliebiges Ziel.

host

host beschreibt einen einzelnen exakten Host.

permit ip host 192.168.10.10 any

Wildcard Mask

Cisco verwendet in ACLs Wildcard Masks statt normaler Subnetzmasken. Dabei gilt:

• 0 bedeutet: dieser Teil muss exakt passen
• 1 bedeutet: dieser Teil darf variieren

Beispiel:

• 0.0.0.0 = einzelner Host
• 0.0.0.255 = komplettes /24-Netz

Wo ACLs angewendet werden

Eine ACL in der Konfiguration wirkt erst dann wirklich, wenn sie an einer Stelle im System verwendet wird. Typischerweise geschieht das auf einem Interface oder auf den VTY-Lines für den Remote-Zugriff.

Inbound

Inbound bedeutet, dass Pakete geprüft werden, sobald sie ein Interface betreten.

Outbound

Outbound bedeutet, dass Pakete geprüft werden, bevor sie ein Interface verlassen.

Beispiel für die Anwendung auf einem Interface

interface GigabitEthernet0/0
 ip access-group 101 in

Damit wird ACL 101 eingehend auf GigabitEthernet0/0 angewendet.

Warum die Platzierung wichtig ist

• Standard ACLs werden meist nah am Ziel platziert
• Extended ACLs werden meist nah an der Quelle platziert
• Die gleiche ACL kann an falscher Stelle unerwartete Effekte haben

Praxisbeispiel: Client-Netz darf nur per Web auf den Server zugreifen

Jetzt wird das Thema konkret. Angenommen, in einem kleinen Unternehmensnetz existieren zwei VLANs oder Subnetze:

• Client-Netz: 192.168.10.0/24
• Server-Netz: 192.168.20.0/24

Im Server-Netz steht ein Webserver mit der Adresse 192.168.20.10. Die Anforderung lautet:

• Clients aus 192.168.10.0/24 dürfen den Webserver per HTTP und HTTPS erreichen
• Andere Zugriffe auf diesen Server sollen blockiert werden
• Der restliche Verkehr aus dem Client-Netz soll weiterhin normal möglich sein

Genau hier ist eine Extended ACL die richtige Wahl, weil nicht einfach ein ganzes Quellnetz blockiert werden soll, sondern nur bestimmte Dienste auf ein bestimmtes Ziel gesteuert werden sollen.

Warum für dieses Beispiel eine Extended ACL nötig ist

Eine Standard ACL wäre hier zu grob. Sie könnte nur prüfen, dass das Paket aus dem Client-Netz kommt. Sie könnte aber nicht unterscheiden, ob das Ziel der Webserver ist und ob der Zugriff auf Port 80 oder 443 erfolgt.

Deshalb brauchen wir eine ACL, die Folgendes gleichzeitig prüfen kann:

• Quelle: 192.168.10.0/24
• Ziel: 192.168.20.10
• Protokoll: TCP
• Ports: 80 und 443

Die ACL für das Praxisbeispiel

Eine mögliche benannte Extended ACL sieht so aus:

ip access-list extended CLIENT-TO-WEBSERVER
 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 80
 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 443
 deny ip 192.168.10.0 0.0.0.255 host 192.168.20.10
 permit ip 192.168.10.0 0.0.0.255 any

Diese Regeln bedeuten im Detail

• Zeile 1 erlaubt HTTP vom Client-Netz zum Webserver
• Zeile 2 erlaubt HTTPS vom Client-Netz zum Webserver
• Zeile 3 blockiert alle anderen IP-Zugriffe vom Client-Netz auf genau diesen Server
• Zeile 4 erlaubt den restlichen IP-Verkehr aus dem Client-Netz zu anderen Zielen

Die Reihenfolge ist entscheidend. Würde die deny ip-Regel vor den HTTP- und HTTPS-Regeln stehen, wären auch diese Zugriffe blockiert.

Wo diese ACL sinnvoll platziert wird

Da es sich um eine Extended ACL handelt, wird sie typischerweise nah an der Quelle platziert. In unserem Beispiel ist die Quelle das Client-Netz 192.168.10.0/24. Wenn das Routing über ein SVI oder Router-Interface für dieses Netz läuft, ist eine inbound-Anwendung dort meist sinnvoll.

Beispiel für die Anwendung auf dem Client-Interface

interface Vlan10
 ip access-group CLIENT-TO-WEBSERVER in

Damit wird der Traffic aus dem Client-Netz bereits beim Eintritt in das Routing geprüft. Unerwünschte Zugriffe auf den Webserver werden also früh blockiert.

Warum diese Platzierung sauber ist

• Unerwünschter Traffic wird früh gestoppt
• Das restliche Netzwerk wird nicht unnötig belastet
• Die Regel ist logisch direkt dem Client-Segment zugeordnet

Was bei diesem Beispiel tatsächlich passiert

Nehmen wir an, ein Client mit der IP 192.168.10.50 will mit dem Server 192.168.20.10 kommunizieren.

Fall 1: Zugriff per HTTP

Der Client baut eine TCP-Verbindung zu Port 80 des Servers auf. Die erste Regel der ACL passt. Der Zugriff wird erlaubt.

Fall 2: Zugriff per HTTPS

Der Client baut eine TCP-Verbindung zu Port 443 auf. Die zweite Regel passt. Auch dieser Zugriff wird erlaubt.

Fall 3: Zugriff per SSH

Der Client versucht eine Verbindung zu Port 22 des Servers. Weder Regel 1 noch Regel 2 passen. Danach trifft Regel 3 zu, weil sie jeglichen anderen IP-Traffic vom Client-Netz zu genau diesem Server blockiert. Der Zugriff wird verweigert.

Fall 4: Zugriff auf ein anderes Ziel

Der Client greift auf einen anderen Server oder aufs Internet zu. Dann passt Regel 3 nicht, weil sie nur für den Host 192.168.20.10 gilt. Danach greift Regel 4, die den restlichen IP-Verkehr erlaubt.

Wichtige Lernpunkte aus dem Praxisbeispiel

• Eine ACL sollte möglichst konkret auf die Anforderung zugeschnitten sein
• Extended ACLs eignen sich für präzise Dienststeuerung
• Die Reihenfolge der Regeln entscheidet über die Wirkung
• Eine explizite Block-Regel kann sinnvoll sein, um Verhalten klar zu definieren
• Die Platzierung nahe an der Quelle ist bei Extended ACLs meist richtig

Ein zweites kurzes Praxisbeispiel: SSH nur aus dem Admin-Netz erlauben

Ein sehr typischer Anwendungsfall ist der Schutz von Management-Zugängen. Angenommen, nur das Admin-Netz 10.10.10.0/24 soll per SSH auf einen Router zugreifen dürfen.

Passende Standard ACL

ip access-list standard MGMT-SSH
 permit 10.10.10.0 0.0.0.255

Anwendung auf den VTY-Lines

line vty 0 4
 access-class MGMT-SSH in
 transport input ssh

Hier reicht eine Standard ACL, weil nur die Quelle geprüft werden muss. Ziel und Port sind bereits durch den SSH-Zugriff auf die VTY-Lines vorgegeben.

Häufige Fehler bei ACLs

In der Praxis scheitern ACLs oft nicht am Grundprinzip, sondern an kleinen Details. Genau diese Details sollte man kennen, um Fehlkonfigurationen zu vermeiden.

Typische Fehlerquellen

• Die ACL wird auf das falsche Interface angewendet
• Inbound und outbound werden verwechselt
• Die Reihenfolge der Regeln ist falsch
• Das implizite Deny wird vergessen
• Eine Standard ACL wird eingesetzt, obwohl eine Extended ACL nötig wäre
• Wildcard Masks sind falsch geschrieben

Beispiel für eine falsche Reihenfolge

ip access-list extended BROKEN-ACL
 permit ip 192.168.10.0 0.0.0.255 any
 deny tcp 192.168.10.0 0.0.0.255 host 192.168.20.10 eq 22

Hier ist die zweite Regel praktisch wirkungslos, weil bereits die erste Regel den gesamten IP-Verkehr aus dem Client-Netz erlaubt.

ACLs überprüfen und verifizieren

Nach jeder Konfiguration sollte eine ACL geprüft werden. Cisco IOS bietet dafür mehrere nützliche Show-Befehle.

Wichtige Befehle

show access-lists
show ip interface
show running-config | section access-list
show running-config | section ip access-list

show access-lists

Dieser Befehl zeigt die ACL-Inhalte und häufig auch Trefferzähler. Diese Counter sind besonders nützlich, weil sie sichtbar machen, welche Regeln tatsächlich Pakete matchen.

show ip interface

Damit lässt sich kontrollieren, ob auf einem Interface eine ACL aktiv ist und in welcher Richtung sie angewendet wird.

Typische Prüffragen

• Ist die ACL am richtigen Interface aktiv?
• Ist die Richtung korrekt gewählt?
• Treffen Pakete auf die erwarteten Regeln?
• Blockiert eine Regel mehr Verkehr als geplant?

Best Practices für ACLs in der Praxis

ACLs sollten nicht nur funktional, sondern auch nachvollziehbar gebaut werden. Gerade in produktiven Netzen ist Lesbarkeit fast genauso wichtig wie technische Korrektheit.

Bewährte Vorgehensweisen

• Benannte ACLs statt anonymer Nummern verwenden, wenn möglich
• Regeln möglichst präzise formulieren
• Die Reihenfolge immer bewusst planen
• Standard ACLs nahe am Ziel, Extended ACLs nahe an der Quelle platzieren
• Nach Änderungen immer mit Show-Befehlen verifizieren
• Trefferzähler und Tests mit Ping, SSH oder Browserzugriffen nutzen

Praxisgedanke

Eine gute ACL ist nicht einfach nur eine Liste von Befehlen. Sie bildet eine klare Policy ab: Wer darf wohin, mit welchem Protokoll und warum? Genau dann wird aus einer reinen Konfiguration ein sauberes 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.