Infrastructure ACLs (iACLs): Schutz vor lateral movement im WAN Edge

Infrastructure ACLs (iACLs) sind ein bewährtes Security-Pattern, um die eigene Netzwerk-Infrastruktur (Router, Switches, Firewalls, Controller, Management-Services) vor lateral movement zu schützen. Die Idee ist simpel, aber wirkungsvoll: Infrastruktur-IPs sind keine „normalen Server“. Von Endnutzer- oder Partnernetzen aus sollte es praktisch keinen direkten Zugriff auf Routing-Protokolle, Management-Ports oder Control-Plane-Services geben. Im WAN Edge Kontext sind iACLs besonders wichtig, weil hier viele Trust-Grenzen zusammenlaufen (Internet, VPN, Partner, DMZ, Remote Sites). Dieser Artikel zeigt, wie du iACLs als Baseline designst, typische Ausnahmen sauber behandelst und Lockouts vermeidest – mit praxistauglichen Cisco-Patterns.

Was iACLs leisten (und was nicht)

iACLs sind keine „vollständige Segmentierung“ wie eine Firewall-Zone. Sie sind ein Baseline-Schutz, der angreifbare Infrastrukturflächen reduziert: Management, Control Plane Protokolle und interne Services. Damit wird lateral movement deutlich erschwert, selbst wenn ein Client-Netz kompromittiert ist.

• Schutz der Infrastruktur-IPs (Loopbacks, Interface-IPs, VIPs)
• Reduktion von Scans und Exploits gegen Control/Management
• Erzwingt „Management nur aus Admin-Netzen“
• Ersetzt keine Zero-Trust-Segmentierung, aber schafft eine robuste Baseline

WAN Edge Threat Model: Warum lateral movement hier real ist

Am WAN Edge treffen Netze mit unterschiedlichen Trust-Levels aufeinander. Wenn ein Remote Site, ein VPN-User oder ein Partnernetz kompromittiert wird, versucht ein Angreifer häufig, sich zur Infrastruktur vorzuarbeiten: SSH/SNMP, Routing-Protokolle, VPN-Control-Plane, NTP/DNS Manipulation.

• Remote Site kompromittiert → Zugriff auf Edge-Infra probieren
• VPN-User kompromittiert → Discovery/Scan auf Infrastruktur-IPs
• Partnernetz → fehlerhafte Freigaben auf Management/Control

Designprinzip: Infrastruktur als eigenes Schutzobjekt definieren

Der wichtigste Schritt ist, Infrastruktur-Adressräume sauber zu definieren. Best Practice ist eine oder mehrere Loopback-/Mgmt-Subnetze, die ausschließlich Infrastruktur enthalten. Damit kannst du iACLs mit klaren Prefix-Listen umsetzen.

• Loopback-Range für Router (z. B. 10.255.0.0/16)
• Mgmt-Range für OOB/VRF MGMT (z. B. 10.99.0.0/24)
• Keine Endgeräte in Infrastruktur-Prefixes

Infrastruktur-Set (Beispiel)

$\text{INFRA}=\text{Loopbacks}+\text{Mgmt-IPs}+\text{Control/VIP}$

Policy-Logik: Default Deny zur Infrastruktur, explizite Ausnahmen

iACLs sind am stärksten, wenn du umdrehst: Nicht „was darf ich blocken?“, sondern „wer darf überhaupt zur Infrastruktur?“. Typischerweise ist das nur ein Admin-Netz, Monitoring-Systeme und wenige Management-Services.

• Allow: Admin-Netze → SSH/HTTPS/NETCONF/SNMP
• Allow: Monitoring → SNMP/Syslog/Telemetry (gezielt)
• Allow: Routing Peers → IGP/BGP nur zwischen Routern
• Deny: alle übrigen Netze → Infrastruktur-Prefixes

Welche Ports/Protokolle iACLs typischerweise schützen

Ein iACL-Design priorisiert exponierte Management- und Control-Protokolle. Du blockst diese nicht „global“, sondern blockst sie, wenn die Quelle nicht autorisiert ist.

• Management: SSH (22), HTTPS (443), NETCONF (830), RESTCONF (443/9443)
• Monitoring: SNMP (161/162), Syslog (514), gNMI/gRPC (je nach Setup)
• Routing: BGP (179), OSPF (IP Proto 89), EIGRP (88), IS-IS (CLNS)
• Infra: NTP (123), DNS (53) – je nach Rollenmodell

Placement: Wo iACLs am WAN Edge am besten wirken

Die Wirkung hängt vom Placement ab. Bewährt ist, iACLs an „untrusted“ Ingress-Punkten zu setzen: WAN-Outside, Partner-Links, VPN-Interfaces (je nach Design) – bevor Traffic überhaupt in Richtung Infrastruktur geroutet wird.

• Inbound auf WAN/Partner-Interfaces (Internet/Extranet)
• Inbound auf VPN/Overlay-Interfaces, wenn Remote Sites nicht infra-trusted sind
• Optional: auf LAN-Edge SVIs bei großen Campus-Designs

Konfigurationspattern: iACL als Extended ACL (IPv4)

Dieses Pattern schützt ein Infrastruktur-Prefix (z. B. 10.255.0.0/16). Es erlaubt Management nur aus Admin-Netzen und blockt den Rest. Passe Netze und Ports an deinen Betrieb an.

ip access-list extended IACL_INFRA_V4
 remark --- Allow admin management to infra ---
 permit tcp 10.99.0.0 0.0.0.255 10.255.0.0 0.0.255.255 eq 22
 permit tcp 10.99.0.0 0.0.0.255 10.255.0.0 0.0.255.255 eq 443
 permit udp 10.99.0.0 0.0.0.255 10.255.0.0 0.0.255.255 eq 161

 remark --- Allow routing/control only from router loopbacks (example) ---
 permit tcp 10.255.0.0 0.0.255.255 10.255.0.0 0.0.255.255 eq 179
 permit ospf 10.255.0.0 0.0.255.255 10.255.0.0 0.0.255.255

 remark --- Deny everything else to infra ---
 deny   ip any 10.255.0.0 0.0.255.255 log

 remark --- Permit other traffic (not to infra) ---
 permit ip any any

Konfigurationspattern: iACL auf Interface anwenden (Ingress)

Wichtig: iACLs sollen „untrusted → infra“ blocken. Deshalb bindest du sie inbound an die Interfaces, über die untrusted Traffic eintritt.

interface GigabitEthernet0/0
 description WAN OUTSIDE
 ip access-group IACL_INFRA_V4 in

IPv6 iACLs: ICMPv6 nicht blind blocken

Bei IPv6 musst du sorgfältiger sein: ICMPv6 ist für ND/PMTUD essenziell. Für iACLs gilt daher: blocke Management/Control zur Infrastruktur von untrusted Sources, aber lass notwendige ICMPv6-Funktionen in den relevanten Segmenten zu. iACLs wirken am besten auf Infrastruktur-Prefixes (Loopbacks/Mgmt), nicht auf Client-LAN ND-Domänen.

• Fokus: Schutz von Infrastruktur-Adressen (Loopbacks/Mgmt)
• ICMPv6 Packet Too Big/Time Exceeded für Diagnose/PMTUD beachten
• ND/RA gehören ins LAN-Segment-Design (RA Guard, etc.), nicht in WAN-iACL

Exception Handling: NTP, DNS, Logging und „Infra als Client“

Infrastruktur ist nicht nur Ziel, sondern auch Quelle: Router sprechen mit NTP, DNS, Syslog, TACACS/RADIUS, PKI. Wenn du iACLs zu breit anwendest, blockst du ungewollt diese Pfade. Best Practice ist ein klares Rollenmodell: Welche Dienste nutzt der Router, wohin darf er, und von wo darf er gemanaged werden?

• NTP: Router → NTP-Server (outbound), nicht „any → infra“
• Syslog: Router → Collector (outbound)
• AAA: Router ↔ TACACS/RADIUS (targeted)
• PKI: Router ↔ CRL/OCSP (underlay erreichbar)

iACLs vs. CoPP und ZBFW: Zusammenspiel statt Konkurrenz

iACLs reduzieren Angriffsfläche im Datenpfad (was überhaupt zur Infrastruktur kommt). CoPP schützt die CPU zusätzlich (rate-limit). ZBFW bietet stateful Policies zwischen Zonen. Die beste Praxis ist: iACLs als Baseline, CoPP als CPU-Schutz, ZBFW für echte Segment-Policies.

• iACL: blockt untrusted → infra früh
• CoPP: begrenzt verbleibenden Control-Plane Traffic
• ZBFW: stateful Zonen-Policies (LAN/WAN/DMZ/VPN)

Typische Fehler und Lockout-Risiken

iACLs sind mächtig – und können dich aussperren, wenn du Management nicht sauber definierst. Häufige Fehler sind falsche Source-Netze (Admin-Netz geändert), fehlende Monitoring-Ausnahmen oder zu breite „deny any infra“ ohne Permit für Routing-Peers.

• Admin-Netz nicht erlaubt → SSH/HTTPS Lockout
• SNMP/Syslog blockiert → Monitoring blind
• BGP/OSPF Peer-Traffic geblockt → Routing flaps
• Zu viel Logging → CPU/Log-Flood

Monitoring und Betrieb: iACLs messbar machen

Damit iACLs im Betrieb nicht zum „Black Box“ werden, brauchst du Metriken: ACL-Hits, Logging-Auswertung und klare Change-Prozesse. Gute iACLs reduzieren Logs, weil sie Scans früh droppen – aber du solltest initial loggen, um Muster zu sehen.

Checks

show access-lists IACL_INFRA_V4
show logging | include IACL_INFRA_V4
show ip interface GigabitEthernet0/0 | include access

Best Practices: iACL Baseline für WAN Edge

Diese Regeln liefern in der Praxis den größten Sicherheitsgewinn bei geringem Betriebsrisiko.

• Infrastruktur-Prefixes strikt definieren (Loopbacks/Mgmt getrennt)
• Untrusted Ingress blockt grundsätzlich Richtung Infra
• Management nur aus Admin-Netzen, Monitoring gezielt
• Routing-Protokolle nur zwischen Routern erlauben
• Logging initial aktiv, später reduzieren

Quick-Runbook: iACL Incident Isolation

Wenn nach iACL-Rollout etwas „plötzlich nicht geht“, prüfst du zuerst ACL-Hits, dann betroffene Flows, dann Placement. So findest du False Positives schnell.

show access-lists IACL_INFRA_V4
show ip interface GigabitEthernet0/0 | include access
show logging | include IACL_INFRA_V4
show ip route <infra-ip>
show ip cef <infra-ip> detail

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.