Den meisten dürfte Munin wohl bekannt sein, da es sich um ein Projekt handelt welches schon lange existiert. Munin ist eine Software zum Überwachen von Computern, besonders von Servern. Munin ist durch Plugins erweiterbar, kann aber bereits standardmäßig eine große Anzahl von Informationen sammeln, wie z.B. Prozessorauslastung, Festplattenbelegung, Netzwerktraffic usw.
Es eignet sich dabei sowohl zum Überwachen eines einzelnen Servers oder einer Vielzahl von Servern. Werden mehrere Maschinen überwacht, so fungiert ein Server als sogenannter Master. Auf diesem werden die Informationen von allen Maschinen gesammelt und ausgewertet. Die anderen Server werden als Nodes bezeichnet. Die Nodes sammeln nur Daten auf der lokalen Maschine und stellen sie dem Master zur Verfügung.
Standardmäßig fragt Munin nur den lokalen Rechner ab. Durch hinzufügen zusätzlicher Nodes in der /etc/munin/munin.conf werden auch die Informationen der entfernten Nodes abgeholt.
[webserver.beispiel] address 192.0.2.10
Die Verbindung wird hierbei vom Master zu den Nodes aufgebaut, d.h. die Nodes bieten ihre Informationen auf dem Port 4949 an, welcher dementsprechend für den Master erreichbar sein muss.
Damit Munin den Zugriff zulässt muss die IP Adresse des Masters in der /etc/munin/munin-node.conf auf den Nodes freigeschaltet werden.
allow ^192\.0\.2\.20$
Da der Port allerdings nur vom Master erreichbar sein muss, kann der Zugriff auf diesen Port auf die IP Adresse des Masters weiter eingeschränkt werden, z.B. via iptables oder einer anderen Firewallösung. Wer UFW nutzt kann die Einschränkung mit folgendem Befehl vornehmen, wobei die IP Adresse durch die IP des Masters ersetzt werden muss.
ufw allow from 192.0.2.20 to any port 4949
Wenn man nun den Munin Dienst auf allen Rechnern neu startet, sollte die Verbindung bereits funktionieren und in der Weboberfläche des Munin-Masters sollte nun die Informationen für einen weiteren Rechner angezeigt werden.
Allerdings werden die Informationen nun unverschlüsselt übertragen. Was in den eigenen vier Wänden vielleicht kein Problem darstellt, sollte bei einer Übertragung über das Internet unbedingt vermieden werden. Bei einer unverschlüsselten Übertragung können Dritte nicht nur die Daten mitlesen, sondern auch manipulieren.
Für die Absicherung des Datenstroms kommen verschiedene Methoden in Frage. Der Zugriff des Masters auf die Nodes kann über eine VPN-Verbindung abgesichert werden, oder der Master baut via SSH und Portweiterleitung eine Verbindung auf, oder die Verbindung wird (aufbauend auf oben beschriebener Konfiguration) via TLS verschlüsselt. Die Einrichtung der dritten Methode soll nun hier beschrieben werden.
Munin sieht zwei Konfigurationsmöglichkeiten für die Verschlüsselung via TLS vor. Das sogenannte Non-paranoid TLS setup sowie das Paranoid TLS setup. Bei ersterem erfolgt die Verbindung zwar verschlüsselt, allerdings werden die Zertifikate nicht überprüft, so dass mit jedem x-beliebigen Zertifikat eine Verbindung aufgebaut werden kann. im zweiten Fall werden für den erfolgreichen Aufbau einer Verbindung nur Zertifikate akzeptiert, die von der gleichen Certificate Authority (CA) unterschrieben wurden. Hierfür kann auch eine selbsterstellte CA verwendet werden.
Natürlich wird hier die zweite Möglichkeit genutzt. Damit Munin überhaupt TLS spricht muss zuerst das Perl Modul für SSL installiert werden mit
sudo apt install libnet-ssleay-perl
Certificate Authority (CA) erstellen
Zuerst wird ein privater Schlüssel für die CA erstellt. Dieser sollte mit einem Passwort geschützt und sicher verwahrt werden. Wer diesen Schlüssel in die Hände bekommt kann damit beliebige Zertifikate erstellen, denen die Nodes vertrauen.
openssl genrsa -aes256 -out ca-key.pem 2048
Mit diesem Schlüssel wird nun das Root-Zertifikat erzeugt. Dieses ist in diesem Fall 3 Jahre (1095 Tage) gültig.
openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1095 -out ca-root.pem -sha512
Man hat nun den privaten Schlüssel ca-key.pem sowie das Root-Zertifikat ca-root.pem erhalten.
Zertifikate für Master und Nodes erstellen
Nun müssen für den Master sowie für alle Nodes eigene Schlüsselpaare erstellt und von der oben erstellten CA signiert werden.
Zuerst werden wieder private Schlüssel erzeugt. Hier sollte kein Passwort vergeben werden, da dieses sonst bei jedem Neustart der Server oder des Munin Dienstes eingegeben werden muss.
openssl genrsa -out master-key.pem 2048 openssl genrsa -out node1-key.pem 2048 openssl genrsa -out node2-key.pem 2048
Im nächsten Schritt werden die Zertifizierungsanfragen (certificate signing request) aus den privaten Schlüsseln erstellt. Wie immer beim erstellen solcher CSRs ist es wichtig dass im Feld Common Name der Hostname des Servers eingetragen werden muss. Ist der Server also unter dem Hostnamen server1.example.com erreichbar muss dieser hier angegeben werden. Die Frage nach einem Passwort kann hier übersprungen werden.
openssl req -new -key master-key.pem -out master.csr -sha512 openssl req -new -key node1-key.pem -out node1.csr -sha512 openssl req -new -key node2-key.pem -out node2.csr -sha512
In einem letzten Schritt werden nun die unterschriebenen Zertifikate erstellt, die den öffentlichen Schlüssel enthalten und in diesem Beispiel 1 Jahr (365 Tage) gültig sind.
openssl x509 -req -in master.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out master-pub.pem -days 365 -sha512 openssl x509 -req -in node1.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out node1-pub.pem -days 365 -sha512 openssl x509 -req -in node2.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out node2-pub.pem -days 365 -sha512
Hierbei wird erneut das oben vergebene Password der CA abgefragt. Die .csr Datei können gelöscht werden, da diese nur zum erstellen des Zertifikates benötigt wurden.
Es existieren nun für jeden Rechner drei Dateien, die auf diese kopiert werden müssen. Z.B. in das Verzeichnis /etc/munin/ssl
Folgende Dateien werden auf allen Rechnern benötigt:
ca-root.pem
master-key.pem (bzw. node1-key.pem usw.)
master-pub.pem (bzw. node1-pub.pem usw.)
Gerade die privaten Schlüssel sollten vor fremden Blicken geschützt werden. Aus diesem Grund sollte der Zugrif auf Schlüsseldateien soweit wie möglich eingeschränkt werden. Dazu wird auf jedem Server in das Verzeichnis /etc/munin/ssl gewechselt und die Rechte eingeschränkt
/etc/munin/ssl sudo chown root:munin * sudo chmod 640 *
Anpassen der Munin Konfiguration
Damit Munin die Übertragung verschlüsselt muss die Konfiguration auf allen beteiligten Servern ergänzt werden.
auf dem Munin Master die /etc/munin/munin.conf
tls paranoid tls_verify_certificate yes tls_private_key /etc/munin/ssl/master-key.pem tls_certificate /etc/munin/ssl/master-pub.pem tls_ca_certificate /etc/munin/ssl/ca-root.pem tls_verify_depth 5
auf den Nodes die /etc/munin/munin-node.conf
tls paranoid tls_verify_certificate yes tls_private_key /etc/munin/ssl/node1-key.pem tls_certificate /etc/munin/ssl/node1-pub.pem tls_ca_certificate /etc/munin/ssl/ca-root.pem tls_verify_depth 5
Nach einem Neustart des Munin Dienstes wird die Verbindung via TLS verschlüsselt-
systemctl restart munin-node
Testen des Munin Ports
Das der Munin Port der Nodes nur noch via TLS erreichbar ist lässt sich einfach mit Telnet überprüfen, indem man versucht vom Master aus (Zugriffe mit anderen IP Adressen wurden ja generell untersagt) via Telnet eine Verbindung zu Port 4949 aufzubauen
telnet 192.0.2.20 4949
Man sollte dann eine Ausgabe wie die folgende erhalten
Trying 192.0.2.20... Connected to 192.0.2.20. Escape character is '^]'. # munin node at server.example.com # I require TLS. Closing. Connection closed by foreign host.
Quellen:
http://munin-monitoring.org/wiki/MuninConfigurationNetworkTLS
https://wiki.ubuntuusers.de/Munin/
https://legacy.thomas-leister.de/eine-eigene-openssl-ca-erstellen-und-zertifikate-ausstellen/
Comments are closed.