Evidence Pack für Audits: Screenshot-/Log-/Config-Evidenzen aus Cisco-Routern

Ein Evidence Pack für Audits aus Cisco-Routern ist eine strukturierte Sammlung von Konfigurationsauszügen, Logs und Nachweisen (Screenshots/Exports), die technische Kontrollen belegt: Zugriffssicherheit (SSH/AAA/RBAC), Audit Trail (Accounting), Zeitsynchronisation (NTP), zentrale Protokollierung (Syslog), Segmentierung/Policies (ACL/VRF), sowie Betriebsfähigkeit (Monitoring, Backups, Change-Nachweise). Der häufigste Audit-Fail ist nicht „fehlende Sicherheit“, sondern fehlende Nachvollziehbarkeit: keine Zeitbasis, keine eindeutige Zuordnung zu Geräten/Standorten, keine Versionierung oder unvollständige Evidence. Dieser Leitfaden liefert ein praxistaugliches Evidence-Pack-Template inklusive Benennung, Mindestinhalt und CLI-Befehlen.

Grundprinzip: Evidence muss reproduzierbar, zeitlich korrekt und zuordenbar sein

Audits bewerten Kontrollen anhand von Nachweisen. Damit Evidence akzeptiert wird, muss sie eindeutig zeigen: welches Gerät, welcher Zeitpunkt, welcher Zustand, und wer Zugriff hatte.

• Zuordnung: Device-ID (Hostname/Serial), Standort, Rolle (Edge/Branch/DC)
• Zeit: NTP synchronized, Zeitstempel in Logs/Evidence sichtbar
• Integrität: unveränderte Exporte, Hash optional, Read-only Ablage
• Vollständigkeit: Mindestkatalog an Kontrollen abgedeckt

Ordner- und Namensstandard: So wird Evidence auditfähig

Struktur ist der Unterschied zwischen „wir haben Screenshots“ und „auditfähig“. Nutzen Sie einen einheitlichen Standard pro Gerät und Auditzeitraum.

• Ordner: YEAR-MONTH_AUDITNAME / SITEID / DEVICE
• Dateinamen: SITEID_DEVICEID_CONTROL_TIMESTAMP
• Zeitzone: konsistent (häufig UTC) oder eindeutig dokumentiert
• Format: Text/CLI-Output als .txt, Konfig als .cfg, Screenshots als .png

Beispiel Dateinamen

• 012_R-BR-012_NTP_2026-03-04T2205Z.txt
• 012_R-BR-012_AAA_ACCOUNTING_2026-03-04T2206Z.txt
• 012_R-BR-012_RUNNINGCFG_PRE_2026-03-04T2207Z.cfg
• 012_R-BR-012_SYSLOG_SAMPLE_2026-03-04T2208Z.txt

Mindestumfang: Welche Kontrollen das Evidence Pack abdecken muss

Die Inhalte hängen vom Audit ab, aber diese Basiskontrollen sind in Enterprise-Umgebungen nahezu immer relevant. Ergänzen Sie je nach Scope (VPN, Dual-ISP, VRF).

• Identität & Gerätestatus: Version, Serial, Uptime, Interface-Status
• Adminzugriff: SSH-only, MGMT-Only, AAA/RBAC, Accounting
• Zeit & Logging: NTP, Syslog zentral, Timestamps
• Policies: ACL/VRF/Segmentierung, Management-Schutz
• Backups/Change: PRE/POST Configs, Change-ID, Evidence Pack
• Optional: VPN Evidence, Resilience Tracking, Monitoring (SNMPv3)

Evidence-Kategorie 1: Geräteidentität und Softwarestand

Auditoren wollen sicherstellen, dass Evidence zum richtigen Gerät gehört. Daher gehören Identität und Softwarestand immer an den Anfang.

CLI: Device Identity (Copy/Paste)

terminal length 0
show version
show inventory
show license summary
show boot
show clock

Evidence-Kategorie 2: Adminzugriffssicherheit (SSH, MGMT-Only, Session Hygiene)

Hier wird überprüft, ob Remote-Administration sicher ist und ob nur autorisierte Netze/Personen Zugriff haben. Shared Accounts sind ein häufiger Audit-Find.

CLI: SSH & VTY Controls

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

Evidence-Kategorie 3: AAA/RBAC und Accounting (Audit Trail)

Accounting ist der Schlüssel für „wer hat was getan“. Wenn AAA genutzt wird, muss Evidence zeigen, dass Authentication/Authorization/Accounting konfiguriert und aktiv ist.

CLI: AAA Evidence

show running-config | include aaa
show running-config | include tacacs|radius
show running-config | include accounting

Evidence-Kategorie 4: Zeitsynchronisation (NTP) und korrelierbare Logs

Ohne NTP sind Logs für Audits kaum verwertbar. Evidence muss NTP-Status und die konfigurierten Zeitquellen zeigen.

CLI: NTP Evidence

show clock
show ntp status
show ntp associations
show running-config | include ntp server

Evidence-Kategorie 5: Syslog-Konfiguration und Log-Samples

Audits erwarten häufig den Nachweis, dass Logs nicht nur „lokal“ existieren, sondern zentral abgelegt werden. Liefern Sie die Konfiguration plus Log-Beispiele mit Zeitstempeln.

CLI: Syslog Config Evidence

show running-config | include service timestamps log|logging host|logging trap|logging source-interface
show logging | last 100

Screenshot-/Export-Evidence (Beispiel)

• Screenshot aus SIEM/Collector: Empfang eines Router-Logevents inkl. Timestamp und Device-ID
• Screenshot der Retention-Policy oder Index-Lifetime (wenn vom Audit gefordert)

Evidence-Kategorie 6: Segmentierung und Policies (ACL/VRF)

Hier wird belegt, dass Netzwerksegmentierung umgesetzt und Managementnetze geschützt sind. Wichtig: ACLs nicht nur als Konfig, sondern auch angewendet (Interface-Bindings).

CLI: ACL/Policy Evidence

show access-lists
show running-config | include ip access-list|access-group
show ip interface | include access list

CLI: VRF Evidence (wenn Scope)

show vrf
show ip route vrf VRF-IT
show ip route vrf VRF-OT

Evidence-Kategorie 7: Monitoring (SNMPv3/Telemetry) als Betriebsnachweis

Viele Audits prüfen, ob betriebliche Kontrollen existieren. Monitoring-Evidence zeigt, dass das Gerät beobachtbar ist und dass Accounts sicher sind (SNMPv3 statt v2c).

CLI: SNMPv3 Evidence

show snmp user
show running-config | include snmp-server

Evidence-Kategorie 8: Resilience und Failover (Dual-ISP/Tracking), falls relevant

Wenn Verfügbarkeit Teil der Kontrollen ist, müssen Tracking und Failover-Mechanismen nachweisbar sein. Ergänzen Sie Log-Events (Track down/up).

CLI: Tracking Evidence

show ip sla statistics
show track
show ip route 0.0.0.0
show logging | include TRACK|IP_SLA

Evidence-Kategorie 9: VPN Evidence (falls im Scope)

VPN ist auditrelevant, wenn es Remote Access oder Site-to-Site trägt. Evidence soll nicht nur SAs zeigen, sondern auch Stabilität und Traffic-Zähler.

CLI: VPN Evidence

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

Evidence-Kategorie 10: Konfig-Backups, Versionierung und Change-Nachweis

Audits verlangen oft Nachweis über kontrollierte Changes. Liefern Sie PRE/POST Configs und referenzieren Sie Change-IDs. Wichtig ist, dass Backups aus einem definierten Prozess stammen.

CLI: Config Backup Evidence

show running-config
show startup-config

Screenshot-/Dokument-Evidence (Beispiel)

• Change-Ticket: Change-ID, freigegebenes Window, Rollback-Plan
• Peer-Review Nachweis (z. B. Pull Request/Review-Protokoll, falls vorhanden)
• Abnahmeprotokoll: UAT/ATP Pass/Fail + Evidence Links

Evidence Collection SOP: Schrittfolge zur Erstellung des Packs

Eine SOP macht Evidence reproduzierbar. Sie minimiert Fehler, wie fehlende Zeitstempel oder das falsche Gerät.

• Schritt 1: NTP prüfen (show clock, show ntp status)
• Schritt 2: Device Identity exportieren (show version, show inventory)
• Schritt 3: Management/AAA/Logging exportieren
• Schritt 4: Policies/VRFs exportieren (falls relevant)
• Schritt 5: Optionalmodule (VPN, Tracking, SNMPv3) exportieren
• Schritt 6: SIEM/Collector Screenshots erstellen (Log-Empfang)
• Schritt 7: Dateien benennen, ablegen, Read-only setzen

Standard Evidence Pack: Copy/Paste CLI-Bundle

Dieses Bundle deckt die häufigsten Auditkontrollen ab und kann pro Gerät ausgeführt und als Textdatei gespeichert werden. Ergänzen Sie VRF/VPN/Tracking je Scope.

terminal length 0
show clock
show version
show inventory
show license summary
show boot
show ip interface brief
show interfaces counters errors
show ip route summary
show ip route 0.0.0.0
show ip ssh
show running-config | include line vty|transport input|access-class|exec-timeout
show running-config | include aaa|tacacs|radius|accounting
show ntp status
show ntp associations
show running-config | include ntp server
show running-config | include service timestamps log|logging host|logging trap|logging source-interface
show logging | last 100
show access-lists
show running-config | include ip access-list|access-group
show snmp user
show running-config | include snmp-server
show processes cpu sorted
show processes memory sorted

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.