Golden Config & Compliance: Drift Detection für Cisco Router im Betrieb

„Golden Config“ bedeutet: Es gibt eine definierte, geprüfte Soll-Konfiguration (Baseline), die Security- und Betriebsstandards abbildet. „Drift“ entsteht, wenn Geräte im Alltag davon abweichen – durch Hotfixes, manuelle Änderungen, Notfall-Workarounds oder unkontrollierte Templates. Drift Detection ist deshalb ein Compliance- und Betriebswerkzeug: Du erkennst Abweichungen früh, kannst sie bewerten (erlaubt vs. kritisch) und automatisiert wieder auf Standard bringen oder zumindest dokumentieren.

Was ist eine Golden Config – und was ist sie nicht?

Eine Golden Config ist kein „einziger Config-Blob für alle Router“. Sie ist ein Standard-Set an Bausteinen (Hardening, Telemetrie, Logging, AAA), ergänzt um definierte Variablen (Hostname, IPs, Peers). Entscheidend ist: Der Sollzustand ist versioniert und freigegeben.

• Baseline-Module: Management-Hardening, CoPP, Syslog, SNMPv3, NTP
• Variablen: Standort-IP-Plan, Interface-IPs, BGP-Neighbors, WAN-Parameter
• Versionierung: Git/Repo als „Source of Truth“
• Freigabeprozess: Change-Review statt „Copy/Paste“

Warum Drift in Enterprise-Netzen unvermeidbar ist

Drift ist nicht immer „Fehler“, sondern oft Ergebnis von Betrieb: schnelle Fixes, Provider-Sonderfälle oder temporäre Workarounds. Das Problem ist fehlende Transparenz: Ohne Drift Detection merkst du Abweichungen erst beim Incident oder Audit.

• Manuelle Änderungen in Wartungsfenstern
• Notfall-Workarounds ohne späteres Cleanup
• Unterschiedliche Templates/Versionen im Feld
• „Silent Changes“ durch Reload/Upgrade/Default-Verhalten

Drift Detection: Zielbild und Messmethode

Drift Detection vergleicht Ist-Konfigurationen mit dem Sollzustand. In der Praxis brauchst du eine klare Normalisierung: manche Zeilen sind dynamisch (Counters, Timestamps, Zertifikate) und dürfen nicht als Drift zählen.

• Ist-Zustand: regelmäßiger Pull von show running-config (oder Startup)
• Soll-Zustand: Golden Config (templated + Variablen)
• Diff: normalisiert (Whitespace, Reihenfolge, dynamische Sektionen)
• Bewertung: „allowed drift“ vs. „policy violation“

Merker

$\text{Drift}=\text{Ist}–\text{Soll}$

Compliance-Checks: Was typischerweise geprüft wird

Ein guter Compliance-Katalog konzentriert sich auf wenige, hochwirksame Standards. Damit bleibt die Alarmrate beherrschbar und Findings sind umsetzbar.

• Management: SSHv2, Telnet aus, VTY ACL, AAA aktiv, Timeouts
• Secrets: enable secret, lokale Break-Glass-User, keine Default-Communities
• Services: no ip http server, CDP auf untrusted Ports aus
• Observability: Syslog zentral, SNMPv3, NTP aktiv
• Control Plane: CoPP aktiv (mindestens Baseline)

Beispiel: „Soll“-Snippets als Compliance-Regeln

ip ssh version 2
no ip http server
no ip http secure-server
service timestamps log datetime msec localtime
logging host {{SYSLOG1}}
snmp-server group NMS v3 priv
control-plane
 service-policy input PM_COPP

Ist-Konfigurationen einsammeln: Pull statt Push

Im Betrieb ist ein Pull-Modell üblich: Ein zentrales System verbindet sich per SSH, sammelt Running/Startup-Config, legt sie versioniert ab und erstellt Diffs. So werden Geräte nicht „von außen“ verändert, nur beobachtet.

• SSH Read-Only Zugriff (AAA/RBAC, falls verfügbar)
• Regelmäßige Abfrage (z. B. alle 4–24 Stunden)
• Speicherung pro Gerät + Zeitstempel (Repo/Storage)

Router-seitige Mindestbasis für Pull

ip ssh version 2
line vty 0 15
 transport input ssh
 login local

Drift sichtbar machen: Diffs, Reports und Schweregrade

Ein Diff allein ist nicht genug. Du brauchst eine Einordnung: Welche Abweichung ist kritisch (Security), welche ist informativ (Standortparameter), und welche ist erlaubt (temporäre Ausnahme)?

• Kritisch: Telnet aktiv, SNMPv2c ohne ACL, VTY offen, CoPP fehlt
• Hoch: Syslog/NTP fehlt, AAA deaktiviert, HTTP server aktiv
• Info: Description fehlt, Banner geändert, Interface-Reihenfolge
• Allowed: dokumentierte Ausnahme (Waiver) mit Ablaufdatum

Drift vermeiden: Guardrails direkt auf Cisco IOS

Neben externer Drift Detection kannst du auf Router-Seite Guardrails setzen, die unbeabsichtigte Änderungen reduzieren. Das ersetzt kein zentrales System, hilft aber gegen „Config Drift durch Alltag“.

• Lokale Konfig-Versionierung per archive
• AAA Accounting (wer hat wann was geändert?)
• Syslog/Traps für Config-Events (plattformabhängig)

Archive: lokale Versionierung aktivieren

archive
 path flash:cfg-archive
 maximum 10
 write-memory

AAA Accounting (Prinzip)

aaa new-model
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

Remediation: Was tun, wenn Drift gefunden wurde?

Drift Detection ist nur dann wertvoll, wenn du einen Prozess für Remediation hast. In der Praxis gibt es drei Wege: akzeptieren (Waiver), korrigieren (Reapply Baseline) oder redesignen (Baseline anpassen).

• Waiver: begründet, zeitlich begrenzt, dokumentiert
• Reapply: Baseline-Modul erneut ausrollen (Automation)
• Update Golden Config: wenn Drift „neuer Standard“ werden soll

Best Practices für ein robustes Golden-Config-Programm

Technik ist nur die halbe Miete. Der Erfolg hängt von klaren Rollen, Versionierung und einem leichten Review-Prozess ab, damit Teams nicht „am Standard vorbei“ arbeiten.

• Golden Config im Git-Repo als Source of Truth
• Pull-basierte Diffs (täglich), Alerts nur bei kritischer Drift
• Modulare Baselines pro Rolle (Branch/Edge/DC)
• Ausnahmen mit Ablaufdatum (keine „ewigen“ Sonderfälle)
• Post-Change Checks automatisieren (Routing, VPN, QoS, Logs)

Verifikation: Router-seitige Checks für Baseline-Compliance

Diese Kommandos helfen dir, Baseline-Bausteine schnell zu prüfen – ideal für Audits oder Spot-Checks.

show running-config | include ip ssh version|transport input|access-class
show running-config | include no ip http|logging host|snmp-server|ntp server
show running-config | section control-plane
show archive
show logging | last 50

Konfiguration speichern

Router# copy running-config startup-config

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.