Secure Logging: Syslog TLS, Time Sync, Log Integrity (Praxisansatz)

Logs sind im Netzwerkbetrieb das wichtigste Beweismittel – aber nur, wenn sie vertrauenswürdig sind. Unverschlüsseltes Syslog über UDP ist leicht abhörbar, manipulierbar und kann bei Störungen „still“ ausfallen. Für einen praxisfesten Security-Ansatz brauchst du deshalb drei Säulen: Transport-Sicherheit (Syslog über TLS), verlässliche Zeitbasis (NTP/PTP mit Monitoring) und Maßnahmen für Log-Integrität (Identität, Tamper-Evidence, zentrale Retention). In der Praxis bedeutet das: Management-Pfade sauber trennen (MGMT-VRF/OOB), PKI/Trustpoints korrekt betreiben und Logging so konfigurieren, dass es im Incident nicht selbst zum Problem wird. Dieser Artikel zeigt einen umsetzbaren Secure-Logging-Blueprint für Cisco IOS/IOS XE.

Warum „Secure Logging“ mehr ist als nur TLS

TLS schützt Vertraulichkeit und Integrität auf dem Transportweg, aber nicht die Qualität der Logdaten. Ohne korrekte Zeitstempel, eindeutige Geräteidentität und saubere Retention ist das Ergebnis trotzdem nicht auditfest.

• Syslog TLS: schützt gegen Abhören und Manipulation unterwegs
• Time Sync: macht Events korrelierbar (RCA, SIEM, Forensik)
• Integrity: reduziert Tampering-Risiko und verbessert Beweiswert

Merker

$\text{Trustworthy Logs}=\text{Secure Transport}+\text{Accurate Time}+\text{Tamper Evidence}$

Architektur: Logging-Pfad über Management-Plane (nicht über Transit)

Best Practice ist, Logs über ein dediziertes Management-Netz oder eine MGMT-VRF zu senden. Dadurch bleiben Logs auch dann verfügbar, wenn das Produktionsrouting gestört ist – und du reduzierst die Angriffsfläche.

• OOB/MGMT-VRF als Standardpfad für Syslog, NTP, PKI
• Source-Interface festsetzen (Loopback oder MGMT Interface)
• iACLs/Firewall-Regeln: nur zu Log-Collector erlauben

Source-Interface (Pattern)

logging source-interface Loopback0

Syslog TLS: Konzept und Voraussetzungen

Syslog über TLS benötigt PKI: Der Router muss dem Syslog-Server vertrauen (CA/Trustpoint), und idealerweise authentifiziert sich der Router gegenüber dem Server (Client-Zertifikat) oder mindestens der Server gegenüber dem Router (Server-Zertifikat). Ohne saubere Trust-Chain wird TLS im Betrieb zur Fehlerquelle.

• Trustpoint/CA: Router muss CA-Zertifikat kennen
• DNS/Reachability: CRL/OCSP und Servername müssen erreichbar sein
• Time Sync: Zertifikatsvalidität hängt an korrekter Uhrzeit

PKI Trustpoint (Pattern)

crypto pki trustpoint TP-LOG-CA
 enrollment url http://pki.example.local/scep
 revocation-check crl
crypto pki authenticate TP-LOG-CA

Syslog TLS konfigurieren: Praxispattern

Die exakten Befehle können je nach IOS/IOS XE Version variieren. Das robuste Muster ist: TLS aktivieren, TLS-Trustpoint referenzieren, Syslog-Server als Ziel definieren und ein sinnvolles Severity-Level setzen. Zusätzlich solltest du Buffering lokal aktivieren, damit du bei Collector-Ausfall nicht „blind“ bist.

Lokales Buffering (Pattern)

logging buffered 16384 informational
service timestamps log datetime msec localtime show-timezone

Remote Logging (Pattern)

logging host 10.99.20.10 transport tcp port 6514
logging trap informational

TLS-Absicherung (konzeptionelles Pattern)

logging tls trustpoint TP-LOG-CA
logging tls enable

Fallback-Design: Kein „Silent Failure“ bei Collector-Ausfall

Secure Logging soll im Incident helfen, nicht stören. Ein häufiger Fehler ist, dass TLS- oder TCP-Syslog bei Problemen „still“ ausfällt. Deshalb brauchst du eine Fallback-Strategie: lokaler Buffer, optional zweiter Collector, und Monitoring auf Log-Delivery.

• Local buffer als Pflicht (RCA bei Collector-Problemen)
• Zwei Syslog Collector (Primary/Secondary)
• Alarmierung: „Device stoppt Logs zu senden“

Zweiter Collector (Pattern)

logging host 10.99.20.11 transport tcp port 6514

Time Sync: NTP als Mindeststandard, Monitoring als Pflicht

Ohne korrekte Zeit sind Logs kaum korrelierbar. Für auditfeste Logs brauchst du stabile NTP-Server, Redundanz und Monitoring auf Drift/Stratum. In kritischen Umgebungen kann PTP relevant sein, für Router-Logging ist NTP jedoch meist der Standard.

• Mindestens zwei NTP-Server (redundant)
• NTP über Management-Pfad, nicht über Internet-DNS-Abhängigkeiten
• Drift-Monitoring: Zeitabweichung ist ein Security-Signal

NTP Baseline (Pattern)

ntp server 10.99.0.10 prefer
ntp server 10.99.0.11
clock timezone CET 1 0

NTP Verifikation

show clock
show ntp status
show ntp associations

Log Integrity: Tamper-Evidence und Identität

Log-Integrität bedeutet in der Praxis: (1) eindeutige Identität im Log (Hostname, Device-ID), (2) manipulationssichere Transport- und Speicherkette (TLS + zentraler Collector), und (3) Retention/Write-Once-Mechanismen auf der Server-Seite. Auf dem Router selbst ist die Integrität begrenzt – deshalb ist zentrale Speicherung entscheidend.

• Hostname/Domain konsistent (keine „Router1“ überall)
• Sequenznummern/Monotonic Counters, wo verfügbar
• Zentraler Collector mit Append-only/immutable Storage (serverseitig)

Identität/Facility (Pattern)

hostname R1-BERLIN-EDGE
logging facility local6

Log-Qualität: Was du loggen solltest (und was nicht)

Mehr Logging ist nicht automatisch besser. Zu viel kann CPU belasten und Log-Systeme fluten. Best Practice ist: Security-relevante Events hoch priorisieren (AAA, Config Changes, Interface Flaps, Routing Events), und Noise reduzieren.

• Wichtig: AAA Logins, Command Accounting, Config Changes
• Wichtig: Interface Up/Down, BGP/OSPF Neighbor Changes
• Wichtig: VPN Rekeys/DPD Flaps (wenn relevant)
• Noise reduzieren: Debugs, Chatty Facilities begrenzen

Config-Change Logging (Pattern)

archive
 log config
  logging enable
  notify syslog

Hardening rund um Logging: iACLs und CoPP berücksichtigen

Syslog TLS läuft häufig über TCP/6514 und kann bei strengen iACLs oder CoPP-Policies unerwartet geblockt werden. Ein robustes Design erlaubt Logging nur zu den Collector-IPs und lässt genügend Burst zu, damit Konvergenz-Events nicht „ausbluten“.

• iACL: allow Router → Collector TCP/6514 (sonst Drops)
• CoPP: Logging-/Management-Traffic nicht in class-default verhungern lassen
• QoS: optional Priorisierung für Management/Logging im Underlay

Troubleshooting: TLS, Zertifikate und „keine Logs kommen an“

Wenn Logs über TLS nicht ankommen, sind die Ursachen meist deterministisch: Zeit falsch, CA/Chain fehlt, CRL/OCSP unreachable, TCP/6514 geblockt, oder falsches Source-Interface/VRF. Debugge zuerst Reachability, dann PKI, dann Logging-Status.

Connectivity Checks

ping 10.99.20.10 source Loopback0
telnet 10.99.20.10 6514

PKI Checks

show clock
show crypto pki trustpoints
show crypto pki certificates
show crypto pki crls

Logging Checks

show logging
show running-config | include logging
show logging | include %SYS|%SEC|%AAA

Operational Best Practices: Secure Logging als Standardprodukt

Secure Logging ist dann robust, wenn es standardisiert ist: gleiche Facility, gleiche Severity, definierte Quellen, PKI-Runbooks und Monitoring. Damit werden Logs im Incident verlässlich und auditierbar.

• Standard: local6, informational (oder policybasiert)
• Dual Collector, lokaler Buffer, zentrale Retention
• NTP redundant, Drift überwachen
• PKI Prozesse: Renewal, CRL/OCSP Verfügbarkeit

Quick-Runbook: Secure Logging verifizieren

Diese Checkliste zeigt in Minuten, ob Zeit, PKI und Remote Logging konsistent sind.

show clock
show ntp status
show ntp associations
show crypto pki trustpoints
show crypto pki certificates
show logging
show run | include logging|service timestamps|archive

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.