Audit-fähiges Logging auf Cisco-Routern besteht aus drei Säulen: korrekte Zeit (NTP), vollständige und zentrale Ereigniserfassung (Syslog/AAA-Accounting) sowie eine definierte Retention, die Ermittlungen und Compliance-Anforderungen abdeckt. In der Praxis scheitern Audits selten an „fehlenden Tools“, sondern an fehlender Konsistenz: unterschiedliche Log-Level, fehlende Zeitstempel, unklare Aufbewahrungsfristen oder Logs, die im Incident nicht auffindbar sind. Dieser Leitfaden zeigt ein praxistaugliches Logging- und Retention-Setup inklusive Mindest-Events, Beispielkonfiguration und Betriebsvorgehen.
Audit-Ziele: Was Logs im Prüfungsfall leisten müssen
Für Audits zählen nicht „viele Logs“, sondern nachvollziehbare Ereignisse: wer hat administriert, was hat sich geändert, wann ist etwas ausgefallen, und können Sie das zeitlich sauber korrelieren. Retention ist dabei Teil der Beweiskette.
- Nachvollziehbarkeit: Admin-Logins, Commands (wenn möglich), Sessions
- Integrität: Zeitstempel korrekt, zentrale Speicherung, Zugriffskontrollen
- Verfügbarkeit: Logs sind auffindbar (Index/Suche) und nicht nur lokal
- Retention: definierte Aufbewahrung (kurz/mittel/lang) je Logtyp
Mindest-Logging-Baustein 1: Zeit und Zeitzone (NTP ist Pflicht)
Ohne NTP sind Zeitstempel wertlos. Für Audits müssen Zeitzone, Sommerzeitregeln und NTP-Synchronisation korrekt sein. Nutzen Sie mindestens zwei Zeitquellen und aktivieren Sie Millisekunden-Zeitstempel.
CLI: Zeitstempel, Zeitzone und NTP
service timestamps log datetime msec
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
ntp server 192.0.2.10 prefer
ntp server 192.0.2.11
Verifikation Zeit/NTP
show clock
show ntp status
show ntp associations
Mindest-Logging-Baustein 2: Syslog zentral (lokal reicht nicht)
Lokale Logs sind begrenzt und können bei Reboots verloren gehen. Auditfähig ist nur zentrale Speicherung. Definieren Sie Log-Level, Quellinterface und eine lokale Buffer-Größe für Kurzdiagnose.
CLI: Syslog-Baseline (zentral + Buffer)
logging buffered 64000 informational
logging host 192.0.2.20
logging trap informational
logging source-interface GigabitEthernet0/1
Verifikation Syslog
show logging
show running-config | include logging
Mindest-Logging-Baustein 3: Admin-Audit (AAA und Accounting)
Für Audits ist entscheidend, dass Admin-Aktionen nachvollziehbar sind. In Unternehmensumgebungen ist AAA mit TACACS+ (oder RADIUS) der Standard. Wenn möglich, aktivieren Sie Accounting für Exec-Sessions und Commands.
- Authentication: wer darf rein?
- Authorization: was darf der Nutzer?
- Accounting: wer hat wann was gemacht?
CLI: AAA + Accounting (Muster, an Umgebung anpassen)
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+
aaa accounting commands 15 default start-stop group tacacs+
Verifikation AAA (Sichtprüfung)
show running-config | include aaa|tacacs
Welche Ereignisse sind auditrelevant? (Mindest-Event-Katalog)
Definieren Sie einen Mindestkatalog, damit Log-Noise nicht die wichtigen Events verdrängt. In Audits werden typischerweise Admin-Events, Netzstabilität und Security-Relevanz geprüft.
- Admin: Login success/failure, AAA-Ausfälle, Privilege-/Role-Events
- Config: Konfigänderungen und Save/Reload-Ereignisse
- Netz: Interface up/down, Link flaps, Routing-Neighbor up/down
- Security: ACL-Drops (selektiv), Scan-/Brute-Force-Indikatoren
- VPN: IKE/IPsec up/down, Rekey/DPD-Fehler (wenn VPN genutzt wird)
- System: CPU hog, Memory-Pressure, Hardware-/Module-Events
Log-Level und Noise-Control: Weniger ist oft auditfähiger
Zu viele Logs führen dazu, dass niemand sie auswertet. Ein stabiler Standard ist ein moderater Log-Level (oft informational) plus gezielte Ergänzungen für Security/AAA. Wichtig: Änderungen am Log-Level sind Change-pflichtig.
- Default: informational für zentrale Syslog-Weiterleitung
- Lokaler Buffer: ebenfalls informational, begrenzte Größe
- Gezielt: Security-/AAA-Events priorisieren, nicht „alles debug“
- Regel: Debug nur zeitlich begrenzt und dokumentiert
Retention-Design: Aufbewahrung nach Logtyp (praxisnah)
Retention ist nicht „eine Zahl für alles“. Sinnvoll ist ein Stufenmodell: kurze Retention für High-Volume-Events, längere Retention für Admin- und Audit-Logs. Die Werte hängen von Vorgaben ab, sollten aber im Betrieb realistisch sein.
- Admin/AAA-Accounting: langfristig (z. B. 6–24 Monate)
- Config-/Change-Events: mittelfristig (z. B. 3–12 Monate)
- System/Interface/Routing Events: kurz bis mittel (z. B. 30–180 Tage)
- Debug/Verbose Logs: sehr kurz (z. B. 1–7 Tage, nur bei Bedarf)
Kapazitätsorientierung (warum Retention gestaffelt sein muss)
Wenn ein Standort täglich viele Interface-/Routing-Events produziert, skaliert Speichervolumen schnell. Gestaffelte Retention reduziert das Volumen, ohne Audit-Fähigkeit zu verlieren.
Integrität und Zugriff: Wer darf Logs sehen und ändern?
Für Audits ist nicht nur das Log selbst wichtig, sondern die Integrität: Logs dürfen nicht beliebig löschbar sein, und Zugriff muss protokolliert und rollenbasiert sein. Das betrifft vor allem den Syslog-/SIEM-Server.
- Write-Once oder manipulationssichere Speicherung (SIEM/Logserver)
- Rollenbasierter Zugriff (Viewer vs. Admin)
- Audit-Trail auch auf dem Logsystem (wer sucht/exportiert)
- Backup der Logdaten (Retention darf nicht durch Systemausfall enden)
Betrieb: Audit-Runbook für schnelle Nachweise
Im Audit müssen Sie häufig belegen, dass Zeit stimmt, Logs zentral ankommen und Admin-Aktionen erfasst werden. Ein kurzes Runbook beschleunigt diese Nachweise deutlich.
Router-Checks für Audit-Nachweis (Copy/Paste)
show clock
show ntp status
show running-config | include service timestamps|clock timezone|clock summer-time|ntp server
show running-config | include logging host|logging trap|logging source-interface|logging buffered
show logging | last 50
show running-config | include aaa|tacacs|radius
Typische Audit-Fails (und wie Sie sie verhindern)
Diese Punkte führen besonders häufig zu Findings: fehlende Zeitsynchronisation, lokale Logs ohne zentrale Ablage, fehlendes Accounting und unklare Retention. Ein fester Standard verhindert das.
- NTP unsynchronized: Zeitstempel unzuverlässig, Events nicht korrelierbar
- Nur lokale Logs: bei Reboot weg, keine zentrale Suche
- Shared Accounts: keine Zuordnung von Admin-Aktionen
- Kein Accounting: „wer hat was geändert“ nicht nachweisbar
- Keine Retention-Policy: Aufbewahrung zufällig/zu kurz
Minimaler Golden-Config-Block: Audit-Logging (kompakt)
Dieser Block bündelt die wichtigsten auditrelevanten Logging-Elemente. Platzhalter sind zu ersetzen; Secrets werden nicht im Klartext dokumentiert.
! ===== AUDIT LOGGING BASELINE =====
service timestamps log datetime msec
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
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
logging source-interface GigabitEthernet0/1
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+
aaa accounting commands 15 default start-stop group tacacs+
! ===== END AUDIT LOGGING 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.












