Site icon bintorosoft.com

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

Red Snapper

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.

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.

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.

Infrastruktur-Set (Beispiel)

INFRA = Loopbacks + Mgmt-IPs + 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.

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.

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.

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.

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?

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version