Sicherheit ist ein wichtiges Thema und gerade bei Diensten, die im Internet betrieben werden können, extrem wichtig. In diesem Dokument soll erläutert werden, welche Techniken in der Software von Bloonix eingesetzt werden, um die Kommunikation und auch bestimmte Daten von Bloonix abzusichern.
Die Kommunikation zwischen den einzelnen Bloonix Komponenten wird standardmäßig via SSL abgesichert. Auf diese Weise ist es möglich, Serverkomponenten über SSL-Zertifikate zu validieren. Wenn sich zum Beispiel der Bloonix-Agent mit dem Bloonix-Server verbinden möchte, so kann der Agent sicherstellen, dass er sich auch tatsächlich mit einem validen Server verbindet, in dem der Agent das Zertifikat des Servers validiert. In allen Client/Server Komponenten gibt es hierfür in den Konfigurationsdateien identische Parametereinstellungen.
Für Clients sind das folgende Parameter:
server {
host $hostname
port $portnumber
mode failover
use_ssl yes
ssl_verify_mode peer
# Debian / SuSE / SLES
ssl_ca_path /etc/ssl/certs
# Red Hat / CentOS / Fedora
ssl_ca_file /etc/pki/tls/certs/ca-bundle.crt
}Die Parameter ssl_ca_path und ssl_ca_file geben den Ort an, an dem die Root-CAs liegen, um das Zertifikat des Servers zu validieren. Wenn ein Zertifikat nicht validiert werden konnte, so wird die Verbindung abgebrochen.
Auf Serverseite gibt es die Parameter ssl_key_file und ssl_cert_file für den privaten Schlüssel sowie das Zertifikat:
tcp_server {
port $portnumber
use_ssl yes
ssl_key_file /path/to/server.key
ssl_cert_file /path/to/server.cert
}Bloonix verwendet PBKDF2 als Hash-Verfahren, um aus den Benutzerpasswörtern für die WebGUI einen Schlüssel abzuleiten, welcher dann in der Datenbank gespeichert wird. Zur Generierung des Schlüssels verwendet Bloonix einen Salt mit einer Länge von 64 Zeichen, SHA512 und mindenstens 10000 Runden.
Alle Prozesse von Bloonix laufen auf unixoiden Systemen mit dem Benutzer bloonix, welcher während der Installation von Bloonix erstellt wird. Für den Fall, dass Bloonix zur Prüfung von Services Root-Rechte benötigt, wird sudo verwendet.
Hier gilt es eine wichtige Frage zu klären: "Wer verbindet sich mit wem?", oder auch: "Wer darf sich mit wem verbinden?". Diese Frage ist besonders für die Netzwerksicherheit wichtig, denn zwischen dem Monitoring-Server und dem zu überwachenden System muss eine Netzwerkverbindung aufgebaut werden. In manchen Netzwerkumgebungen kann das ein Hindernis sein, zum Beispiel wenn sich das Monitoring-System und das zu überwachende System in unterschiedlichen Netzwerken befinden.
Viele Monitoring-Systeme arbeiten nach folgendem Verfahren: es gibt einen Monitoring-Server, der die zeitgerechte Ausführung der Checks verwaltet und sich mit dem zu überwachenden System verbindet, um es zu überwachen.
Bei diesem Verfahren ist es notwendig, dass der Monitoring-Server zu jedem System, welches überwacht werden muss, eine Netzwerkverbindung aufbauen kann. Das Verfahren ist gut, solange sich alle Systeme, die überwacht werden müssen, auch im gleichen Netzwerk wie der Monitoring-Server befinden. Die Schwierigkeiten beginnen, sobald sich Systeme in fremden Netzwerken befinden. Insbesondere für Unternehmen, welche Monitoring als Dienstleistung anbieten möchten, kann dies eine große Hürde darstellen, denn kein Kunde vergibt gerne einen Zugang in sein internes Netzwerk.
Hinweis: Das Monitoring-System Nagios funktoniert auf diese Weise. Der Nagios-Server, welcher für die zeitliche Ausführung der Checks verantwortlich ist, benötigt eine Netzwerkverbindung zu jedem System, welches überwacht werden muss.
Wegen den oben genannten Schwierigkeiten funktioniert Bloonix anders, oder man könnte soagr sagen, Bloonix funktioniert genau anders herum.
Während bei vielen Monitoring-Systemen der Monitoring-Server eine aktive Komponente und für die zeitliche Ausführung der Checks veranwortlich ist, so ist der Bloonix-Server eine passive Komponente. Der Bloonix-Server ist weder für die zeitliche Auführung von Checks verantwortlich, noch benötigt der Bloonix-Server eine Verbindung zu jedem System, welches überwacht werden muss. Diese Aufgaben wurden an einen eigenen Dienst ausgelagert und zwar dem Bloonix-Agenten.
Der Bloonix-Agent wird entweder direkt auf dem zu überwachenden System installiert:
oder auf einem zentralen Server im Netzwerk installiert:
Der Bloonix-Agent verbindet sich mit dem Bloonix-Server und fragt entweder die Services ab, die in der WebGUI konfiguriert wurden und überwacht werden müssen oder liefert die Ergebnisse der Prüfungen ab. Dieses Verfahren hat den großen Vorteil, dass nicht jedes zu überwachende System für den Monitoring-Server erreichbar sein muss, sondern der Bloonix-Server muss für jeden Agenten erreichbar sein.
