Netzwerk-Protokollierungsprobleme lösen Sie in dieser Reihenfolge: prüfen Sie den Log-Dienst auf Quelle und Kollektor, testen Sie die Erreichbarkeit von UDP/TCP 514 durch Firewalls, kontrollieren Sie rsyslog- oder Event-Forwarding-Regeln, synchronisieren Sie NTP und stellen Sie sicher, dass Speicherplatz sowie Schreibrechte auf dem Log-Ziel ausreichen.
Symptome
- Auf dem zentralen Kollektor treffen keine Einträge von einem oder mehreren Geräten mehr ein.
- Zeitstempel weichen zwischen Client und Server um Minuten oder Stunden ab.
- Log-Dateien wachsen unkontrolliert und füllen die Systempartition.
- Ereignisse erscheinen doppelt, verstümmelt oder ohne Hostname.
- SIEM-Regeln lösen nicht mehr aus, obwohl die Ereignisse in lokalen Logs stehen.
Häufige Ursachen
Fehlkonfigurierte Weiterleitungsregel
In rsyslog.conf, syslog-ng oder der Windows Event Forwarding-Subscription fehlt das Ziel, die Facility-Filterung ist zu eng oder das Template ist ungültig.
Blockierter Syslog-Transport
Firewalls, Sicherheitsgruppen oder Host-basierte Regeln lassen UDP 514, TCP 514 oder TLS 6514 zwischen Sender und Kollektor nicht passieren, oft nach einem Netzsegmentwechsel.
Ausgefallener Protokollierungsdienst
rsyslog, systemd-journald, Windows EventLog oder ein Agent wie NXLog, Winlogbeat oder Fluent Bit ist gestoppt, abgestürzt oder nach einem Update im Fehlerzustand.
Zeitversatz ohne NTP
Fehlt eine funktionierende Zeitquelle, driften Clients weg. Korrelation im SIEM scheitert, und Compliance-Anforderungen an Zeitstempel werden verletzt.
Speicher- oder Rechteproblem am Ziel
Die Log-Partition ist voll, ein Rotationsjob scheitert, oder der Zieldienst darf mangels SELinux-Kontext oder NTFS-ACL nicht in das Verzeichnis schreiben.
Schritt-für-Schritt-Lösung
- Zustand der Protokollierungsdienste auf Quelle und Kollektor prüfen
Beginnen Sie am Sender. Unter Linux zeigt systemctl status rsyslog oder systemctl status syslog-ng, ob der Dienst läuft und ob journalctl -u rsyslog Fehler wirft. Unter Windows kontrollieren Sie den Dienst EventLog sowie den Windows Event Collector über services.msc. Ist ein Agent im Einsatz, prüfen Sie dessen eigenes Statuskommando. - Netzwerkpfad zum Log-Ziel verifizieren
Testen Sie vom Sender aus die Erreichbarkeit des Kollektors. Für TCP nutzen Sie nc -vz kollektor 514 oder Test-NetConnection kollektor -Port 514. UDP prüfen Sie mit logger -n kollektor -P 514 -T Test und einem parallelen tcpdump port 514 auf dem Empfänger. Kein Paket sichtbar heißt: Firewall, ACL oder Routing. - Weiterleitungs- und Filterregeln kontrollieren
Öffnen Sie /etc/rsyslog.conf sowie /etc/rsyslog.d/*.conf und prüfen Sie die Zielzeile, typischerweise im Format *.* @@kollektor:514 für TCP oder @kollektor:514 für UDP. Achten Sie auf falsche Facilities, unerwartete Stop-Regeln oder eine defekte Template-Definition. Unter Windows kontrollieren Sie die Subscription in wecutil qc und die Quellrechnerliste. - Zeit über NTP synchronisieren
Divergierende Uhren machen Logs für Korrelation und Forensik wertlos. Prüfen Sie chronyc tracking beziehungsweise w32tm /query /status. Setzen Sie eine verlässliche interne oder externe Zeitquelle, erlauben Sie UDP 123 in der Firewall und erzwingen Sie eine sofortige Synchronisation. Wiederholen Sie den Test nach fünf Minuten. - Speicherplatz, Rotation und Berechtigungen prüfen
Mit df -h finden Sie eine volle Log-Partition schnell. Kontrollieren Sie /etc/logrotate.d auf fehlerhafte Regeln und führen Sie logrotate -d /etc/logrotate.conf im Debug-Modus aus. Auf Windows-Kollektoren prüfen Sie die maximale Größe im Event Viewer und die NTFS-Rechte des Benutzers, unter dem der Dienst läuft. - TLS, Zertifikate und Authentifizierung validieren
Wird syslog über TLS oder HTTPS an ein SIEM gesendet, scheitert die Übertragung häufig an abgelaufenen oder falsch verketteten Zertifikaten. Prüfen Sie mit openssl s_client -connect kollektor:6514 die Zertifikatskette und die Ablaufdaten. Passen Sie CA-Store, Cipher und, falls nötig, den Client-Schlüssel auf dem Sender an. - Ende-zu-Ende mit einem Testereignis bestätigen
Erzeugen Sie ein eindeutiges Ereignis, etwa logger -t netcheck "probe $(date +%s)" oder eventcreate /T INFORMATION /ID 999 /L APPLICATION /D "probe". Suchen Sie auf dem Kollektor gezielt nach der Kennung. Fehlt der Eintrag, engen Sie die Ursache mit Paketmitschnitt und Debug-Logging des Log-Dienstes weiter ein. - Änderungen dokumentieren und Monitoring einrichten
Halten Sie die geänderte Konfiguration in Ihrem Change-System fest und legen Sie einen Alarm an, der bei ausbleibenden Events pro Host innerhalb eines definierten Zeitfensters warnt. Ein einfacher Heartbeat pro Quelle verhindert, dass ein stiller Ausfall erneut Wochen unbemerkt bleibt.
Typische Symptome, wahrscheinliche Ursache und erste Maßnahme
| Symptom | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| Keine Logs von einem Host | Dienst gestoppt oder Regel entfernt | systemctl status prüfen, Konfig neu laden |
| Keine Logs aus einem VLAN | Firewall blockiert 514/6514 | Portfreigabe mit nc oder Test-NetConnection prüfen |
| Zeitstempel weichen ab | NTP nicht synchron | chronyc tracking bzw. w32tm /query /status |
| Partition läuft voll | Rotation defekt oder Debug-Level zu hoch | logrotate testen, Log-Level senken |
| TLS-Übertragung bricht ab | Zertifikat abgelaufen oder Chain unvollständig | openssl s_client, CA-Store aktualisieren |
| Doppelte Einträge im SIEM | Zwei Weiterleitungspfade aktiv | Doppelte Ausgabe-Regel deaktivieren |
So beugen Sie vor
- Heartbeat-Events je Quelle senden und im SIEM auf Ausbleiben alarmieren.
- Log-Partition getrennt vom Systemvolumen anlegen und Rotation testen.
- NTP-Konfiguration in das Standard-Image aufnehmen und regelmäßig auditieren.
- Firewall-Regeln für Log-Ports als benannte Objekte pflegen, nicht als Einzelregeln.
Häufige Fragen
Warum kommen Logs sporadisch, aber nicht vollständig an?
Meist liegt UDP-Syslog vor, das bei Paketverlust oder MTU-Problemen still verwirft. Wechseln Sie auf TCP 514 oder TLS 6514, aktivieren Sie eine Queue-Konfiguration im Sender und prüfen Sie Interface-Fehlerzähler mit ethtool oder Get-NetAdapterStatistics. Auch ein überlasteter Kollektor kann Pakete verwerfen, wenn Empfangspuffer zu klein sind.
Wie finde ich heraus, ob eine Firewall Syslog blockiert?
Starten Sie auf dem Kollektor tcpdump -ni any port 514 oder Wireshark mit demselben Filter. Senden Sie parallel ein Testereignis vom Client. Kommen keine Pakete an, liegt die Blockade im Pfad, häufig an der Zonen- oder Sicherheitsgruppe. Ergänzend zeigen Firewall-Logs meist ein passendes Deny-Ereignis mit Quell-IP und Zielport.
Sollten wir Logs lokal und zentral speichern?
Ja. Eine lokale Kopie überbrückt Ausfälle des Kollektors und liefert Beweise, falls ein Angreifer Weiterleitungen abschaltet. Konfigurieren Sie eine Rotation mit definierter Aufbewahrung, schützen Sie das Verzeichnis mit strengen Rechten und übertragen Sie parallel an das zentrale System, damit Korrelation und Langzeitarchivierung möglich bleiben.