Audit der Cisco-Router-Konfiguration für Enterprise: Security, Performance und Operational Readiness

Ein Enterprise-Audit der Cisco-Router-Konfiguration prüft nicht nur „ist es sicher?“, sondern auch „läuft es stabil unter Last?“ und „kann das Betriebsteam Störungen schnell beherrschen?“. Die drei Audit-Dimensionen sind Security, Performance und Operational Readiness. In der Praxis entstehen die kritischsten Findings durch offene Managementflächen, fehlende Auditfähigkeit (NTP/Syslog/AAA), unkontrolliertes Routing (fehlende Filterpflicht), NAT/VPN-Fehlkonstruktionen sowie mangelnde Runbooks und Rollback-Disziplin. Dieser Leitfaden liefert eine praxistaugliche Audit-Checkliste inklusive CLI-Nachweisen, die Sie für Assessment, Compliance und Remediation nutzen können.

Audit-Setup: Scope, Evidence und Bewertungssystem

Starten Sie jedes Audit mit klarer Scope-Definition und Evidence-Anforderungen. Für Enterprise-Umgebungen ist ein standardisiertes Evidence-Paket wichtig, damit Findings vergleichbar sind und Remediation-Wellen planbar werden.

  • Scope: Geräte/Standorte, IOS/IOS XE, WAN/VPN/Routing/NAT/QoS, Management
  • Evidence: Config-Export (sanitized), CLI-Snapshots, Log-Ausschnitte, Monitoring-Status
  • Bewertung: kritisch/hoch/mittel/niedrig + Impact + Empfehlung + Owner + Termin
  • Abgrenzung: Provider/Firewall/Switch/WLAN als separate Owner-Domänen

Evidence-Snapshot (Standard, Copy/Paste)

show version
show inventory
show license summary
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show ip sla statistics
show track
show policy-map interface
show ntp status
show logging | last 100
show processes cpu sorted
show processes memory sorted

Security-Audit: Managementzugriff und Identitäten (Pflichtblock)

Der häufigste Enterprise-Finding ist ein zu offener Managementzugang oder fehlende Nachvollziehbarkeit. Prüfen Sie SSH-only, MGMT-Restriktion, AAA/Accounting und den Umgang mit lokalen Accounts.

  • SSH-only (SSHv2), Telnet deaktiviert
  • VTY per Access-Class auf MGMT-Netz begrenzt
  • HTTP/HTTPS-Server deaktiviert (wenn nicht benötigt)
  • AAA/TACACS+ (oder RADIUS) inkl. Accounting, lokaler Fallback
  • Keine Shared Accounts, Break-Glass-Prozess dokumentiert

CLI-Checks Management/AAA

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

Security-Audit: Angriffsfläche und Basis-Hardening

Enterprise-Standards verlangen eine reduzierte Angriffsfläche. Typische Findings sind unnötige Services, Discovery auf WAN oder fehlende Schutzmechanismen gegen einfache Angriffe.

  • Unnötige Services deaktiviert (mindestens Web-Server, Discovery auf WAN)
  • Management nur über definierte Pfade (MGMT-VLAN, ggf. OOB)
  • Konfig-Standards: Naming, Descriptions, klare Objektbenennung

CLI-Checks Hardening

show running-config | include no ip domain-lookup|cdp|service timestamps
show interfaces description

Security-Audit: Segmentierung und Mindest-Policies (Guest/IoT/MGMT)

In Enterprise-Umgebungen sind Segmentierung und Policies zentral. Das Audit prüft, ob Rollen-VLANs existieren, ob Policies korrekt angewendet sind und ob die Policy-Matrix eingehalten wird.

  • Segmentrollen dokumentiert (Users/Guest/IoT/MGMT/Voice)
  • Guest: interne RFC1918-Netze blockiert, nur Internet erlaubt
  • IoT/POS: Whitelist zu notwendigen Zielen/Ports, interne Netze blockiert
  • MGMT: Zugriff nur aus MGMT-Netz, kein Zugriff aus Users/Guest
  • Policy-Matrix vorhanden und aktuell (Owner, Logging-Bedarf)

CLI-Checks Policies

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

Security-Audit: NAT und VPN (No-NAT, Selektoren, Krypto-Standards)

NAT/VPN ist ein typischer Finding-Bereich: zu breite NAT-ACLs, fehlendes No-NAT, unsaubere Selektoren, instabile Rekey/DPD. Prüfen Sie auch, ob VPN „traffic-fähig“ ist.

  • NAT-Ownership klar (Router vs. Firewall)
  • NAT-Whitelist, keine ungewollten Quellnetze
  • No-NAT für VPN-Netze (Pflicht bei Site-to-Site)
  • IKEv2/IPsec-Standards: Cipher/Hash/DH/PFS, Rekey/DPD
  • VPN-Nachweis: SAs stabil + Paketzähler steigen

CLI-Checks NAT/VPN

show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

Security-Audit: Routing-Policy (Filterpflicht, Leaks, Default-Strategie)

Unkontrolliertes Routing ist im Enterprise ein kritisches Risiko. Prüfen Sie bei BGP Filterpflicht und max-prefix, bei OSPF Area-Design und passive-interfaces. Default-Handling muss klar sein.

  • BGP: Prefix-Lists/Route-Maps, max-prefix, keine ungewollten Präfixe
  • OSPF: Area-Design, passive-interface, stabile Nachbarn
  • Default-Handling: Primary/Backup klar, Tracking bei Path-Down (wenn relevant)

CLI-Checks Routing

show ip route 0.0.0.0
show ip route summary
show ip protocols
show ip ospf neighbor
show bgp summary

Performance-Audit: Interface-Health (Errors, Drops, Flaps)

Performance-Probleme entstehen häufig auf Layer 1/2: CRC, Input Errors, Output Drops. Ein Audit sollte Trendindikatoren aufnehmen, nicht nur Momentaufnahmen.

  • Keine steigenden CRC/Input Errors auf WAN/LAN-Uplinks
  • Keine ungewöhnlichen Output Drops/Queue Drops
  • Keine Interface-Flaps (oder sauber begründet)

CLI-Checks Interfaces

show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show logging | include LINEPROTO|LINK-

Performance-Audit: CPU/Memory Headroom (Trend- und Peakfähigkeit)

Ein Router kann stabil wirken, aber im Peak an die Grenzen kommen (Crypto/NAT/QoS). Prüfen Sie Headroom und Top-Prozesse, um spätere Engpässe zu vermeiden.

  • CPU keine Dauerlast, Top-Prozesse plausibel
  • CPU-Spikes korrelieren mit Events (VPN-Rekey, Routing-Flaps)
  • Memory ausreichend frei, keine auffälligen Trends/Leaks

CLI-Checks Ressourcen

show processes cpu sorted
show processes cpu history
show processes memory sorted
show logging | include CPUHOG

Performance-Audit: Path-Qualität (RTT/Loss) und SLA-Fähigkeit

Für Enterprise zählt Servicequalität: RTT/Loss zu definierten Targets, nicht nur „Internet geht“. Wenn IP SLA/Tracking genutzt wird, ist das gleichzeitig KPI- und Failover-Evidence.

  • RTT/Loss Baseline zu Internet und Hub/Zentrale
  • Degradation-Events definiert (Schwellenwerte, Dauer)
  • Path-Down Erkennung (IP SLA) vorhanden bei kritischen Standorten

CLI-Checks Path/KPI

show ip sla statistics
show track
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1

Performance-Audit: QoS (wenn aktiviert) – Wirksamkeit statt Konfigumfang

QoS ist nur dann „gut“, wenn es messbar hilft. Auditieren Sie daher Policy-Zähler, Shaping und Drops in Prioritätsklassen. Ein großes QoS-Design ohne Nachweis ist ein Finding.

  • Shaping aktiv am WAN-Egress (Queueing im Router)
  • Klassen sehen Traffic (Zähler steigen)
  • Keine auffälligen Drops in Prioritätsklassen (Voice/Video)

CLI-Checks QoS

show policy-map interface

Operational Readiness: Auditfähigkeit (NTP, Syslog, Retention)

Operational Readiness beginnt mit korrekter Zeit und zentralen Logs. Ohne NTP/Syslog ist Incident-Korrelation kaum möglich und Audits werden schwierig. Retention muss als Policy definiert sein.

  • NTP synchronized, Zeitzone/DST korrekt
  • Syslog zentral, Log-Level definiert, Source-Interface gesetzt
  • AAA/Accounting: Admin-Aktionen nachvollziehbar
  • Retention: gestaffelt je Logtyp (Admin/Change/Events)

CLI-Checks Audit-Logging

show ntp status
show running-config | include service timestamps|ntp server|logging host|logging trap|aaa accounting
show logging | last 50

Operational Readiness: Runbooks, Pre-/Post-Checks und Change-Disziplin

Ein Enterprise-Router ist nur dann betriebsbereit, wenn Standardchecks existieren und Changes kontrolliert ablaufen. Das Audit prüft, ob Runbooks vorhanden sind und ob Abnahmen dokumentiert werden.

  • Runbook: First-Level Triage (WAN/VPN/Routing/NAT) vorhanden
  • Pre-/Post-Checks als Standardprozess (Outputs gespeichert)
  • UAT definiert (Use-Cases) und wiederholbar
  • Change-Typen: Standard/Normal/Emergency inkl. Rollback

CLI-Runbook-Basis (Copy/Paste)

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip nat statistics
show crypto ikev2 sa
show crypto ipsec sa
show ip sla statistics
show logging | last 100
show processes cpu sorted

Operational Readiness: Backup, Restore und Notfallzugang

Rollback-Fähigkeit ist ein Audit-Kernpunkt, weil sie Downtime-Risiko senkt. Prüfen Sie, ob Backups versioniert sind, ob ein Notfallzugang existiert und ob Boot/Images dokumentiert sind.

  • Backups: pre/post running/startup, versioniert mit Change-ID
  • Rollback-Plan: Trigger, Soft/Hard, Validierungschecks
  • Notfallzugang: OOB/Console oder Remote-Hands (Status)
  • Image/Boot: Rollback-Image verfügbar (bei Upgrade-Projekten)

CLI-Checks Backup/Boot

show startup-config
show running-config
show boot
dir flash:

Findings-Struktur: So werden Audit-Ergebnisse umsetzbar

Damit Remediation planbar ist, sollten Findings in einem Register dokumentiert werden: ID, Kategorie, Risiko, Evidence, Empfehlung, Owner, Zieltermin. Das verhindert „Audit-Berichte ohne Umsetzung“.

  • ID und Kategorie (Security/Performance/Operability)
  • Risiko/Impact (Downtime/Security/Compliance)
  • Evidence (CLI/Logs/Monitoring) und Reproduzierbarkeit
  • Empfehlung: konkrete Maßnahme + Abhängigkeiten
  • Owner, Termin, Validierungscheck nach Fix

Remediation-Wellen: Quick Wins bis strukturelle Verbesserungen

Enterprise-Audits liefern oft viele Findings. Planen Sie Remediation in Wellen: zuerst Quick Wins, dann Standardisierung, dann komplexe Architekturthemen. Das reduziert Risiko schnell.

  • Quick Wins: SSH/MGMT, NTP/Syslog, Guest-Isolation, Template-Naming
  • Welle 1: NAT-Whitelist/No-NAT, VPN-Stabilität, Routing-Filterpflicht
  • Welle 2: Dual-WAN/Tracking, QoS-Validierung, KPI-Reporting
  • Welle 3: Automatisierung, Drift-Control, Governance-Reifegrad

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.

Related Articles