Zentrale Speicherung von Logfiles
... aber bitte verschlüsselt!

Im ersten Teil dieser Reihe sind wir auf die grundlegende Konfiguration von syslog-ng eingegangen. Dieser Artikel knüpft an dieser Stelle an und erläutert unter anderem die Vorteile und Risiken der zentralen Speicherung von Logfiles. Hierdurch wird es z. B. möglich, Auswertungen über die Vorkommnisse auf allen Hosts durchzuführen und gegebenenfalls Schwachstellen leichter zu erkennen, um sie dann auszumerzen. Da die Meldungen aber standardmäßig unverschlüsselt über das Netzwerk übertragen werden, sollte zumindest über die Möglichkeiten einer Verschlüsselung der unter Umständen sensiblen Daten nachgedacht werden.

Eine Frage des Protokolls

source s_tcp { 
tcp(ip("192.168.1.20") port(514) max-connections(100)); 
};

destination remote { tcp("192.168.1.20" port(514)); };
log { source(src); destination(remote); };

client = yes
cert = /etc/stunnel/syslog-ng-client.pem
CAfile = /etc/stunnel/syslog-ng-server.pem
verify = 3
[514]
accept = 127.0.0.1:5140
connect = 192.168.1.20:514

cert = /etc/stunnel/syslog-ng-server.pem
CAfile = /etc/stunnel/syslog-ng-client.pem
verify = 3
[514]
accept = 192.168.1.20:514
connect = 127.0.0.1:5140

Syslog-ng bietet im Gegensatz zum alten Syslog die Möglichkeit, die Daten auch mittels TCP über das Netzwerk zu übertragen. Bevor man sich also über die Verschlüsselung der Daten Gedanken macht, ist es notwendig, die Frage nach dem richtigen Protokoll zu klären. TCP arbeitet verbindungsorientiert und garantiert, dass die Pakete in der richtigen Reihenfolge ankommen. Dies prädestiniert es für den Einsatz als Übertragungsprotokoll für Log-Meldungen. Es sollte jedoch nicht unterschlagen werden, dass nicht wie bei UDP ein Port für Syslog reserviert ist. Die Firma BalaBit, die syslog-ng entwickelt hat, schlägt in ihrer Dokumentation wie schon bei UDP die Nutzung von Port 514 vor. Dieser ist aber eigentlich für rsh bzw. rcp reserviert. Man sollte sich vorher sicher sein, dass man diese Dienste nicht mehr benötigt. Falls dies der Fall ist, ist TCP die erste Wahl.

Die Zentrale

Damit syslog-ng Meldungen empfangen kann, ist die Konfiguration des Daemons, so wie in Abbildung 1 gezeigt, auf der Serverseite notwendig. Wie im ersten Teil des Artikels [1] beschrieben, muss ein Source-Objekt eingerichtet werden, über das die Meldungen empfangen werden können.

Dieses Objekt muss festlegen, dass der Server auf dem Interface mit der IP-Adresse 192.168.1.20 und dem Port 514 Meldungen empfangen soll.

Standardmäßig existiert eine Beschränkung auf zehn Verbindungen gleichzeitig. Um Meldungen von mehr als zehn Clients empfangen zu können, muss dieser Wert erhöht werden. Es sollte aber darauf geachtet werden, dass man ihn nicht zu hoch einstellt, da der Server sonst unter Umständen anfällig gegen DoS-Attacken wird. Die empfangenen Meldungen müssen nun nur noch gespeichert werden - z. B. in Dateien.

Der Client

Auf dem Client muss eine Destination eingerichtet werden. Zusätzlich wird in einer Log-Anweisung festgelegt, welche Meldungen an dieses neu eingerichtete Ziel geschickt werden sollen (siehe Abbildung 2).

Diese beiden Zeilen führen dazu, dass alle Meldungen aus dem Source-Objekt src an das neu definierte Ziel remote geschickt werden. Dies wäre schon ein Beispiel für eine einfache Konfiguration, die dafür sorgen würde, dass der Client seine Meldungen an den Server schickt und dieser sie auch empfangen kann.

SSL-Verschlüsselung mittels Stunnel

In der Open Source Edition bietet syslog-ng keine eigene Möglichkeit, die Meldungen, die über das Netzwerk übertragen werden, zu verschlüsseln. An dieser Stelle kommt Stunnel ins Spiel.

Stunnel ist ein universeller SSL-Wrapper, der es ermöglicht, beliebige TCP-Verbindungen mittels SSL zu verschlüsseln. Dafür ist es notwendig, auf dem Client und auf dem Server einen Stunnel-Daemon zu starten, der die Meldungen auf dem Client entgegennimmt und an den Server weiterleitet.

Damit die in den Abbildungen 2 und 3 eingerichtete Verbindung durch Stunnel verschlüsselt werden kann, ist nur ein geringer Konfigurationsaufwand notwendig.

Konfiguration des Daemons

Die Ports auf den Systemen werden in unserem Beispiel, wie in Abbildung 3 beschrieben, konfiguriert. Dort ist auch die generelle Funktionsweise von Stunnel erläutert. Der Client schickt die Meldungen nicht, wie oben beschrieben, direkt an den Server, sondern erst an einen lokalen Port, auf dem Stunnel lauscht. Stunnel nimmt die Meldungen an und schickt sie an das in der /etc/stunnel/stunnel.conf angegebene Ziel. Auf dem Ziel muss auch ein Stunnel-Daemon lauschen, der das passende Zertifikat besitzt, die Nachrichten entschlüsselt und sie dann an den syslog-ng weiterreicht. Die Konfiguration des Clients bzw. des Servers kann in den Abbildungen 4 und 5 nachvollzogen werden.

Fazit

Die zentrale Speicherung von Log-Meldungen bietet viele Vorteile und ist ohne wesentlich höheren Konfigurationsaufwand realisierbar. Wenn man jedoch einen zentralen Syslog-Server plant, muss man sich auch über die Risiken im Klaren sein. Alle Daten, die unverschlüsselt über das Netzwerk übertragen werden, können brisante Informationen enthalten. Auch wenn sie verschlüsselt zum Server übertragen wurden, muss dieser so abgesichert sein, dass die Meldungen vor unbefugten Zugriffen geschützt sind. Dies sollte aber nicht nur bei einem zentralen Syslog-Server der Grundsatz sein.

Marius Dorlöchter (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen