Wer ein Netzwerk mit Access Control Lists (ACLs) absichert, erlebt früher oder später einen klassischen Zielkonflikt: Je restriktiver die Regeln, desto kleiner die Angriffsfläche – aber desto größer die Gefahr, dass der Betrieb leidet. Besonders häufig betrifft das Basisdienste und Diagnosepfade wie ICMP, DNS, NTP erlauben. Diese drei Themen wirken auf den ersten Blick „klein“, sind aber im Alltag entscheidend: Ohne DNS funktionieren viele Anwendungen scheinbar nicht, obwohl IP-Konnektivität vorhanden ist. Ohne NTP geraten Zertifikate, Authentifizierung und Logging aus dem Takt. Und ohne ICMP wird Troubleshooting unnötig schwer, weil Ping und Traceroute nur eingeschränkt arbeiten und wichtige Fehlermeldungen fehlen. Ziel dieses Leitfadens ist es, sinnvolle ACL-Regeln zu zeigen, die den Betrieb stabil halten, ohne unnötig zu öffnen. Sie lernen, welche ICMP-Typen in der Praxis wirklich hilfreich sind, warum DNS nicht nur UDP/53 ist, welche NTP-Regeln in Client- und Infrastruktursegmenten sinnvoll sind und wie Sie diese Regeln sauber in Cisco Standard- oder Extended ACLs umsetzen. Außerdem erfahren Sie, woran man erkennt, dass „zu viel“ erlaubt wurde, wie Sie Logging und Hit Counter nutzen, und wie Sie Regeln so platzieren, dass sie wartbar und performant bleiben.
Warum ICMP, DNS und NTP in restriktiven ACLs oft vergessen werden
Viele ACLs entstehen aus einer Sicherheitsanforderung („nur notwendige Ports erlauben“). Dabei fokussiert man sich auf Applikationsports wie 443, 22, 3389 oder spezifische Business-Services. Die Nebenbedingungen werden übersehen:
- DNS: Anwendungen nutzen Namen, nicht IPs. Wenn DNS nicht erlaubt ist, wirkt das wie „Internet kaputt“.
- NTP: Zeit ist Grundlage für TLS, Kerberos/AAA, Zertifikate, Ticketing, Syslog-Korrelation.
- ICMP: Ping/Traceroute sowie wichtige Fehlermeldungen (z. B. „Fragmentation needed“) unterstützen Stabilität und Diagnose.
Die Kunst besteht darin, diese Protokolle nicht pauschal „offen“ zu lassen, sondern zielgerichtet und minimal zu erlauben – idealerweise zu definierten Servern (Resolvern, NTP-Servern) und mit bewusst gewählten ICMP-Typen.
Grundprinzipien für „betriebstaugliche“ ACLs
Bevor Sie einzelne Regeln schreiben, lohnt sich ein kurzer Best-Practice-Rahmen. Diese Prinzipien machen ACLs deutlich robuster:
- Allow-List statt Block-List: Erlauben Sie nur benötigte Flows, blocken Sie den Rest.
- Extended ACLs für Betriebsservices: DNS/NTP/ICMP sind protokoll- und portabhängig – Extended ACLs sind dafür passender als Standard ACLs.
- Platzierung passend wählen: Extended ACLs eher nahe an der Quelle (z. B. inbound am VLAN-SVI), um unerwünschten Traffic früh zu stoppen.
- DNS/NTP zentralisieren: Wenn Clients nur definierte Resolver/NTP-Server nutzen dürfen, sind Regeln einfacher und sicherer.
- Dokumentation per remark: Jede erlaubte Ausnahme sollte nachvollziehbar sein (Zweck, Owner, Ticket).
- Hit Counter nutzen: Mit
show ip access-listsprüfen, welche Regeln wirklich genutzt werden.
Für ACL-Grundlagen und Syntaxdetails sind diese Quellen hilfreich: Cisco ACL Grundlagen und Konfiguration sowie die Cisco IOS Command Reference.
DNS in ACLs: Mehr als nur UDP 53
DNS ist im Betrieb oft der wichtigste „unsichtbare“ Dienst. Wenn DNS fehlt, funktionieren Browser, Updates, Cloud-APIs, E-Mail, Identity-Systeme und Monitoring oft nicht oder nur sporadisch. Gleichzeitig ist DNS ein beliebter Angriffs- und Exfiltrationskanal. Daher ist eine gezielte Erlaubnis sinnvoll: Clients dürfen DNS nur zu Ihren Resolvern, nicht „zu jedem Ziel im Internet“.
Warum DNS auch TCP nutzt
- UDP/53: Standard für die meisten Anfragen.
- TCP/53: wird u. a. bei großen Antworten, DNSSEC, bestimmten Retransmits und Zonentransfers genutzt.
In vielen Clientnetzen reicht TCP/53 als „Fallback“ zum Resolver. Zonentransfers (AXFR/IXFR) sollten Sie nur zwischen autoritativen DNS-Servern erlauben, nicht aus Clientsegmenten.
Protokollhintergrund: RFC 1034 und RFC 1035.
Sinnvolle DNS-Regeln für Clients zu internen Resolvern
Beispielannahmen:
- Client-VLAN: 10.20.20.0/24
- Resolver: 10.10.10.10 und 10.10.10.11
configure terminal
ip access-list extended CLIENT-DNS-NTP-ICMP
remark DNS nur zu internen Resolvern erlauben
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.11 eq 53
permit tcp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
permit tcp 10.20.20.0 0.0.0.255 host 10.10.10.11 eq 53
Best Practice: Erlauben Sie DNS nicht pauschal zu „any“. Das reduziert Missbrauch und macht Troubleshooting einfacher, weil klar ist, wo DNS laufen muss.
DNS-Fehlerbilder, die wie „Internet down“ wirken
- Ping zu IP funktioniert, Websites/Services über Namen nicht.
- Nur manche Seiten funktionieren (weil Clients Caches nutzen), andere nicht.
- Updates schlagen fehl, weil Update-URLs nicht auflösbar sind.
Wenn Sie solche Symptome sehen, ist DNS fast immer einer der ersten ACL-Kandidaten.
NTP in ACLs: Zeit ist Sicherheit und Betrieb
NTP ist nicht nur „nice to have“. Zeitabweichungen führen zu echten Ausfällen: Zertifikate gelten „noch nicht“ oder „nicht mehr“, AAA-Anmeldungen scheitern, Logs werden unbrauchbar, und Fehlersuche wird deutlich schwieriger. In restriktiven Segmenten sollten Clients und Netzwerkgeräte NTP zu definierten Zeitservern nutzen dürfen.
NTP-Grundlagen für ACL-Regeln
- NTP nutzt typischerweise UDP Port 123.
- Clients senden an NTP-Server, Antworten kommen zurück – bei stateless ACLs sollten Hin- und Rückweg bedacht werden (in vielen Designs reicht eine inbound ACL am Client-SVI, weil die Antworten als „Rückverkehr“ über dasselbe Interface zurücklaufen).
Protokollhintergrund: RFC 5905 (NTP).
Sinnvolle NTP-Regeln: Clients nur zu internen NTP-Servern
Beispielannahmen:
- NTP-Server: 10.10.10.20 und 10.10.10.21
remark NTP nur zu definierten Zeitservern
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.20 eq 123
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.21 eq 123
Best Practice: Nutzen Sie interne NTP-Server, die ihrerseits kontrolliert gegen externe Quellen synchronisieren. Dadurch müssen Sie in Client-ACLs keine externen NTP-IPs öffnen.
Besondere Segmente: Netzwerkgeräte und Management-VLAN
Für Router, Switches, Firewalls und Server ist NTP noch wichtiger, weil Logkorrelation und Security-Events zeitkritisch sind. Hier empfiehlt sich:
- NTP erlaubt aus dem Management-VLAN zu internen NTP-Servern
- Zusätzlich ggf. NTP von NTP-Servern zu Upstream-NTP (nur auf den NTP-Servern selbst)
ICMP in ACLs: Nicht pauschal sperren, sondern gezielt erlauben
ICMP wird oft komplett blockiert, weil es „unsicher“ wirkt. Das ist im Betrieb selten sinnvoll. ICMP ist Teil der IP-Funktionalität und hilft bei Diagnose und Stabilität. Die richtige Strategie ist: ICMP selektiv erlauben, statt alles zu öffnen oder alles zu schließen.
Welche ICMP-Typen sind im Betrieb nützlich?
- echo und echo-reply: klassischer Ping für Erreichbarkeitstests.
- time-exceeded: wichtig für Traceroute (TTL abgelaufen).
- unreachable: signalisiert u. a. „Destination unreachable“; hilfreich bei Diagnose.
- fragmentation-needed (Teil von „unreachable“ je nach Darstellung): relevant für Path MTU Discovery, besonders bei Tunneln/VPNs.
Protokollhintergrund: RFC 792 (ICMP).
ICMP-Regeln für Clients: Ping und Traceroute ermöglichen
Wenn Sie aus dem Client-VLAN grundlegende Diagnose erlauben wollen, können Sie ICMP gezielt freigeben. Beispiel:
remark ICMP Diagnose: Ping
permit icmp 10.20.20.0 0.0.0.255 any echo
permit icmp 10.20.20.0 0.0.0.255 any echo-reply
remark ICMP Diagnose: Traceroute und Fehler
permit icmp 10.20.20.0 0.0.0.255 any time-exceeded
permit icmp 10.20.20.0 0.0.0.255 any unreachable
Je nach Sicherheitsanforderung können Sie ICMP auch nur zu bestimmten Zielen erlauben (z. B. nur zu Gateways, DNS/NTP-Servern oder Monitoring-Endpunkten), statt „any“ zu nutzen.
ICMP und Sicherheit: Was Sie vermeiden sollten
- ICMP komplett blockieren, wenn Sie später verlässliches Troubleshooting erwarten.
- ICMP überall unkontrolliert erlauben, wenn Sie sehr restriktive Segmentierung benötigen.
- Vergessen, dass Traceroute je nach Tool auch UDP oder TCP nutzen kann (ICMP ist dennoch für viele Varianten relevant).
Eine praxistaugliche „Basis-ACL“ für Clients: DNS + NTP + ICMP + Web
In vielen Segmenten ist eine „minimal betriebstaugliche“ Policy sinnvoll: DNS zu Resolvern, NTP zu Zeitservern, grundlegendes ICMP, sowie Web (80/443) zu beliebigen Zielen oder zu einem Proxy. Die Web-Regeln sind optional und hängen vom Segment ab (Gast, IoT, Corporate). Beispiel:
configure terminal
ip access-list extended VLAN20-BASELINE
remark DNS zu internen Resolvern
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.11 eq 53
permit tcp 10.20.20.0 0.0.0.255 host 10.10.10.10 eq 53
permit tcp 10.20.20.0 0.0.0.255 host 10.10.10.11 eq 53
remark NTP zu internen Zeitservern
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.20 eq 123
permit udp 10.20.20.0 0.0.0.255 host 10.10.10.21 eq 123
remark ICMP Diagnose selektiv
permit icmp 10.20.20.0 0.0.0.255 any echo
permit icmp 10.20.20.0 0.0.0.255 any echo-reply
permit icmp 10.20.20.0 0.0.0.255 any time-exceeded
permit icmp 10.20.20.0 0.0.0.255 any unreachable
remark Optional: Web
permit tcp 10.20.20.0 0.0.0.255 any eq 80
permit tcp 10.20.20.0 0.0.0.255 any eq 443
deny ip any any
end
Diese ACL wenden Sie typischerweise inbound auf dem VLAN-SVI an:
configure terminal
interface vlan 20
ip access-group VLAN20-BASELINE in
end
DNS/NTP lieber zu festen Servern als zu „any“
Ein zentraler Best-Practice-Gedanke ist: Wenn Sie DNS und NTP auf definierte Server beschränken, gewinnen Sie gleich mehrfach:
- Security: Weniger Missbrauchsmöglichkeiten (DNS-Tunneling, externe NTP-Quellen).
- Betrieb: Klare Fehlerdomäne – wenn DNS nicht geht, prüfen Sie Resolver, nicht „das Internet“.
- Wartbarkeit: Sie ändern bei Serverwechsel nur wenige ACL-Zeilen oder eine Object Group.
In größeren Umgebungen empfiehlt sich zusätzlich die Nutzung von Object Groups, um Resolver- und NTP-Server zentral zu verwalten.
Object Groups für DNS/NTP/ICMP-Regeln: Effizient und konsistent
Wenn mehrere VLANs dieselben Resolver und Zeitserver nutzen, vermeiden Sie Copy-and-Paste, indem Sie Objektgruppen definieren und in mehreren ACLs wiederverwenden.
Beispiel: Resolver- und NTP-Gruppen
configure terminal
object-group network DNS-RESOLVERS
host 10.10.10.10
host 10.10.10.11
object-group network NTP-SERVERS
host 10.10.10.20
host 10.10.10.21
object-group service WEB-PORTS tcp
port-object eq 80
port-object eq 443
end
Dann können Sie in ACLs konsistenter arbeiten (plattformabhängige Syntax beachten):
ip access-list extended VLAN20-BASELINE
permit udp 10.20.20.0 0.0.0.255 object-group DNS-RESOLVERS eq 53
permit tcp 10.20.20.0 0.0.0.255 object-group DNS-RESOLVERS eq 53
permit udp 10.20.20.0 0.0.0.255 object-group NTP-SERVERS eq 123
permit tcp 10.20.20.0 0.0.0.255 any object-group WEB-PORTS
Der Vorteil: Wenn ein Resolver wechselt, ändern Sie nur die Objektgruppe – und nicht alle ACLs in allen VLANs.
Reihenfolge in ACLs: Warum DNS/NTP/ICMP früh stehen sollten
Damit Basisdienste zuverlässig funktionieren, sollten die entsprechenden Permit-Regeln in einer Allow-List-ACL vor allgemeinen Deny-Regeln stehen. Gleichzeitig gilt „spezifisch vor allgemein“:
- DNS und NTP zu festen Servern sind sehr spezifisch und gehören weit nach oben.
- ICMP-Diagnose kann ebenfalls relativ früh stehen, damit Troubleshooting möglich bleibt.
- Breite Regeln wie „permit tcp any any eq 443“ (falls überhaupt gewünscht) kommen eher später oder werden auf Proxy-Ziele begrenzt.
Wenn Sie am Ende ein deny ip any any setzen, ist das eine bewusste Entscheidung und erleichtert auch die Fehlersuche, weil alles Nicht-Erlaubte eindeutig verworfen wird.
Logging und Hit Counter: Betriebstauglich verifizieren
Statt sofort Logging auf „deny any any“ zu aktivieren, ist es in den meisten Fällen besser, mit Hit Countern zu arbeiten. Prüfen Sie regelmäßig:
show ip access-lists(Trefferzähler pro Zeile)show running-config interface <IF>(ACL korrekt gebunden?)
Logging ist sinnvoll, wenn Sie gezielt wissen möchten, ob z. B. DNS außerhalb des erlaubten Pfads versucht wird. Dann loggen Sie besser eine eng matchende Deny-Regel, etwa „DNS zu any“ als Hinweis auf Fehlkonfiguration:
deny udp 10.20.20.0 0.0.0.255 any eq 53 log
Wichtig: Logging sparsam einsetzen, sonst drohen Logflut und unnötige Last.
Typische Fehler und Fixes in der Praxis
- Web geht nicht, Ping geht: DNS fehlt oder DNS ist nur UDP erlaubt, aber TCP wird benötigt. Fix: DNS zu Resolvern UDP+TCP erlauben.
- Zertifikatsfehler, AAA-Probleme, Logs unbrauchbar: NTP fehlt oder ist zu externen Quellen blockiert. Fix: NTP zu internen Zeitservern erlauben und NTP-Architektur sauber planen.
- Traceroute funktioniert nicht: ICMP time-exceeded/unreachable blockiert. Fix: selektive ICMP-Typen erlauben.
- VPN/Tunnel-Probleme, große Transfers brechen: Path MTU Discovery wird behindert. Fix: ICMP unreachable (inkl. Fragmentation needed) zulassen, besonders bei Tunneln.
- Zu offene DNS-Regeln: DNS ist „any any“, ermöglicht Missbrauch. Fix: DNS nur zu Resolvern, optional DNS zu externen Zielen komplett sperren.
Sicherheitsbalance: Was Sie bewusst nicht (oder nur sehr gezielt) erlauben sollten
„Betrieb ermöglichen“ heißt nicht „alles öffnen“. Diese Punkte helfen, die Balance zu halten:
- DNS: nicht zu beliebigen Zielen erlauben, sondern nur zu Resolvern; Zonentransfers nur zwischen DNS-Servern.
- NTP: nicht zu „any“ erlauben; NTP-Clients zu internen Servern, nur NTP-Server selbst zu externen Quellen.
- ICMP: selektiv erlauben; bei sehr restriktiven Zonen ICMP nur zu Gateways/Monitoring-Endpunkten.
Als allgemeine Orientierung zu sicheren Betriebspraktiken (Least Privilege, Logging, Change-Disziplin) ist der Anchor-Text CIS Controls hilfreich.
Praxis-Checkliste: Sinnvolle ACL-Regeln für den Betrieb
- DNS ist erlaubt – aber nur zu definierten Resolvern (UDP/53 und TCP/53 nach Bedarf).
- NTP ist erlaubt – aber nur zu definierten Zeitservern (UDP/123), idealerweise intern.
- ICMP ist nicht pauschal gesperrt, sondern selektiv erlaubt (echo/echo-reply, time-exceeded, unreachable).
- Die Regeln stehen in der richtigen Reihenfolge (spezifisch vor allgemein, Allow-List vor Deny).
- Die ACL ist am richtigen Interface und in der richtigen Richtung gebunden (meist inbound am Client-SVI).
- Hit Counter werden geprüft, Logging wird nur gezielt eingesetzt.
- Änderungen werden dokumentiert (remark/Owner/Change) und schrittweise ausgerollt.
copy running-config startup-config
Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.