Monitoring von Hosts hinter einer Firewall mit Hilfe von icinga und TLS

Wer seine Systeme mithilfe eines Monitoring-Servers überwacht, kennt das Problem: Möchte man Dienste hinter NAT bzw. hinter einer Firewall überwachen, ist ein einfacher Check nicht mehr ausreichend. Diese Dienste sind nicht direkt aus dem Internet erreichbar. Deshalb baut man sich meist eine Brücke per SSH, NRPE oder Ähnlichem.

Mit icinga wird dieses Szenario erheblich vereinfacht. Denn es bringt eine Möglichkeit mit, entfernte Instanzen abzufragen und die Ergebnisse der entfernt ausgeführten Checks lokal zu überwachen.

icinga nutzt ein spezielles TCP-Protokoll für die Kommunikation zwischen allen Instanzen. Dies können Cluster-, Load-Balancing- oder einfache Master-Client Setups sein. Die Verbindung erfolgt TLS-gesichert mit Austausch von SSL-Zertifikaten und unterstützt IPv4 sowie IPv6.

Hier soll es um das Master-Client Setup gehen. Damit sind eine beliebige Anzahl Clients und ein Master gemeint. Während die Clients nur lokal konfigurierte Checks ausführen, holt der Master die Ergebnisse der einzelnen Instanzen per TLS-gesicherter Verbindung ab und veröffentlicht sie im eigenen Backend.


Anwendungsfall: Master fragt Checks des Clients ab

Mehrere hinter einer Firewall befindliche Server sollen überwacht werden. Diese sind also nicht direkt vom Monitoring-Server aus erreichbar. Die Firewall selbst hat allerdings Komplettzugriff auf diese Server. Dort wird icinga installiert und es werden lokale Checks eingerichtet. Danach wird diese Instanz (Client) mit dem Monitoring-Server (Master) verbunden um dort die Checks einzuliefern bzw. abholen zu lassen.

Firewall-Konfiguration auf Seite des Masters

Als Erstes muss sichergestellt werden, dass der Master über Port 5665 TCP erreichbar ist. Die Kommunikation ist bidirektional, daher kann die Verbindung von beiden Servern hergestellt werden. Für die einfache Methode (CSR-Autosigning) empfehlen wir allerdings temporär die direkte Freischaltung von Port 5665 auf dem Master. Dies kann selbstverständlich nach der Installation wieder rückgängig gemacht werden.

iptables -A INPUT -i <interface> -s <client-ip> -d <master-ip> -p tcp --dport 5665 -j ACCEPT

Hier muss noch das jeweilige Interface ersetzt werden. Falls sich der Master ebenfalls hinter einer Firewall befindet, muss temporär eine NAT-Regel (inkl. FORWARD) eingefügt werden.

iptables -t nat -A PREROUTING -s <client-ip> -d <master-ip> -p tcp --dport 5665 -j DNAT --to-destination <master-ip>:5665
iptables -A FORWARD-i <interface> -d <master-ip> -p tcp --dport 5665 -j ACCEPT

Auch hier bitte nicht vergessen, die in <> gesetzten Werte entsprechend anzupassen.

Setup des Masters

Auf dem Master wird eine SSL-CA, ein signiertes Zertifikat und ein lokaler Endpunkt mit Zonen-Objekt benötigt. Außerdem muss das API-Feature aktiviert werden. Dazu wird von icinga ein Wizard mitgeliefert, welcher mit icinga node wizard gestartet werden kann.
Bitte unbedingt darauf achten, bei der ersten Frage ‘n’ (für Master) auszuwählen.

Welcome to the Icinga 2 Setup Wizard!
 
We'll guide you through all required configuration details.
 
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]: n
Starting the Master setup routine...
Please specifiy the common name (CN) [icinga-node1.localdomain]:
information/base: Writing private key to '/var/lib/icinga/ca/ca.key'.
information/base: Writing X509 certificate to '/var/lib/icinga/ca/ca.crt'.
information/cli: Initializing serial file in '/var/lib/icinga/ca/serial.txt'.
information/cli: Generating new CSR in '/etc/icinga/pki/icinga-node1.localdomain.csr'.
information/base: Writing private key to '/etc/icinga/pki/icinga-node1.localdomain.key'.
information/base: Writing certificate signing request to '/etc/icinga/pki/icinga-node1.localdomain.csr'.
information/cli: Signing CSR with CA and writing certificate to '/etc/icinga/pki/icinga-node1.localdomain.crt'.
information/cli: Copying CA certificate to '/etc/icinga/pki/ca.crt'.
information/cli: Dumping config items to file '/etc/icinga/zones.conf'.
information/cli: Created backup file '/etc/icinga/zones.conf.orig'.
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
information/cli: Enabling the APIlistener feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Created backup file '/etc/icinga/features-available/api.conf.orig'.
information/cli: Updating constants.conf.
information/cli: Created backup file '/etc/icinga/constants.conf.orig'.
information/cli: Updating constants file '/etc/icinga/constants.conf'.
information/cli: Updating constants file '/etc/icinga/constants.conf'.
Done.
 
Now restart your Icinga 2 daemon to finish the installation!

Der Wizard generiert außerdem einen sogenannten Ticketsalt und die Konstante NodeName in der Datei /etc/icinga/constants.conf wird gesetzt. Beides wird für die Installation der Client-Instanzen verwendet. Also sollte man sich vergewissern, dass beides erstellt wurde:

egrep 'NodeName|TicketSalt' /etc/icinga/constants.conf

Außerdem wurde auch eine Zone-Config generiert:

cat /etc/icinga/zones.conf

Anschließend muss icinga per systemctl restart icinga neu gestartet werden. Bei älteren Debian-Versionen (<=7) funktioniert das mit service icinga restart bzw. /etc/init.d/icinga restart.

Setup des Clients

Bevor es mit der Konfiguration des Clients weiter geht, muss dort icinga installiert werden.
Hier einmal beispielhaft die Installation unter Debian8/Jessie:

wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -
echo 'deb http://debmon.org/debmon debmon-jessie main' >/etc/apt/sources.list.d/debmon.list
apt-get update
apt-get install icinga

Für Hilfestellungen zur Installation von icinga möchten wir gern auf die Offizielle Dokumentation verweisen.

Auf dem Client muss ein vom Master signiertes Zertifikat und ein lokaler Endpunkt mit Zonen-Objekt erstellt werden. Außerdem muss das API-Feature aktiviert werden. Dies kann wieder mit dem Wizard passieren.

Wenn die Firewall des Masters wie oben beschrieben konfiguriert wurde (Port 5665 direkt erreichbar), kann jetzt CSR-Autosigning verwendet werden. Das erspart das manuelle Erstellen und Signieren von Zertifikaten. Der Wizard meldet sich, falls das nicht möglich ist.

Folgende Optionen werden abgefragt:

– CN (Common Name), entspricht FQDN
– lokaler Zonen-Name, entspricht FQDN
– Master Endpunkt-Name, in ‘zones.conf’ des Masters zu finden
– Verbindungsdaten: IP, Port(5665)

Bevor der Wizard gestartet wird, muss auf dem Master ein Ticket erstellt werden:

icinga pki ticket --cn <remote-fqdn>

Danach kann der Wizard erneut mit icinga node wizard gestartet werden.
Dieses Mal wählen wir ‘Y’ für Client.

Welcome to the Icinga 2 Setup Wizard!
We'll guide you through all required configuration details.
     
Please specify if this is a satellite setup ('n' installs a master setup) [Y/n]:
Starting the Node setup routine...
Please specifiy the common name (CN) [icinga-node2.localdomain]:
Please specifiy the local zone name [icinga-node2.localdomain]:
Please specify the master endpoint(s) this node should connect to:
Master Common Name (CN from your master setup): icinga-node1.localdomain
Please fill out the master connection information:
Master endpoint host (optional, your master's IP address or FQDN): 192.168.56.101
Master endpoint port (optional) []:
Add more master endpoints? [y/N]
Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
Host [192.168.56.101]:
Port [5665]:
information/base: Writing private key to '/etc/icinga/pki/icinga-node2.localdomain.key'.
information/base: Writing X509 certificate to '/etc/icinga/pki/icinga-node2.localdomain.crt'.
information/cli: Generating self-signed certifiate:
information/cli: Fetching public certificate from master (192.168.56.101, 5665):
     
information/cli: Writing trusted certificate to file '/etc/icinga/pki/trusted-master.crt'.
information/cli: Stored trusted master certificate in '/etc/icinga/pki/trusted-master.crt'.
     
Please specify the request ticket generated on your Icinga 2 master.
 (Hint: # icinga pki ticket --cn 'icinga-node2.localdomain'): ead2d570e18c78abf285d6b85524970a0f69c22d
information/cli: Processing self-signed certificate request. Ticket 'ead2d570e18c78abf285d6b85524970a0f69c22d'.
     
information/cli: Writing signed certificate to file '/etc/icinga/pki/icinga-node2.localdomain.crt'.
information/cli: Writing CA certificate to file '/etc/icinga/pki/ca.crt'.
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
information/cli: Disabling the Notification feature.
Disabling feature notification. Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Enabling the Apilistener feature.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
information/cli: Created backup file '/etc/icinga/features-available/api.conf.orig'.
information/cli: Generating local zones.conf.
information/cli: Dumping config items to file '/etc/icinga/zones.conf'.
information/cli: Created backup file '/etc/icinga/zones.conf.orig'.
information/cli: Updating constants.conf.
information/cli: Created backup file '/etc/icinga/constants.conf.orig'.
information/cli: Updating constants file '/etc/icinga/constants.conf'.
information/cli: Updating constants file '/etc/icinga/constants.conf'.
Done.

Folgende Aufgaben erledigt der Wizard automatisch:

– Generierung eines neuen Zertifikates
– Speichern des Master-Zertifikates und Anfrage eines unterschriebenen Zertifikates vom Master
– Erstellen einer lokalen Zone und Endpunkt basierend auf FQDN des Clients
– Deaktivieren der Notifications des Clients (diese generiert der Master)

Jetzt sollte die Config wieder verifiziert werden:

grep 'NodeName' /etc/icinga/constants.conf
cat /etc/icinga/zones.conf

Anschließend noch icinga neu starten.

systemctl restart icinga

Nachdem man auf dem Client seine Checks konfiguriert hat, muss auf dem Master nach Client-Services gesucht werden. Der Client führt zwar schon selbständig Checks durch, allerdings weiß der Master noch nicht, welche davon er überwachen soll. Mit icinga node list bekommt man eine Liste mit Client-Services (bekannt durch den Sync über Port 5665). Die benötigte Config für den Master kann mit icinga node update-config generiert werden. Diese wird dann in /etc/icinga/repository.d/ abgelegt.

Nach jedem Config-Update muss ein systemctl reload icinga ausgeführt werden. Sobald sich Änderungen an der Config des Clients ergeben, muss erneut ein icinga node update-config ausgeführt werden.

Ausblick

Das Synchronisationsprotokoll von icinga verwendet TLS unter Nutzung von OpenSSL und basiert damit auf anerkannten offenen Standards. Außerdem sind dadurch Sicherheitsupdates einfach und schnell möglich. icinga benötigt kaum System-Ressourcen, ist einfach zu warten und skalierbar. Durch die eigene Verschlüsselung lässt sich auch eine Art Mesh-Netzwerk in größeren Umgebungen aufbauen.

icinga ist quelloffen und wird derzeit stark weiterentwickelt. Wir unterstützen Sie gern bei Ihren Planungen oder zum Einsatz von icinga als Monitoring-System.

Remote-Monitoring mit Icinga