Syslog einrichten: Cisco Logs zentral sammeln und auswerten

Syslog ist der Standard, um Cisco Router-Logs zentral zu sammeln, zu korrelieren und auszuwerten. Statt lokal im Ringbuffer zu verschwinden, landen Meldungen (z. B. Interface down, VPN-Fehler, Login-Versuche) auf einem Logserver oder SIEM. Damit du Logs zuverlässig und sicher betreibst, brauchst du drei Dinge: korrekte Zeit (NTP), sinnvolle Severity-Level/Filter und eine saubere Transport-/Quellenkonfiguration (z. B. Source-Interface, Management-VLAN, optional ACL). Diese Anleitung zeigt eine praxistaugliche Cisco-IOS-Konfiguration.

Warum zentrale Logs im Betrieb unverzichtbar sind

Lokale Router-Logs sind begrenzt (Speicher, Reboots) und für Ursachenanalyse oft zu kurzlebig. Zentrale Syslog-Sammlung ermöglicht Trendanalyse, Security-Alerting und saubere Incident-Timelines.

• Forensik: Logs bleiben erhalten, auch nach Neustart
• Korrelation: mehrere Geräte, ein Zeitstrahl
• Alerting: Interface-Flaps, VPN-Fails, Brute-Force
• Compliance: Nachvollziehbarkeit und Audit

Voraussetzung 1: Zeit synchronisieren (NTP)

Ohne korrekte Zeit sind Logs schwer auswertbar. NTP sorgt dafür, dass Zeitstempel über alle Geräte hinweg konsistent sind. Best Practice: NTP-Server im Management-Netz, optional Source-Interface.

NTP konfigurieren (Beispiel)

Router# configure terminal
Router(config)# ntp server 192.168.10.10 prefer
Router(config)# ntp source loopback0
Router(config)# end

NTP-Status prüfen

Router# show ntp status
Router# show ntp associations

Voraussetzung 2: Sinnvolle Zeitstempel aktivieren

Aktiviere Zeitstempel mit Datum und Millisekunden, damit du Events exakt korrelieren kannst. Zusätzlich ist „localtime“ sinnvoll, wenn du in lokaler Zeitzone arbeiten möchtest.

Timestamps aktivieren

Router# configure terminal
Router(config)# service timestamps log datetime msec localtime
Router(config)# service timestamps debug datetime msec localtime
Router(config)# end

Syslog-Grundkonzept: Severity-Level und Facility

Cisco Syslog-Meldungen haben eine Severity (0–7). Je niedriger die Zahl, desto kritischer. Für den zentralen Betrieb ist es üblich, nicht „alles“ zu senden, sondern mit einem sinnvollen Level zu starten (z. B. warnings) und dann nach Bedarf zu verfeinern.

• 0–2: emergencies/alerts/critical (sehr selten, sehr wichtig)
• 3: errors
• 4: warnings (guter Startpunkt für Betrieb)
• 5: notifications (mehr Noise, aber oft nützlich)
• 6–7: informational/debugging (sehr chatty)

Merker

$\text{Kleine Zahl} \to \text{hohe Kritikalität}$

Schritt 1: Logserver definieren (logging host)

Du definierst einen oder mehrere Syslog-Server. Best Practice ist, das Source-Interface zu setzen (z. B. Loopback0), damit Logs immer von einer stabilen IP kommen und ACLs/Firewall-Regeln einfach bleiben.

Syslog-Server setzen und Source-Interface definieren

Router# configure terminal
Router(config)# logging host 192.168.10.20
Router(config)# logging source-interface loopback0
Router(config)# end

Optional: Zweiten Logserver als Redundanz

Router# configure terminal
Router(config)# logging host 192.168.10.21
Router(config)# end

Schritt 2: Severity-Level für Remote Logging festlegen

Mit logging trap bestimmst du, ab welcher Severity der Router an den Syslog-Server sendet. Ein praxistauglicher Start ist warnings. Für Security-Analysen ist notifications häufig sinnvoll, wenn Noise akzeptabel ist.

Beispiel: warnings an den Syslog-Server senden

Router# configure terminal
Router(config)# logging trap warnings
Router(config)# end

Noise reduzieren: Console Logging begrenzen

Damit Sessions nicht „zugespammt“ werden, setzt du Console auf einen höheren Level oder deaktivierst es in produktiven Umgebungen.

Router# configure terminal
Router(config)# no logging console
Router(config)# end

Schritt 3: Lokalen Buffer aktivieren (für schnelle Diagnose)

Ein lokaler Buffer ist weiterhin nützlich, um kurzfristig Dinge zu prüfen, wenn der Logserver gerade nicht erreichbar ist. Setze eine sinnvolle Buffer-Größe und Severity.

Buffered Logging aktivieren

Router# configure terminal
Router(config)# logging buffered 16384 warnings
Router(config)# end

Buffer anzeigen

Router# show logging

Schritt 4: Identität und Kontext verbessern (hostname, facility)

Für zentrale Auswertung sind eindeutige Hostnames Pflicht. Optional kannst du Facility anpassen, wenn dein SIEM/Server nach Facilities routet. Außerdem ist „sequence-numbers“ hilfreich für Event-Reihenfolgen.

Hostname und Sequence Numbers

Router# configure terminal
Router(config)# hostname R1-BRANCH
R1-BRANCH(config)# service sequence-numbers
R1-BRANCH(config)# end

Optional: Facility setzen

R1-BRANCH# configure terminal
R1-BRANCH(config)# logging facility local7
R1-BRANCH(config)# end

Schritt 5: Security-Events gezielt loggen

Für Security-Use-Cases sind bestimmte Ereignisse besonders wertvoll: Login-Failures, SSH/AAA-Events, Interface-Flaps, VPN-Fehler und ACL-Drops (gezielt). Das ist oft aussagekräftiger als „alles auf informational“.

• Login/AAA-Events (Success/Fail)
• Interface up/down und Line Protocol Changes
• VPN/IKE/IPsec Events
• ACL-Drops mit log (sparsam einsetzen)

Beispiel: ACL-Drops loggen (gezielt)

ip access-list extended OUTSIDE_IN
 permit tcp any host 203.0.113.10 eq 443
 deny ip any any log

Transport und Firewall: UDP/514 und Management-ACL

Syslog nutzt klassisch UDP/514. Stelle sicher, dass dein Router den Logserver erreichen kann und dass Firewalls/ACLs den Verkehr erlauben. Mit Source-Interface und Management-Netz ist das leicht zu kontrollieren.

Reachability prüfen

Router# ping 192.168.10.20 source loopback0
Router# traceroute 192.168.10.20 source loopback0

Verifikation: Kommen Logs an?

Prüfe auf Router-Seite den aktuellen Logging-Status und generiere testweise ein Event (z. B. Interface shutdown/no shutdown oder ein bewusstes Login-Failure). Auf dem Logserver solltest du Meldungen mit korrektem Hostname und Zeitstempel sehen.

Router-Status prüfen

Router# show logging
Router# show running-config | include logging

Test-Event erzeugen (kontrolliert)

Router# configure terminal
Router(config)# interface gigabitEthernet0/0
Router(config-if)# shutdown
Router(config-if)# no shutdown
Router(config-if)# end

Typische Fehler und schnelle Fixes

Wenn keine Logs ankommen, ist es meist ein Transport-/Routing-/Source-Problem oder eine zu restriktive Severity. Prüfe systematisch und ändere nicht mehrere Dinge gleichzeitig.

• Falsche Server-IP oder falsches Routing zum Logserver
• logging trap zu hoch (z. B. nur errors) → kaum Meldungen
• Source-IP ungeplant (kein logging source-interface) → Firewall blockt
• NTP fehlt → Zeitstempel unbrauchbar
• Console/Monitor Logging stört Sessions → no logging console

Quick-Checks (Copy & Paste)

show running-config | include logging
show logging
show ntp status
ping 192.168.10.20 source loopback0
traceroute 192.168.10.20 source loopback0

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.