# Syslog Integration: Das Netzwerk in die Logs holen

TL;DR / Management Summary Ein zentraler Log-Server auf Linux-Basis ist nur dann vollständig, wenn er auch die Daten Ihrer Hardware-Infrastruktur (Switches, PDUs, SAN) empfängt. Diese Geräte nutzen oft das klassische Syslog-Protokoll (Port 514). Ein Senior Admin konfiguriert rsyslog so, dass diese Nachrichten nicht mit den System-Logs vermischt werden, sondern in einer klaren Verzeichnisstruktur nach Hostname und Datum sortiert landen. Dies ist die Voraussetzung für ein ganzheitliches Netzwerk-Auditing.

# 1. Einführung & Architektur

Die Sprachen der Hardware.

Netzwerkgeräte sprechen meist:

• RFC 3164 (Legacy Syslog): Kurze, oft unpräzise Meldungen.
• RFC 5424 (Modern Syslog): Strukturierter, mit genauen Zeitstempeln und Metadaten.

# Der Integrations-Fluss (Mermaid)

graph LR
    A[Cisco Switch] -->|UDP 514| B[Linux Central Log Server]
    C[HPE Storage] -->|UDP 514| B
    D[Juniper Firewall] -->|TCP 514| B
    B --> E{rsyslog Templates}
    E --> F[/var/log/remote/switch01/...]
    E --> G[/var/log/remote/firewall01/...]

# 2. Server-Konfiguration: Den Empfang vorbereiten

Alles annehmen, nichts vermischen.

In der /etc/rsyslog.conf (oder einer separaten Datei unter rsyslog.d/):

# Schritt 1: Module laden

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

# Schritt 2: Dynamische Verzeichnisse (Das Profi-Template)

Verhindern Sie, dass /var/log/messages mit tausenden Switch-Meldungen geflutet wird.

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* -?RemoteLogs
& ~

• & ~: Sagt rsyslog, dass die Verarbeitung hier stoppen soll (die Meldung landet also nicht mehr in den lokalen Systemdateien).

# 3. Geräte-Anbindung: Praxisbeispiel

Dem Switch das Loggen beibringen.

# Beispiel: Cisco IOS

# Auf dem Switch konfigurieren
logging host 192.168.1.50 transport udp port 514
logging trap informational

# 4. Day-2 Operations: Log-Retention für das Netz

Disk-Usage bändigen.

Netzwerk-Logs können bei einem Port-Flapping massiv anwachsen.

1. Logrotate: Passen Sie logrotate so an, dass auch der Ordner /var/log/remote/ erfasst wird (Artikel 340).
2. Separate Partition: Legen Sie /var/log/remote auf ein eigenes LVM-Volume (Artikel 020), um die Stabilität des OS-Roots zu garantieren.

# 5. Troubleshooting & “War Stories”

Wenn die Logs stumm bleiben.

# Story 1: “Der falsche Hostname”

Symptom: Alle Logs der 50 Switches landen in einem einzigen Ordner namens 192.168.1.1 (die IP des zentralen Gateways). Ursache: Die Geräte stehen hinter einem NAT-Router. rsyslog sieht nur die Quell-IP des Routers. Lösung: Nutzen Sie das rsyslog-Template-Feld %FROMHOST% statt %HOSTNAME% oder stellen Sie die Geräte auf das modernere RFC 5424 Protokoll um, das den Hostnamen im Header mitschickt.

# Story 2: “Das UDP-Schwarze-Loch”

Symptom: Bei Lastspitzen (z.B. während eines Netzwerk-Ausfalls) fehlen genau die kritischen Meldungen auf dem Server. Ursache: UDP ist verbindungslos. Bei Netzwerk-Stress verwirft der Switch oder die Firewall zuerst die (für ihn unwichtigen) Logging-Pakete. Lösung: Nutzen Sie TCP für das Logging, sofern das Endgerät dies unterstützt. Falls nicht, erhöhen Sie die Empfangspuffer (Recv-Q) auf dem Linux-Host: net.core.rmem_max=16777216.

# 6. Fazit & Empfehlung

• Zentralisierung: Ein Linux-Server ist der kostengünstigste und leistungsfähigste Syslog-Knoten.
• Struktur: Nutzen Sie Templates konsequent. Ein unsortiertes Log-Verzeichnis ist nutzlos.
• Sicherheit: Erlauben Sie Inbound-UDP/TCP 514 nur von bekannten Netzwerk-Management-IPs.

# Anhang: Cheatsheet