Cisco-Router-Konfiguration: Standardleitfaden für Passwort- & Key-Management

Passwort- und Key-Management ist bei Cisco-Routern kein „IT-Organisationsdetail“, sondern ein Sicherheits- und Betriebsstandard: Es entscheidet darüber, ob Adminzugriffe nachvollziehbar sind, ob VPNs stabil bleiben und ob ein Incident kontrolliert abgearbeitet werden kann. Viele Sicherheitsvorfälle entstehen durch geteilte Accounts, unklare Schlüsselrotation oder ungeschützte Secrets in Tickets/Docs. Dieser Standardleitfaden beschreibt praxistaugliche Regeln für Passwörter, SSH-Keys, VPN-Pre-Shared Keys, Zertifikate sowie für sichere Ablage, Rotation und Notfallzugänge – inklusive CLI-Bausteinen, die sich als Golden Config einsetzen lassen.

Grundprinzipien: Least Privilege, Nachvollziehbarkeit, Rotation

Ein gutes Passwort- und Key-Management verfolgt drei Ziele: minimale Rechte, eindeutige Zuordnung (wer war das?) und planbare Rotation ohne Downtime. Alles, was diese Ziele verletzt, ist ein Risiko.

• Keine Shared Accounts: jeder Admin hat einen eigenen Zugang
• Rollen statt „alle privilege 15“ (Viewer/Operator/Admin)
• Secrets niemals in Klartext in Tickets, E-Mails oder Chat
• Rotation nach Plan (und sofort bei Verdacht/Offboarding)
• Notfallzugang separat, streng kontrolliert

Passwortstandard: Anforderungen, Speicherung und Umgang

Passwörter müssen stark und gut verwaltbar sein. In der Praxis ist die wichtigste Regel nicht „komplexe Zeichen“, sondern ein sauberer Prozess: Passwortmanager, eindeutige Zuordnung, dokumentierte Rotation.

• Passwortmanager als einzige Ablage (kein Excel, kein Wiki, keine Tickets)
• Unique pro Gerät und pro Account (keine Wiederverwendung)
• Rotation: periodisch (z. B. 90–180 Tage) und bei Personalwechsel sofort
• Break-Glass-Account: getrennt verwalten, Rotation nach jedem Einsatz

CLI: Lokale Accounts (Minimalstandard, ohne Klartext)

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

Enable-Secret und lokale Absicherung (wenn lokal erforderlich)

Wenn lokale Authentifizierung notwendig ist (z. B. als AAA-Fallback), müssen enable secret und user secrets genutzt werden. Vermeiden Sie „enable password“ und Klartextspeicherung.

CLI: enable secret (statt enable password)

enable secret <SECRET>

AAA als Unternehmensstandard: Zentral, rollengesteuert, auditierbar

Für Unternehmen ist AAA der Standard, weil Authentifizierung, Autorisierung und Accounting zentral gesteuert werden können. Lokale Accounts dienen dann nur als Fallback (Notfall).

• TACACS+ bevorzugt für Device-Admin (bessere Command-Autorisierung)
• RADIUS häufig für Network Access, TACACS+ für Device Management
• Accounting aktivieren (wer hat wann was gemacht?)
• Fallback: local nur, wenn AAA nicht erreichbar

CLI: AAA mit TACACS+ und lokalem Fallback (Muster)

aaa new-model
tacacs server TACACS1

address ipv4 10.10.10.10

key 
aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ local

aaa accounting exec default start-stop group tacacs+

SSH-Key-Management: Host-Keys, Zugriff und Algorithmen

SSH ist Pflicht für Adminzugriffe. Dazu gehören stabile Host-Keys, sinnvolle Key-Größen und klare Regeln, wer SSH nutzen darf. Host-Keys müssen planbar rotierbar sein, ohne dass Monitoring/Automation überraschend bricht.

• SSHv2 verpflichtend, Telnet deaktiviert
• Host-Key: RSA 2048+ als Mindeststandard (plattformabhängig)
• SSH-Zugriff nur aus Managementnetz (Access-Class)
• Host-Key-Rotation: geplant, dokumentiert, mit Change-Fenster

CLI: SSH aktivieren und Host-Key erzeugen

ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2

CLI: VTY nur SSH, Zugriff begrenzen

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

exec-timeout 10 0

VPN-Keys: Pre-Shared Keys (PSK) richtig verwalten

PSKs sind in Site-to-Site-VPNs häufig. Das Risiko ist hoch, wenn PSKs wiederverwendet oder unkontrolliert verteilt werden. Für viele Standorte sind per-Peer-PSKs Pflicht.

• PSK pro Tunnel/Peer eindeutig (keine Global-PSKs)
• Rotation geplant (z. B. halbjährlich) und bei Verdacht sofort
• Verteilung nur über sicheren Kanal (Passwortmanager/Secrets-Store)
• Änderung immer als Change mit Abnahme (SA up + Traffic-Nachweis)

VPN-Verifikation nach PSK-Rotation

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

Zertifikate statt PSK: Wann PKI sinnvoll ist

Ab vielen Standorten oder bei hohen Compliance-Anforderungen sind Zertifikate oft besser skalierbar als PSKs. Sie erleichtern Rotation, reduzieren das Risiko durch Leaks und erlauben klarere Identitäten.

• Sinnvoll bei vielen Peers (z. B. 20+ Standorte) und strengen Audit-Anforderungen
• CA/PKI-Prozess: Enrollment, Renewal, Revocation (CRL/OCSP) definieren
• Lifecycle: Ablaufdaten überwachen (Monitoring/Alerting)
• Notfall: Zertifikat-Revoke bei Kompromittierung, schneller Ersatz

Secrets in Konfigurationen: Sichtbarkeit und Schutz

Ein realistischer Standard berücksichtigt, dass Konfigs in Backups/Repos landen. Verhindern Sie Klartext-Secrets, minimieren Sie die Verteilung und schützen Sie Backups organisatorisch.

• Nur „secret“ nutzen (nicht „password“ in Klartext)
• Backups verschlüsselt speichern, Zugriff rollenbasiert
• Konfigs niemals ungeschützt in Tickets/Chats posten
• Review-Prozess: Secrets in Logs/Docs entfernen (Redaction)

Rotation: Zeitplan, Trigger und Abnahme

Rotation muss planbar sein, sonst wird sie verschleppt. Definieren Sie einen festen Rhythmus und klare Trigger. Jede Rotation hat eine Abnahme: Adminzugang funktioniert, VPNs stabil, Logs ok.

• Planrotation: Passwörter/PSKs/Zertifikate nach festem Intervall
• Triggerrotation: Offboarding, Verdacht, Leak, Audit-Fund
• Change-Fenster: bei VPN/Zertifikaten verbindlich
• Abnahme: Login-Test, VPN SA/Traffic, Syslog/NTP weiterhin ok

Abnahme-Check (Rotation, kompakt)

show ip ssh
show users
show crypto ikev2 sa
show crypto ipsec sa
show logging | last 50

Notfallzugang (Break Glass): Pflicht, aber streng kontrolliert

Break-Glass ist nötig, wenn AAA ausfällt oder ein Fehler den Zugriff blockiert. Gleichzeitig ist es ein attraktives Angriffsziel. Daher braucht es strengere Regeln als normale Accounts.

• Separater lokaler Admin mit sehr starkem Secret
• Ablage im Passwortmanager mit „2-Personen“-Freigabe (wenn möglich)
• Rotation nach jedem Einsatz
• Dokumentierter Einsatzprozess (Ticket-ID, Begründung, Zeitpunkt)

Operational SOP: Wie das Betriebsteam sicher arbeitet

Technik alleine reicht nicht. Definieren Sie SOPs, damit Secrets nicht „nebenbei“ geleakt werden. Das Betriebsteam braucht klare Regeln für Tickets, Screenshots und Exporte.

• Keine Secrets in Tickets: nur Referenzen (Secret-ID), nicht Inhalte
• Konfig-Exports redigieren (Redaction) vor Weitergabe
• Peer-Review für Änderungen an AAA/VPN/Keys
• Änderungen nur mit Pre-/Post-Checks und Abnahmeprotokoll

Minimaler Golden-Config-Block: Passwort- & Key-Management (Copy/Paste)

Dieser Block bündelt die wichtigsten Mindeststandards für Passwort- und Key-Management auf Cisco-Routern. Platzhalter sind zu ersetzen, Secrets werden nicht im Klartext dokumentiert.

! ===== PASSWORD & KEY MANAGEMENT BASELINE =====
no ip http server
no ip http secure-server
no ip domain-lookup
ip domain-name example.local

crypto key generate rsa modulus 2048

ip ssh version 2
username netadmin privilege 15 secret 

enable secret 
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
aaa new-model

tacacs server TACACS1

address ipv4 10.10.10.10

key 
aaa authentication login default group tacacs+ local

aaa authorization exec default group tacacs+ local

aaa accounting exec default start-stop group tacacs+

! ===== END BASELINE =====

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.