lcer00
Goto Top

Minimaler Syslogserver mit rsyslog

article-picture
Hallo,

auf der Suche nach einer praktikablen SYSLOG-Server Lösung für unsere nicht-Windows-Systeme geht es jetzt "back to the roots". Zwischenzeitlich hatte ich verschiedene Lösungen ausprobiert:


Aus verschiendenen Gründen hat alles nicht so richtig gepasst. Beispielsweise ist der Wartungsaufwand für Elasticsearch & Kibana insbesondere bei Major-Versionsänderungen enorm. Fastvue ist schick, aber leider kaum konfigurierbar, die Weboberfläche hat kein https ...

Jetzt habe ich mir mal wieder ein ganz minimales System auf Debian Basis gebastelt. Das Schöne ist - nach der Grundinstallation von Debian (netinstall-Image, keine graphische Installation, nur Standartsystemwerkzeuge) mit muss man kein einziges zusätzliches Paket installieren.

Das System bietet natürlich keine Auswertung der Syslogs. Das muss man dann anders lösen. Es ist dafür aber wesentlich ressourcenschonender und einfacher zu realisiseren als beispielsweise Elastic-Stack.


Debian verwendet rsyslog für die Protokollierung. Das bringt schon alles erforderliche mit. Die Dokumentation zu rsyslog ist auf den ersteb Blick linuxtypisch etwas unzugänglich. Die Dokumente findet man unter https://rsyslog.readthedocs.io/en/latest/

Rsyslog enthält eine sehr flexible Skriptsprache (Rainerscript https://rsyslog.readthedocs.io/en/latest/rainerscript/index.html ), mit der sich differenzierte Kontrollstrukturen programmieren lassen. (https://rsyslog.readthedocs.io/en/latest/rainerscript/control_structures ...) ). So ist eine ganze Menge Log-Verarbeitung mit Bordmitteln möglicht. Die meisten im Internet auffindbaren Beispiele zu rsyslog verwenden jedoch hauptsächlich Legacy-Formate - auch die Standard-Debian-Configurationsdatei. Das Verwenden von Rainerscript ist jedoch deutlich leistungsfähiger.

In diesem Tutorial zeige ich, wie man:

  • rsyslog zum empfangen von Syslog-nachrichten verwendet
  • Die Protokolle separat in dynamisch erzeugten Protokolldateien speichert.

back-to-topKonfiguration


back-to-topVorbereitungen

Zunächst müssen einige Verzeichnisse erstellt werden:


Die ersten beiden sind Spoolverzeichnisse für die eingehenden Nachrichten (siehe unten). Im dritten Verzeichnis sollen die Logdateien abgelegt werden. Die zusätzlichen Konfigurationsdateien enthalten Templates und Rulesets.
Deren Benennung ist eigentlich egal da die Konfigurationsdateien später per Platzhalter eingebunden werden.
Der Einlesereihenfolge wegen empfiehlt sich hier jedoch das voranstellen von Ziffern, so dass später gezielt erweitert werden kann.

back-to-topTemplates erstellen


Reinerscript ermöglicht die Verwendung von Templates: https://rsyslog.readthedocs.io/en/latest/configuration/templates.html https://www.rsyslog.com/how-to-bind-a-template/ In diesem Beispiel werden Templates vom Typ "string" benötigt.
Im Verzeichnis erstellt man eine Datei


Die Notation erfolgt im "neuen" Format. Siehe Infos unter https://rsyslog.readthedocs.io/en/latest/configuration/templates.html#le ...
Ist ist möglich, beliebige Eigenschaften, auch mehrere nacheinander, zu verwenden. Die später resultierenden Pfade erstellt rsyslog dann automatisch. Die Möglichen Eigenschaften kann man hier finden: https://rsyslog.readthedocs.io/en/latest/configuration/properties.html

Ich habe hier die Kombination aus fromhost-ip und hostname verwendet. IP ist immer eindeutig - der Hostname nicht unbedingt. Manchmal ist der Hostname auch sehr seltsam belegt (bei meinen Bintec-Router steht da unabhängig vom eingestellten Hostname des Routers immer den auf 3 Zeichen gekürzten englischen Wochentag !!!). Man kann das aber anpassen: https://rsyslog.readthedocs.io/en/latest/configuration/property_replacer ... machts möglich.

back-to-topRulesets erstellen


Die Rulsets sind Regelsets für die eingehenden Nachrichten. Hier kann man allerhand machen. Ich verwende hier zwar das Legacy-Format für die Aktion ( *.warn ), aber es sind auch umfangreiche Controllstrukturen möglich: https://rsyslog.readthedocs.io/en/latest/rainerscript/control_structures ... . Das "stop" am Ende sorgt dafür, dass keine weiteren Regeln auf die Nachricht angewendet werden. Läßt man das weg, landen die Nachrichten zusätzlich da, wo die /etc/rsyslog.conf sie hinsortiert - z.B. im syslog.


Ich habe hier eingehende Rulesets für TCP und UDP Transport erstellt. Das ist normalerweise nicht erforderlich. Ein Rulset würde genügen. Ausserdem erfolgt der syslog Transport typischerweise über UDP. Wer aber möglicherweise besonder wichtige Syslogsender per TCP transportieren lassen will, damit keine Pakete auf dem Weg zum Syslogserver untergehen, kann hier gleich noch separate Regeln hinzufügen.

Anmerkung zum Queue: Die Dokumentation findet sich unter https://rsyslog.readthedocs.io/en/latest/rainerscript/queue_parameters.h ... Im Beispiel werden die eingehenden Nachrichten zuerst einein Spool-Verzeichnis geschrieben, und dann abgearbeitet. Da die Nachrichten lediglich in lokalen Logfiles gespeichert werden sollen, ist dies ein Festplattenbasierter Queue eigentlich nicht erforderlich. Will man die Nachrichten dann aber ggf. an andere Logserver weiterleiten, bietet sich ein festplattenbasierter Queue an, da so das Risiko reduiert wird, beim Absturz oder Herunterfahren des Rechner Nachrichten, die noch im RAM liegen, zu verlieren. Ich habe den Queue jedenfalls mit in die Konfiguration aufgenommen, da die Config dann auch für etwaige Erweiterungen taugt.

back-to-topLetzte Anpassungen an der rsyslog.conf

Die folgende Config basiert auf der Standard-Debian-Config:


Hier ist die Reiheinfolge der Einträge wichtig! Die wesentlichen Punkte sind folgende:


  • Die UDP und TCP Module müssen geladen werden. Dazu entfernt man einfach die Kommentier-Raute.
  • Die dazugehörigen input-Statements bleiben auskommentiert. Zuerst müssen die Dateien aus /etc/rsyslog.d geladen werden!
  • Erst nach $IncludeConfig werden die Rulesets an das Input-Modul gebunden.
  • Erst danach kommen die Regeln der standard-Konfiguration.

Zum Schluss startet man rsyslog neu und überprüft den Status.


back-to-topTroubleshooting

Ein paar Hinweise:

  • Die Fehlermeldungen schreibt rsyslog ins das syslog. Dort sollte man nachschauen, wenn es probleme gibt. z.B. tail /etc/rsyslog face-smile
  • Eingehende Nachrichten werden nicht immer sofort verarbeitet und in die Logdatei geschrieben. Zunächst sollte man warten, ob die Logdatei bzw. Einträge nicht doch noch 1 Minute später erstellt werden.
  • Der Code eines Rulesets wird zur Laufzeit interpretiert. Daher ist bei Fehlern im Rulset-Code der Start von rsyslog möglicherweise erfolgreich, der Prozess stürzt aber ab, sobald ein engehendes Paket dem Ruleset zugewiesen wird. Daher lohnt es sich zu püfen, ob rsyslog nach 20 Minuten immer noch läuft (service rsyslog status)

back-to-topWie weiter?


back-to-toplogrotate Einrichten

Es macht Sinn, Speicherplatzsparend zu arbeiten und daher sollte man logrotate für die Logdateien aktivieren. Dier die ergänzte Debian Standart-Config aus /etc/logrotate.d/rsyslog


back-to-topNutzung

Wie nutze ich das? Na ganz einfach - die entsprechende Logdatei wird von der Console aus angezeigt:
... zeigt die letzten 100 Zeilen an.


... und alle weiteren folgenden, quasi "Live"

back-to-topwas noch fehlt...

Je nach Situation sollte man natürlich folgendes nicht vergessen:

  • ssh-Zugriff absichern
  • firewall aktivieren
  • Datensicherung einrichten.

Grüße
lcer

Content-Key: 1739455565

Url: https://administrator.de/contentid/1739455565

Printed on: February 7, 2023 at 23:02 o'clock

Member: beidermachtvongreyscull
beidermachtvongreyscull Jan 19, 2022 at 12:28:50 (UTC)
Goto Top
Danke für die Anleitung!

Kennst Du den hier schon:
https://sourceforge.net/projects/syslogserverwindows/

Den verwende ich recht gerne.

VG
bdmvg
Member: it-frosch
it-frosch Feb 03, 2022 at 16:56:48 (UTC)
Goto Top
Hallo Icer,

danke dir. Ich hatte für unsere Server auch mal einen Syslogserver (allerdings mit gebaut hatte aber dann immer wieder Probleme auf Grund der anfallenden Datenmengen die von den anderen Servern kamen.

Welche Ideen hast du für die Auswertung?
Momentan sammelst du du ja alle Logs nur auf dem Server. face-wink

Grüße vom it-frosch
Member: lcer00
lcer00 Feb 03, 2022 at 20:51:20 (UTC)
Goto Top
Hallo,

momentan benutze ich die Config als Dstensammelmaschine. Da kann kann ich hinterher schauen, wenn es Probleme gab. Oder man kann in Debugszenarien live zusehen, was passiert (tail -f).

Im einfachsten Fall könnte man alle Meldungen > Warnung in eine separate Datei Schreiben und deren Größe Monitoren, um dann zu schauen, was es gibt.

Gutes logfile-Monitoring ist nochmal eine ganz andere Nummer. Das fängt damit an, die richtigen Fragen zu stellen. Welche Logeinträge sind da relevant? Gibt es Schwellenwerte, wenn ja, wie hoch ist die Schwelle? Schau Dir z.B. die fail2ban Config an. Wie optimierst Du da die Parameter, um die Bösen Jungs auszusperren ohne den Regelbetrieb zu stark zu stören? Meine Cisco-Switches melden z.B. mit hohem Schweregrad, wenn ein Port keinen Link mehr hat. Die Info ist aber zumindest zum Feierabend recht sinnlos - natürlich werden die DesktopPCs da abgeschaltet.

Wenn Du wirklich proaktiv die Logfiles zum Erkennen von Fehlentwicklungen nutzen willst, sollte man nicht selbst basteln. Da würde ich über so etwas wie Elastic Stack gehen. Mittels logstash kann man detailliert die Daten Vorverarbeiten und Kibana kann das Visualisieren, mittlerweile sogar mit irgendwelchen KI-Algorithmen. Aber dazu muss man entweder viel Zeit einplanen oder besser noch, einen Mitarbeiter einstellen - oder backen.

Nach ja, ein wenig geht schon. Schau Dir mal die Output-Module von Rsyslog an. https://rsyslog.readthedocs.io/en/latest/configuration/modules/idx_outpu ...

Mail, Pipe oder SNMP-Trap wären Möglichkeiten, eine Benachrichtigung auszulösen. Kontrollstrukturen werden ja ordentlich unterstützt. https://rsyslog.readthedocs.io/en/latest/rainerscript/control_structures ...

Grüße

lcer
Member: Gentooist
Gentooist Sep 09, 2022 at 18:39:05 (UTC)
Goto Top
Ja das ist in der Tat schon recht minimal, wobei rsyslog wiederum nicht der minimalste Logging Daemon ist. Es gibt noch Metalog, Syslog-NG und den originalen sysklogd natürlich der sehr minimal ist.

Man kann übrigens Rsyslog auch in eine Datenbank loggen lassen, und dann per Webinterface (Loganalyzer) darauf zugreifen.
Member: aqui
aqui Sep 13, 2022, updated at Oct 13, 2022 at 08:16:30 (UTC)
Goto Top
...wie im hiesigen RasPi Tutorial oder direkt bei Loganalyzer beschrieben. ­čśë
Member: maretz
maretz Nov 23, 2022 at 07:29:12 (UTC)
Goto Top
Zitat von @Gentooist:

Ja das ist in der Tat schon recht minimal, wobei rsyslog wiederum nicht der minimalste Logging Daemon ist. Es gibt noch Metalog, Syslog-NG und den originalen sysklogd natürlich der sehr minimal ist.

Man kann übrigens Rsyslog auch in eine Datenbank loggen lassen, und dann per Webinterface (Loganalyzer) darauf zugreifen.

Was dann aber wieder mehr Schwachstellen hat - denn der DB-Server kann ja dann auch wieder crashen...

Ich würde hier mal ganz simpel anfangen:
a) Überlegen WAS überhaupt geloggt werden soll (wie beim Monitoring auch kommt man oft in die Versuchung jeden Furz zu überwachen - und am Ende soviel Daten zu haben das keiner mehr drauf guckt...)

b) WER soll das Prüfen? Egal wo die Logs nun liegen. Egal ob man die Auswertung auf der Konsole macht (ich nutze zB. einfach die Logfiles weil ich da schnell mit nem "cat /var/log/syslog | grep -i "error" " drübergehen kann... ) oder ob man da graphische Tools für nimmt,... Am Ende läuft es ja oft drauf raus das man dann irgendwo das super logging hat aber keiner reinguckt bzw. erst dann jemand reinguckt wenn irgendwas schon im Eimer ist... Auch hier der Vergleich zum Monitoring: Da wird ja auch gerne dann eingestellt das jeder Furz per Email rausgeht - was dann nach 1-2 Tagen bedeutet das sich die Empfänger ne Regel ins Postfach werfen das alles vom Monitoring in irgendeinen Unterordner wandert.

c) Wer betreut den LOG-Server? Auch da: Schön wenn die Kiste irgendwo in der Ecke steht.. Hier kann man sich z.B. auch nen einfaches Synology-NAS mit wenigen Klicks dafür aufbauen. Hilft nur nix wenn die Kiste irgendwann absemmelt, vollläuft oder sonstwas damit ist (der Praktikant hats geklaut ;) ) und es keiner merkt. Insbesondere bei ner VM muss man noch überlegen: Was passiert denn wenn der HOST sich da mit nem Problem meldet? (Ich mache zB. auch das Logging von Switches auf den Syslog... is aber natürlich nur solang hilfreich wie das Netzwerk soweit steht das die Log-Maschine erreicht werden kann... )

Wenn das alles geklärt ist dann kann man sich den rsyslog gut aufbauen (wobei ich meine man musste da gar nich soviel machen - habe mir das aber einfach in nen Ansible-Script gekippt, daher weiss ich nicht genau was da alles gemacht wird :D Einmal ins Script und raus ausm Hirn halt...).