Security-Hardening für Cisco-Router: Mindeststandards, die Pflicht sind

Red Snapper

3 weeks ago

Security-Hardening für Cisco-Router ist im Unternehmensbetrieb keine „Option“, sondern Grundvoraussetzung: Ohne Mindeststandards entstehen vermeidbare Angriffsflächen durch unsichere Management-Zugriffe, fehlende Protokollierung oder unkontrollierte Control-Plane-Last. Dieser Leitfaden beschreibt praxisnahe Pflichtmaßnahmen, die in Büro, Filiale und Enterprise-Edge umgesetzt werden sollten, und zeigt robuste Cisco-CLI-Beispiele, die sich als Baseline-Template eignen.

Zielbild: Was „Mindeststandards“ im Router-Hardening bedeuten

Mindeststandards zielen auf drei Kernbereiche: sichere Administration (Management-Plane), robuste Router-Stabilität (Control Plane) und nachvollziehbarer Betrieb (Logging/Monitoring). Damit verhindern Sie die häufigsten realen Ursachen für Incidents: offene Zugänge, schwache Authentifizierung und fehlende Sichtbarkeit.

Management-Plane absichern (wer darf konfigurieren?)
Control Plane schützen (was darf den Router belasten?)
Datenebene kontrollieren (was darf durch den Router?)
Betrieb nachvollziehbar machen (Logs, Zeit, Auditing)

Pflicht 1: Unsichere Services deaktivieren und sichere Defaults setzen

Viele Router laufen mit Funktionen, die im Unternehmensbetrieb nicht benötigt werden. Alles, was nicht gebraucht wird, sollte deaktiviert sein – das reduziert Angriffsfläche und Fehlkonfigurationen.

DNS-Lookups bei Tippfehlern deaktivieren (verhindert Hänger bei CLI)
HTTP/HTTPS-Server auf dem Router deaktivieren (wenn nicht benötigt)
CDP/LLDP auf WAN-Interfaces deaktivieren (Informationsabfluss)
Unnötige Dienste und Broadcast-Helper vermeiden

Beispiel: Sichere Basis-Defaults

no ip domain-lookup
service password-encryption
no ip http server

no ip http secure-server
interface GigabitEthernet0/0

description WAN-ISP

no cdp enable

Pflicht 2: Management-Zugriff nur per SSH und nur aus Management-Netzen

Telnet und offene Management-Zugriffe sind im Unternehmensumfeld nicht akzeptabel. SSH-only, Zugriffsbeschränkung per ACL und klare Session-Timeouts gehören zur Pflicht.

SSH v2 aktivieren, Telnet blockieren
VTY-Zugriff auf definierte Management-Subnetze einschränken
Exec-Timeouts setzen, um verwaiste Sessions zu beenden
Banner/Legal Notice optional für Compliance

Beispiel: SSH-only + VTY-Zugriff beschränken

ip domain-name example.local
crypto key generate rsa modulus 2048
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

Pflicht 3: Starke Authentifizierung und Rechtekonzept (AAA)

Ein gemeinsames „admin/admin“ oder geteilte Passwörter sind ein Audit- und Sicherheitsrisiko. Mindeststandard ist ein lokaler Admin mit Secret; im Unternehmen ist AAA (z. B. TACACS+) mit Accounting deutlich besser.

Lokale Benutzer mit privilege und „secret“ statt „password“
Rollen/Least-Privilege (nicht jeder braucht privilege 15)
AAA mit zentraler Authentifizierung (wenn verfügbar)
Accounting für Nachvollziehbarkeit von Änderungen

Beispiel: Lokaler Admin (Mindeststandard)

username netadmin privilege 15 secret <SECRET>

Beispiel: AAA-Grundstruktur (Konzeptmuster)

aaa new-model
aaa authentication login default local
aaa authorization exec default local

Pflicht 4: Zeit, Logging und Auditing aktivieren

Ohne korrekte Zeitstempel sind Logs kaum verwertbar. Mindeststandard ist NTP plus Syslog mit definiertem Level. Damit sind Changes, Angriffsversuche und Routing-/Interface-Flaps nachvollziehbar.

NTP konfigurieren, bevorzugt redundante Quellen
Syslog zentralisieren (SIEM/NMS), sinnvolle Log-Level setzen
Log-Timestamps aktivieren
Konfig-Backups/Versionierung als Prozess (vor/nach Change)

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

Pflicht 5: SNMP sicher (SNMPv3) oder konsequent deaktivieren

SNMPv2c mit „public“ ist ein Klassiker in Security-Audits. Mindeststandard ist SNMPv3 mit Auth+Priv oder – wenn nicht benötigt – konsequent kein SNMP.

SNMPv3 mit Auth (SHA) und Privacy (AES)
Quellnetze zum NMS einschränken (zusätzlich über ACLs)
SNMP Traps gezielt konfigurieren

Beispiel: SNMPv3 (Mindeststandard)

snmp-server group NMS v3 priv
snmp-server user snmpmon NMS v3 auth sha <AUTH> priv aes 128 <PRIV>

Pflicht 6: Control Plane schützen (CoPP/Rate-Limits als Mindestdisziplin)

Der Router muss gegen unnötige Last und Flooding geschützt werden, sonst kann er trotz korrekter Datenebene instabil werden. Mindestens sollten Sie Management-Zugriffe einschränken und unnötige Control-Plane-Exposition vermeiden.

Management nur aus definierten Netzen
ICMP/SSH nicht „für die Welt“ offen lassen
Bei Enterprise-Edges: CoPP einsetzen, um Control-Plane-Traffic zu begrenzen

Beispiel: Management-Plane restriktiv halten (wirksamster Mindestschritt)

ip access-list extended CP-MGMT
 permit tcp 10.10.10.0 0.0.0.255 any eq 22
 permit udp 10.10.10.0 0.0.0.255 any eq 161
 deny   ip any any

Pflicht 7: Datenebene absichern (ACLs an Trust-Grenzen)

Ein Router ist häufig auch Segment-Gateway. Mindeststandard ist, sensible Segmente (z. B. Guest, IoT) zu begrenzen und nur notwendige Verbindungen zu erlauben. „Any-Any“ ist in Bürosegmentierung kein akzeptabler Default.

Guest: nur Internet, kein Zugriff auf interne Netze
IoT/Printer: nur benötigte Ports zu Servern/Printdiensten
Management: nur aus Management-VLANs

Beispiel: Guest-VLAN vom internen Netz trennen

ip access-list extended ACL-GUEST-IN
 deny ip 10.10.30.0 0.0.0.255 10.10.0.0 0.0.255.255
 permit ip 10.10.30.0 0.0.0.255 any
interface GigabitEthernet0/1.30

description VLAN30-GUEST

ip access-group ACL-GUEST-IN in

Pflicht 8: Passwort- und Schlüsselhygiene

Selbst die beste Architektur scheitert an schwacher Credential-Praxis. Mindeststandard ist die Nutzung von „secret“, keine Klartext-Passwörter, und ein Prozess für Rotation und Deprovisionierung.

„secret“ statt „password“ nutzen
Keine geteilten Accounts, keine generischen Admins
Rotation von PSKs/Zugangsdaten, insbesondere nach Personalwechsel
Wenn möglich: Zertifikate/PKI statt PSK bei VPNs

Pflicht 9: Sichere Konfiguration speichern und Recovery sicherstellen

Ein Hardening ist nur dann betriebssicher, wenn Konfigurationsänderungen kontrolliert, gesichert und im Notfall rückgängig gemacht werden können. Mindeststandard: Startup-Config aktuell halten und Backups vor/nach Changes.

Konfiguration nach Changes speichern
Backups versionieren (z. B. Repo oder Backup-Server)
Rollback-Plan dokumentieren (Notfallzugang, Console/OOB)

Beispiel: Konfiguration sichern

copy running-config startup-config

Pflicht 10: Mindest-Checks zur Abnahme des Hardening

Hardening ist nur „fertig“, wenn es überprüfbar ist. Diese Checks bestätigen, dass Management-Zugriffe eingeschränkt sind, Logging funktioniert und der Router betriebsstabil bleibt.

show running-config | include ip ssh|line vty|access-class|username|aaa|logging|ntp|snmp
show ip ssh
show logging | last 50
show ntp status
show processes cpu sorted
show processes memory sorted

Minimal-Hardening als Template: Kompakte Baseline (zusammengeführt)

Dieses Muster bündelt typische Pflichtbausteine für Büro/Filiale. Es ist als Startpunkt gedacht und muss an Ihre Policies (Management-Netze, Logging-Server, AAA) angepasst werden.

no ip domain-lookup
service password-encryption
no ip http server
no ip http secure-server

ip domain-name example.local
username netadmin privilege 15 secret <SECRET>

crypto key generate rsa modulus 2048
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

service timestamps log datetime msec
ntp server 192.0.2.10 prefer

logging buffered 64000 informational
logging host 192.0.2.20
logging trap informational

snmp-server group NMS v3 priv
snmp-server user snmpmon NMS v3 auth sha <AUTH> priv aes 128 <PRIV>

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.