Cisco-Router-Konfiguration für Netzwerksicherheit: ACL, Anti-Scan und Best Practices

Netzwerksicherheit auf Cisco-Routern beginnt mit klaren Trust-Grenzen und einer konsequenten Reduzierung der Angriffsfläche. In Büro- und Filialnetzen sind Access Control Lists (ACLs) oft die pragmatischste Maßnahme, um Segmentierung durchzusetzen, Management-Zugriffe abzusichern und unerwünschten Traffic (z. B. Scans) zu begrenzen. Ergänzt durch Anti-Scan-Mechanismen, sauberes Logging sowie robuste Betriebsstandards entsteht ein wirksames Sicherheitsniveau, ohne den Router mit unnötiger Komplexität zu überladen.

Sicherheitsprinzipien: Was Sie mit Router-Security realistisch erreichen

Ein Router ersetzt keine Next-Gen-Firewall, kann aber sehr effektiv Basis-Sicherheit liefern: Segmentgrenzen, Managementschutz, einfache Inbound-Regeln und Control-Plane-Schutz. Entscheidend ist das Minimalprinzip: nur erlauben, was benötigt wird.

• Least Privilege: nur definierte Netze/Ports erlauben
• Trust Boundaries: Guest/IoT/Management strikt getrennt
• Management-Plane schützen (SSH-only, Zugriff nur aus MGMT-Netz)
• Control-Plane entlasten (Scans/Brute Force begrenzen)
• Logging/Audit aktivieren (NTP + Syslog)

Grundlage: Saubere Segmentierung als Sicherheitsmultiplikator

ACLs sind am wirksamsten, wenn VLAN-Rollen klar definiert sind. Typisch sind: Users, Guest, IoT und Management. Policies werden an den Segmentgrenzen angewendet und bleiben dadurch übersichtlich.

• VLAN10-MGMT: nur IT, Managementzugriffe
• VLAN20-USERS: Mitarbeitergeräte
• VLAN40-IOT: Drucker/IoT (restriktiv)
• VLAN50-GUEST: Gäste (nur Internet)

ACL-Best Practices: Struktur, Naming und Platzierung

ACLs sollten so geschrieben sein, dass sie im Betrieb lesbar bleiben. Nutzen Sie konsistente Namen und ordnen Sie Regeln nach Zweck. Platzieren Sie ACLs an der richtigen Stelle: meist inbound am Quellsegment (dort, wo unerwünschter Traffic entsteht).

• Naming: ACL-GUEST-IN, ACL-IOT-IN, MGMT_ONLY
• Inbound am VLAN-Interface: reduziert unnötigen Traffic im Netz
• Explizite Deny-Regeln für interne Netze, danach Permit ins Internet
• Keine „Any-Any“-Freigaben ohne dokumentierten Zweck

CLI-Check: ACL-Zuordnung sichtbar machen

show access-lists
show running-config | include ip access-group

Basis-ACL 1: Guest isolieren (nur Internet)

Die wichtigste Büro-/Filialregel: Gäste dürfen nicht auf interne Netze zugreifen. Damit reduzieren Sie das Risiko von lateralem Movement und vereinfachen Compliance-Anforderungen deutlich.

Beispiel: Guest blockt interne RFC1918-Netze

ip access-list extended ACL-GUEST-IN
 deny ip 10.10.50.0 0.0.0.255 10.0.0.0 0.255.255.255
 deny ip 10.10.50.0 0.0.0.255 172.16.0.0 0.15.255.255
 deny ip 10.10.50.0 0.0.0.255 192.168.0.0 0.0.255.255
 permit ip 10.10.50.0 0.0.0.255 any
interface GigabitEthernet0/1.50

ip access-group ACL-GUEST-IN in

Erwartete Ergebnisse

• Guest erreicht Internetziele, aber keine internen Subnetze
• ACL-Hits steigen bei internen Testzugriffen (Deny zählt)

Basis-ACL 2: IoT restriktiv (nur definierte Ziele/Ports)

IoT-Geräte sind häufig schlecht patchbar und sollten nur minimalen Zugriff erhalten. Erlauben Sie nur notwendige Ziele (z. B. DNS, NTP, Print-Server) und blockieren Sie interne Netze konsequent.

Beispiel: IoT nur DNS/NTP und ein Print-Ziel

ip access-list extended ACL-IOT-IN
 permit udp 10.10.40.0 0.0.0.63 10.10.10.10 0.0.0.0 eq 53
 permit udp 10.10.40.0 0.0.0.63 10.10.10.11 0.0.0.0 eq 53
 permit udp 10.10.40.0 0.0.0.63 10.10.10.10 0.0.0.0 eq 123
 permit tcp 10.10.40.0 0.0.0.63 10.10.20.20 0.0.0.0 eq 9100
 deny ip 10.10.40.0 0.0.0.63 10.0.0.0 0.255.255.255
 deny ip 10.10.40.0 0.0.0.63 172.16.0.0 0.15.255.255
 deny ip 10.10.40.0 0.0.0.63 192.168.0.0 0.0.255.255
 permit ip 10.10.40.0 0.0.0.63 any
interface GigabitEthernet0/1.40

ip access-group ACL-IOT-IN in

Management-Sicherheit: SSH-only und Zugriff einschränken

Viele Scans zielen direkt auf Management-Ports. Eine Access-Class auf VTY verhindert, dass SSH von beliebigen Netzen erreichbar ist. Zusätzlich sollten unnötige Services deaktiviert werden.

Beispiel: SSH-only + VTY-Zugriff nur aus MGMT-Netz

no ip http server
no ip http secure-server
ip ssh version 2
ip access-list standard MGMT_ONLY

permit 10.10.10.0 0.0.0.255

deny   any
line vty 0 4

transport input ssh

access-class MGMT_ONLY in

login local

exec-timeout 10 0

Anti-Scan und Brute-Force: Angriffsfläche reduzieren

„Anti-Scan“ bedeutet auf Routern meist: Managementzugriffe begrenzen, Fehlversuche drosseln und Control-Plane nicht unnötig exponieren. Damit wird der Router resistenter gegen automatisierte Scans und Credential-Stuffing.

Login-Schutz (vorsichtig dosieren)

login block-for 60 attempts 5 within 60
login on-failure log
login on-success log

Externe Interfaces „leiser“ machen

Deaktivieren Sie Discovery-Funktionen auf WAN-Interfaces, damit weniger Informationen nach außen dringen. Das ist ein kleiner, aber sinnvoller Best-Practice-Härtungsschritt.

interface GigabitEthernet0/0
 description WAN-ISP
 no cdp enable

Logging & Audit: Security ohne Zeitstempel ist blind

Ohne NTP und zentrale Logs können Sie Angriffsversuche nicht sauber nachweisen. Syslog ist daher ein Sicherheitsbaustein, nicht nur „Monitoring“. Nutzen Sie Zeitstempel mit Millisekunden und senden Sie Logs an einen zentralen Server.

Beispiel: NTP + Syslog Baseline

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
ntp server 192.0.2.11
logging buffered 64000 informational

logging host 192.0.2.20

logging trap informational

Verifikation Logging

show clock
show ntp status
show logging | last 50

Best Practices für sichere ACL-Änderungen (Change-Methodik)

ACLs sind sicherheitskritisch und können Traffic „hart“ blockieren. Änderungen sollten daher wie ein Change behandelt werden: Pre-/Post-Checks, begrenzte Änderung, sofortige Validierung und Rollback-Bereitschaft.

• Pre-Check: aktuelle ACL sichern, Zählerstände notieren
• Änderung in kleinen Schritten, danach Ping/Traceroute/Service-Tests
• Post-Check: ACL-Hits prüfen, Logs auswerten, Abnahme dokumentieren
• Rollback: letzte stabile ACL-Version bereithalten

ACL-Change-Checks (SOP)

show access-lists
show logging | last 30
show ip interface brief
ping 8.8.8.8 repeat 10

Typische Fehler bei Router-Security (und wie Sie sie vermeiden)

Viele Sicherheitslücken entstehen durch „Bequemlichkeit“: offene Managementzugänge, zu breite ACLs und fehlendes Logging. Mit wenigen Standards vermeiden Sie die häufigsten Fehler zuverlässig.

• SSH aus allen Netzen erreichbar: MGMT_ONLY fehlt
• Guest kann intern: ACL am falschen Interface oder falsche Richtung
• IoT zu breit: „permit ip any any“ statt Ziel/Port-Whitelist
• Keine Logs/NTP: Ereignisse nicht korrelierbar, Audit nicht möglich
• Unklare Naming: ACLs und Policies nicht wartbar

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.