Check_MK-Einsatz absichern

20. August 2010 | Von | Kategorie: Monitoring | Availability

Check_MK erfreut sich zunehmender Beliebtheit beim Monitoring von Systemen. Ich habe bereits mehrere Artikel in diesem Blog zum Einsatz von Check_MK geschrieben. Einen weiteren Punkt möchte ich dir in diesem Artikel erläutern.

Standardmässig wird Check_MK mittels dem xinet-Daemon in die Monitoringstruktur eingebunden. Hierbei stellt der Daemon auf Port tcp/6556 den check_mk_agent zur Abfrage bereit. Eine Verschlüsselung der Daten findet hierbei jedoch nicht statt. Folglich können die Daten auch im Netzwerk mitgeschnitten werden.  Auch führt der Agent keine Authentifizierung des anfragenden Systems durch. Zwar kann eine Zugriffsbeschränkung durch eine entsprechende xinetd-Konfiguration auf IP-Ebene implementiert werden – eine wirkliche Authentifizierung ersetzt dies jedoch bei weitem nicht. In letzter Konsequenz könnte von allen Maschinen, die diese betreffende Maschine erreichen können, eine Abfrage des Agent durchgeführt werden. Um es gleich vorweg zunehmen, ein wirkliches Sicherheitsrisiko stellt diese nicht dar, weil keine Daten in das abzufragende System eingeschleust werden. Dennoch werden hierüber Daten über den Zustand des Systems zur Verfügung gestellt. Dies könnten zum Beispiel Angreifer dazu nutzen, um beispielsweise die Auswirkungen eines Angriffes auf das System festzustellen.

Für all diejenigen, die also eine Authentifzierung benötigen oder wünschen, will ich hier kurz die Absicherung mittels SSH vorstellen.

Konfiguration des SSH-Zugriffs

Voraussetzung für einen Einsatz einer Authentifizierung ist jedoch das keine Interaktion für die Anmeldung notwendig ist. Hierzu muss eine SSH-Anmeldung für den Benutzer root auf dem Zielsystem eingerichtet werden, die vollständig auf Basis von Schlüsselpaaren realisiert wird.

Wenn auf dem Nagios-Server noch kein SSH-Schlüsselpaar vorliegt, muss dieses also zunächst generiert werden. Zum Generieren von Schlüssel sind die folgende Befehle auszuführen.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nagios/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in check_mk.key.
Your public key has been saved in check_mk.key.pub.
The key fingerprint is:
d6:e1:34:df:a0:ba:45:67:ea:f9:b4:03:4a:20:df:45 nagios@nagios-monitor
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
| .     o         |
|. E . . S        |
| o o   o =.      |
|  + o o +...     |
| . o o *.  .o    |
|  .  .Bo... .o   |
+-----------------+

Bei der Schlüsselgenerierung solltest du natürlich keine Passphrase angeben, ansonsten wird bei jeder Anmeldung ja eine User-Interation benötigt.
Anschließend hast du ein Schlüsselpaar bestehend aus einem privaten und einem öffentlichen Schlüssel im Homeverzeichnis des Benutzer, als den du die Keyerzeugung gestartet hast vorliegen. Die Schlüssel werden wahrscheinlich die Bezeichnungen id_rsa und id_rsa.pub tragen.

Nun musst du den öffentlichen Schlüssel id_rsa.pub auf das Zielsystem an die Datei /root/.ssh/authorized_keys anhängen. Diese Datei ist Zeilenweise aufgebaut. In jeder Zeile steht ein Public-Key zur Authentifizierung. In die Zeile, in der du deinen SSH-Key eingetragen hast, trägst du am Anfang noch ein einschränkendes Command (fett) ein:

<strong>command="/usr/bin/check_mk_agent"</strong>ssh-rsa AAAAB3NzaC1...

Durch diesen Eintrag wird bei jeder Anmeldung mit dem zugehörigen privaten Schlüssel nur der Check_MK-Agent ausgeführt. Ansonsten können mit diesem Schlüssel keine anderen Befehle ausgeführt werden.

Anschließend kannst du den privaten Schlüssel noch in ein Verzeichnis kopieren auf das der Nagios-Prozess zugriff hat. Ebenso müssen auch die Zugriffsberechtigungen auf den Schlüssel entsprechend gesetzt werden. Ich habe den Schlüssel in das Konfigurationsverzeichnis von Nagios kopiert.


$ cp /home/user/.ssh/id_rsa /etc/nagios/keys/
# chown nagios.nagios /etc/nagios/keys/id_rsa
# chmod 400 /etc/nagios/keys/id_rsa

Du kannst es direkt auch ausprobieren. Als der Benutzer Nagios sollte nun der folgende Aufruf, dir den Datenstrom des Check_MK-Agent ausgeben.

$ ssh -i /etc/nagios/keys/id_rsa root@remote-machine
<<<check_mk>>>
Version: 1.1.6p1
<<<df>>>
/dev/hda1     ext3    63440936   3438608  56779692       6% /

Wenn dies bei dir soweit funktioniert, musst du nun noch Check_MK konfigurieren, dass es nicht mehr über den Default-Port sondern mittels SSH den Agent kontaktiert. Wahrscheinlich müssen Sie bei der ersten Verbindung die Authentizität des Server-Key-Fingerprints bestätigen. Prüfen Sie daher diesen und bestätigen nur korrekte Fingerprints!

Check_MK-Konfiguration für SSH-Verbindung

Check_MK stellt für die Anfrage abweichender Verbindung die datasource_programs-Direktive zur Verfügung. Diese verwende ich nun dazu um Check_MK mitzuteilen, das eine Verbindung mittels SSH erfolgen soll. Um mir die Konfiguration zu Vereinfachen verwende ich Host Tags zur Definition aller Systeme, die mittels SSH abgefragt werden sollen.

all_hosts = [
'web01|ssh',
 'web02|ssh'
]
datasource_programs = [
 ( "ssh -l root -i /etc/nagios/keys/id_rsa <IP>", ['ssh'], ALL_HOSTS ),
]

Hierdurch werden nun alle Hosts, die das Host Tag ssh gesetzt haben, automatisch mittels SSH abgefragt und auch inventarisiert. Die IP-Adresse des Zielsystems wird automatisch bei der Ausführung des Checks eingesetzt. Das spezielle Tag <IP> sorgt hierfür.

Zusammenfassung

Sie haben hierdurch nicht nur eine Verschlüsselung der Datenübertragung. Sondern auch eine Authentifizierung des anfragenden Systems.

Häufig ist der Einsatz von SSH auch daher notwendig, wenn nicht weitere Löcher für zusätzliche Ports in eine Firewall gebohrt werden sollen.

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Ping.fm Post to Reddit

Tags: | |

Schreibe einen Kommentar

Fühle dich ermuntert einen Kommentar, Anmerkungen, Hinweise oder deine Ideen zum Thema zu hinterlassen. Wir freuen uns über deine Rückmeldung.