Im letzten Teil der Serie haben wir auf einem Ubuntu-Server einen syslog-ng Server aufgesetzt. In diesem Teil betrachten wir etwas genauer, wie man das System weiter verbessern kann.

Als erstes machen wir einen Exkurs zum Thema “Systemhärtung”. Der schönste Log-Server hilft wenig, wenn er als zentrales Einfallstor für einen Angriff missbraucht werden kann. Generell gibt es diverse Härtungs-Guidelines für Ubuntu Server. Ein Beispiel dafür findet man hier. Ein wichtiges Thema betrachten wir im Rahmen dieses Artikels:

Lokale Firewall: Wenn der Server nicht bereits von einer zentralen Firewall geschützt ist (z.B. indem er an einem dedizierten Interface einer Netzwerk-Firewall angeschlossen ist), dann sollte man sich zumindest mit einer lokalen Firewall behelfen. Unter Linux kommt hier üblicherweise iptables zum Einsatz. Ubuntu bietet hier mit ufw ein simples Interface zur Konfiguration. Dies geschieht wie Folgt:

sudo apt-get install ufw

sudo ufw enable

sudo  ufw allow ssh

sudo ufw allow 514/tcp

Bitte beachten Sie: ufw hat als Basis-Setup “default deny”. Sollten Sie also nicht lokal vor dem Rechner sitzen, dann schneiden Sie sich mit “ufw enable” Ihren Remote-Zugriff ab. In diesem Fall bitte VORHER unter /etc/ufw die passende Zugriffsregel definiern.

Mit dem Beispiel oben erlauben Sie nur Remote-Zugriff via ssh und Zugriff auf den syslog-ng-Dienst über Port 514 (tcp). Sollten Sie noch weitere Dienste zwingend benötigen, dann können diese analog ergänzt werden.

Nachdem Sie das System gehärtet haben, stellt sich die Frage nach der Sicherheit der Log-Daten während der Übertragung. Bisher werden die Daten im Klartext übertragen. Dies kann durchaus akzeptabel sein, wenn man ein dediziertes Log-Netzwerk betreibt. Sollte man die Daten allerdings über ein öffentliches Netzwerk (z.B. das Internet) senden, dann bietet sich eine Kommunikations-Verschlüsselung an. Früher musste man dazu die Log-Daten relativ umständlich über ssh oder stunnel tunneln. In neueren Versionen (ab 3.0) von syslog-ng ist allerdings direkt TLS-Verschlüsselung eingebaut, so dass sich Verschlüsselung relativ einfach aktivieren lässt.

Zuerst generiert man die Zertifikate für den Server und die jeweiligen Datenquellen. Wer damit keine Erfahrung hat, der möge hierauf einen Blick werfen. Freunde von grafischen User-Interfaces können hierfür unter Ubuntu auch tinyca verwenden.
Die Zertifikate müssen jeweils im pem-Format sein. Zusätzlich erwartet syslog-ng den Dateinamen des CA Zertifikats in einem bestimmten Schema. Dies erreicht man so:

ln -s cacert.pem `openssl x509 -noout -hash -in cacert.pem`.0

Anschließend konfiguriert man den syslog-ng Dienst auf dem Loghost neu:

source s_tls
{
    tcp
    (
        ip(<IP Adresse des Servers>)
        port(514)
        tls
            (
                ca_dir("/etc/syslog-ng/ca.d")
                cert_file("/etc/syslog-ng/server-cert.pem")
                key_file("/etc/syslog-ng/server-key.pem")
            )
    );
};

Auf einem Linux-Client geht man analog vor, nur dass hier entsprechend eine Destination definiert wird:

destination d_tls
{
    tcp
    (
        "<IP Adresse des Servers>"
        port(514)
        tls
        (
            ca_dir("/etc/syslog-ng/ca.d")
            cert_file("/etc/syslog-ng/client-cert.pem")
            key_file("/etc/syslog-ng/client-key.pem")
        )
    );
};

Mit dieser Konfiguration stellt man sicher, dass die Kommunikation verschlüsselt ist und dass der Server nur Verbindungen von Clients akzeptiert, die ein Zertifikat vorweisen können, das von der eigenen CA unterschrieben wurde.
Weiteres Anpassungen des Logservers dann in einem Folge-Artikel