Cisco-Router-Konfiguration für sicheres Management: SSH, AAA und RBAC

Sicheres Management ist die wichtigste Sicherheitsmaßnahme an Cisco-Routern: Wenn Management-Zugriffe offen oder schwach abgesichert sind, helfen auch gute VLANs, VPNs oder ACLs nur begrenzt. Eine saubere Management-Konfiguration basiert auf drei Säulen: SSH-only (verschlüsselte Administration), AAA (zentralisierte Authentifizierung/Autorisierung/Accounting) und RBAC (rollenbasierte Rechte statt „jeder ist Admin“). Dieser Leitfaden zeigt praxiserprobte Mindeststandards und konkrete CLI-Beispiele, die sich als Baseline-Template eignen.

Zielbild: Was „sicheres Management“ konkret bedeutet

Ein Router gilt managementseitig als sicher, wenn Zugriffe nachvollziehbar, minimal und kontrolliert sind. Das bedeutet: nur verschlüsselte Protokolle, Zugriff nur aus Management-Netzen, individuelle Accounts, klare Rollen und zentrale Logs.

• Nur SSH (keine Klartextprotokolle, kein unnötiger Webserver)
• Zugriff nur aus Management-Subnetzen (Access-Class/ACL)
• AAA mit Accounting (wer hat wann was gemacht?)
• RBAC/Least Privilege (nicht jeder braucht privilege 15)
• Zeit und Logs korrekt (NTP, Syslog, Zeitstempel)

Voraussetzungen: Management-Netz, NTP und Logging

Bevor Sie AAA/RBAC „perfekt“ machen, müssen Management-Pfade stabil und auditierbar sein. Ein dediziertes Management-VLAN/VRF ist ideal, mindestens aber ein klar definiertes Management-Subnetz.

• Management-Netz (z. B. 10.10.99.0/24) festlegen und dokumentieren
• NTP aktivieren (sonst sind Logs nicht korrelierbar)
• Syslog zentralisieren (SIEM/NMS), Log-Level sinnvoll wählen

Beispiel: NTP und 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

SSH-only: Sichere Remote-Administration einrichten

SSH-only ist der Mindeststandard. Dazu gehören RSA-Keys, SSH v2, harte VTY-Einstellungen und ein sinnvoller Session-Timeout. Vermeiden Sie zudem DNS-Lookups bei Tippfehlern, um CLI-Hänger zu vermeiden.

• RSA-Key erzeugen, SSH v2 erzwingen
• VTY nur SSH erlauben, keine Telnet-Backdoor
• Exec-Timeout setzen, Idle-Sessions beenden
• Unnötige Services deaktivieren (HTTP/HTTPS, falls nicht benötigt)

Beispiel: SSH aktivieren und unsichere Services deaktivieren

no ip domain-lookup
no ip http server
no ip http secure-server
ip domain-name example.local

crypto key generate rsa modulus 2048

ip ssh version 2

Beispiel: VTY auf SSH-only und Timeout setzen

line vty 0 4
 transport input ssh
 exec-timeout 10 0

Zugriff einschränken: Management-ACL (Access-Class) als Pflicht

SSH ist verschlüsselt, aber nicht automatisch „sicher“, wenn es aus jedem Netz erreichbar ist. Beschränken Sie Management-Zugriffe auf ein definiertes Subnetz (oder besser: Management-VRF). Das reduziert Angriffsfläche massiv.

Beispiel: VTY-Zugriff nur aus Management-Subnetz erlauben

ip access-list standard MGMT_ONLY
 permit 10.10.99.0 0.0.0.255
 deny   any
line vty 0 4

access-class MGMT_ONLY in

transport input ssh

AAA: Authentifizierung, Autorisierung und Accounting

AAA liefert zentrale Kontrolle und Nachvollziehbarkeit. In Enterprise-Umgebungen ist TACACS+ typisch, weil es Command-Authorization und sauberes Accounting ermöglicht. Für kleine Umgebungen kann AAA zunächst lokal starten und später auf TACACS+ erweitert werden.

AAA-Modelle im Überblick

• Local-only: schnell, aber keine zentrale Kontrolle und schwächere Audits
• AAA mit Fallback: TACACS+/RADIUS primär, lokal als Notfall
• AAA mit Accounting: zentrale Nachweise für Logins und Befehle

Beispiel: AAA aktivieren und lokale Fallback-Strategie

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

Beispiel: AAA mit TACACS+ (Konzeptmuster)

aaa new-model
tacacs server TACACS1
 address ipv4 10.10.99.10
 key <TACACS_KEY>
aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ local

aaa accounting exec default start-stop group tacacs+

RBAC/Least Privilege: Rollen statt „alle sind Admin“

RBAC bedeutet, dass Benutzer nur die Rechte erhalten, die sie benötigen. Praktisch wird das oft über TACACS+-Rollen oder lokale Privilege-Level umgesetzt. Ziel ist: Operatoren dürfen prüfen, Admins dürfen ändern.

Pragmatisches Rollenmodell (Beispiel)

• Role „Viewer“: nur show-Kommandos, keine Konfigänderungen
• Role „Operator“: Troubleshooting/Interface Reset nach Prozess
• Role „Admin“: volle Konfiguration, aber auditierbar

Beispiel: Lokale Nutzer mit Privilege-Level (Basis-RBAC)

username viewer privilege 1 secret <SECRET>
username netadmin privilege 15 secret <SECRET>

Beispiel: Privilege für Show-Kommandos erweitern (pragmatischer Ansatz)

privilege exec level 1 show ip
privilege exec level 1 show interfaces
privilege exec level 1 show logging
privilege exec level 1 show crypto

Zusätzliche Schutzmaßnahmen: Login-Schutz und Banner

Zusätzliche Controls reduzieren Brute-Force-Risiko und unterstützen Compliance. Wichtig ist, dass Controls nicht den Notfallzugang verhindern (z. B. bei TACACS-Ausfall).

• Login-Block bei wiederholten Fehlversuchen (sinnvoll dosieren)
• Banner (Legal Notice) für Compliance
• Exec-Timeouts und Session-Limits

Beispiel: Login-Schutz (vorsichtig einsetzen)

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

Beispiel: Banner (optional)

banner motd ^C
Unauthorized access is prohibited.
^C

Management-Verifikation: Erwartete Ergebnisse und Checks

Nach der Umsetzung sollten Sie objektiv prüfen, ob Management wirklich sicher ist: SSH aktiv, VTY nur aus Management-Netzen erreichbar, AAA/Accounting greift und Logs sind sauber.

Checks für SSH, VTY und AAA

show ip ssh
show running-config | include line vty|transport input|access-class
show running-config | include aaa|tacacs|username

Checks für Zeit und Logging

show clock
show ntp status
show logging | last 50

Minimal-Template: Sicheres Management als Baseline (kompakt)

Dieses Muster bündelt die wichtigsten Elemente für sicheres Management: SSH-only, Management-Restriktion, lokale Admins, NTP und Syslog. Es ist als Startpunkt gedacht und wird für Enterprise-Umgebungen typischerweise durch TACACS+ und strengere Rollen erweitert.

no ip domain-lookup
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.99.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 host 192.0.2.20
logging trap informational

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.