Seite wählen

NETWAYS Blog

TLS Konfiguration von Icinga 2 mit collect_ssl_info checken

In Icinga2 und dessen Kommunikationsprotokoll ist SSL/TLS die Kommunikationsbasis. Transportverschlüsselung von Daten ist heute weit verbreitet wie das Beispiel HTTPS zeigt. Die technische Grundlage ist SSL/TLS. SSL steht für Secure Socket Layer und TLS bedeutet Transport Layer Security. Transportlayer Security ist nur eine neuer Name der die Weiterentwicklung verdeutlichen soll. Die entscheidende Grundlage ist die Standardisierung dieser Kommunikation um möglichst vielen Kommunikationspartnern eine problemlose Kommunikation zu ermöglichen.
Die Kryptographische Grundlagen sind mehrere Algorithmen für Datenhashing und Verschlüsselung die sich in vier Gruppen aufteilt. Die erste Gruppe sind Securehashe. Beim Hashing besteht die Aufgabe von Quelldaten eine Quersumme zu erzeugen die zweifelsfrei nur von identischen Daten identische Quersummen erzeugt und gleichzeitig einen Rückschluss von der erzeugten Quersumme, Hashwert auf die Quelldaten unmöglich macht. Die zweite Gruppe sind symmetrische Chiffrierer. Bei Symmetrischer Verschlüsselung muss zuallererst ein geheimer Schlüssel erzeugt und nur an den Kommunikationspartner übermittelt werden. Danach wird ein symmetrisches Verfahren vereinbart und mit dem geheimen Schlüssel die Daten an der Quelle verändert und diese Transformation am Ziel wieder Rückgängig gemacht. Für alle unbeteiligten sind diese veränderten Daten unleserlich und damit wertlos. Die Dritte Gruppe sind asymmetrische Chiffren. In den siebziger Jahren wurden Asymmetrische Verfahren erfunden. Der erste Algorithmus der sich verbreitet hat trägt den Namen RSA nach den Anfangsbuchstaben der Entwickler. Wesentliches Prinzip ist hier dass immer zwei komplementäre Schlüssel erzeugt werden wobei immer was mit dem einen Schlüssel verändert wurde kann nur mit dem zweiten Schlüssel rückgängig und wieder lesbar gemacht werden. Und weiter kann von einem Schlüssel nicht der andere hergeleitet oder erzeugt werden. Das bietet die schöne Möglichkeit einen Schlüssel zu veröffentlichen und den anderen geheim zu halten. Da jetzt beliebig viele diesen öffentlichen Schlüssel anwenden und damit Daten verschlüsseln können und nur der Besitzer des zweiten geheimen Schlüssels dies Daten wieder lesbar machen kann, sonst niemand und damit entfällt die Notwendigkeit zwischen Beteiligten geheime Schlüssel vorher austauschen zu müssen. Noch erwähnen möchte ich eine vierte Gruppe, die Schlüsselaustauschprozeduren wie beispielsweise Diffie-Hellman. Solche Verfahren ermöglichen es ein gemeinsames Geheimnis, geheime Schlüssel, zwischen zwei Partnern zu verabreden ohne das Dritte durch abhören erfahren können was ausgehandelt wurde.
Im praktischen Einsatz werden meist alle verfahren kombiniert eingesetzt um damit die Aufgaben

  • Identitätsfeststellung
  • Massendatenverschlüsselung
  • Datenauthentizität
  • Schlüsselaustausch

zu bewältigen. Asymmetrische Verfahren bieten bisher nur geringen Datendurchsatz und sind für Massendaten kaum zu gebrauchen, bieten aber die Möglichkeit der Identitätsfeststellung indem man mit dem öffentlichen Schlüssel ein bestimmtes Datenmuster verschlüsselt, zur Gegenseite transferiert mit der Aufforderung zu entschlüsseln, das Muster zu invertieren und mit dem zweiten privaten Schlüssel zu verschlüsseln und wieder zurückzusenden. Kann an der Datenquelle die Antwort mit dem öffentlichen Schlüssel wieder erfolgreich entschlüsselt werden und liefert das erwartete invertierte Bitmuster, ist sichergestellt dass am andern Ende der zugehörige private Schlüssel vorhanden ist und somit ist die Identität festgestellt. Bisherige Asymmetrische Verfahren benötigen zur ausreichenden Schlüssel-härte größere Schlüssellängen. Schlüssel-härte bezeichnet die Resistenz gegen Knacker. Als neue Verfahren sind in den letzten Jahren EC Verfahren, Elliptische Kurven Kryptographie, dazugekommen, die erheblich härtere Schlüssel haben und damit deutlich kürzer sein können. Ein Vergleich, beim RSA Verfahren sind weniger als 2048 Bit als unsicher anzusehen, hingegen ECDSA erreicht die gleich Härte schon mit gut 200 Bit Schlüssellänge. Mit Symmetrische Verfahren können Massendaten am schnellsten codiert werden und sie bieten eine relativ hohe Schlüssel-härte. Symmetrische Verfahren sind bereits mehrere tausend Jahre bekannt und es gibt viele verschiedene davon. In neuere Zeit hat sich hier der AES, Advanced Encryption Standard, verbreitet. 128 Bit lange Schlüssel sind heute bei diesem symmetrischen Verfahren schon als hart und damit als sicher zu betrachten. Aber beide Kommunikationspartner brauchen denselben geheimen Schlüssel und der muss vorher sicher erzeugt und ausgetauscht werden. Hier kommen Schlüsselaustauschprozeduren wie DH, Diffie-Hellman oder die neuere Variante ECDH, Elliptische Kurven Kryptographie Diffie Hellman zum Einsatz oder alternative werden auch asymmetrische Cipher dazu eingesetzt. Und nicht vergessen möchte ich die Aufgabe übermittelte Daten auf Authentizität zu prüfen und jede Veränderung zu bemerken und solche Daten als falsch abzuweisen wozu wieder Hashverfahren angewendet werden, mein HMAC bezeichnet, Hashed Message Authentication Code
Zusammengefasst

  • Symmetrische Verfahren arbeiten performant aber benötigen ein gemeinsames Geheimnis
  • Asymmetrische Verfahren arbeiten langsam aber verwenden zwei komplementäre Schlüssel die als privat und öffentlich bezeichnet werden
  • Secure Hashe bilden Prüfsummen von Daten
  • Schlüsselaustauschprozeduren handeln Geheimnisse aus

So besteht heute die Aufgabe öffentliche Schlüssel und Daten zu Personen, Firmen oder Rechnern zuzuordnen. Dazu haben sich mehrere Arbeitsabläufe etabliert. Manche, handeln nach dem Prinzip des Web of Trust, also wer kennt wen und vertraut wem und welche Schlüssel gehören zu wem. Andere handeln nach der Standardisierung x509, einem ITU-T Standard. Zur Erfüllung dieses Standards haben sich sogenannte Trustcenter etabliert die sich in zwei Aufgaben splitten der CA und der RA. CA bedeutet Zertifikatsautorität und hat zur Aufgabe kryptographisch Schlüssel und Datenzugehörigkeit zu beweisen in Form eines x509 Zertifikats. Der zweite Teil besteht aus der Registrierungs Autorität und der Aufgabe die Verifikation von Kundendaten wie Adresse, Firmenname, Rechnernamen und bei Fehlern Zertifikate zu verweigern. Ein Zertifikat enthält dann diese Daten, einen öffentlichen Schlüssel und die Signatur durch die CA.
Signaturen sollen Datenauthentizität sicherstellen. Dazu wird über die als korrekt bewerteten Daten mit einem Secure Hase eine Prüfsumme erstellt und mit dem privaten Schlüssel der CA verschlüsselt. Diese CA stellt ihren öffentlichen Schlüssel mit Ihren Daten als x509 Root-Zertifikat aus und hat diesen normalerweise bereits weit verteilt in Webbrowsern oder anderen Programmen. Eine zu jeder Zeit durchführbare Authentizitätsprüfung wiederholt den Schritt die Quersumme aus den vorhandenen Daten, wie Rechnernamen neu zu erzeugen, die verschlüsselte Quersumme in der Signatur mit dem öffentlichen Schlüssel der CA aus deren Zertifikat zu entschlüsseln und zu vergleichen. Sind beide identisch, so ist damit die Authentizität bewiesen. Solche Zertifikate können mehrstufige Ketten bilden und beginnen immer mit einem Root-Zertifikate der CA, einem Zwischenzertifikat und dem Server oder Clientzertifikat am Ende das dann in Massen ausgestellt wird.
Heute wird sehr oft SSL/TLS angewendet. Transport Layer Security beschreibt eine große Zahl von verfügbaren Ciphern, Chiffrierverfahren, deren Anwendung, Protokollen und besonders das jeweilige Handshake Protokoll, also das Aushandeln vom Kommunikationsparametern. Für SSL stehen mehrere Softwarepakte zur Verfügung die durch die Standardisierung untereinander in der Kommunikation kompatibel sind und verschlüsselt kommunizieren können. Diese Softwarepakete werden in der Regel in Kommunikationsprogramme als Bibliotheken eingebunden. Solche um SSL erweiterten Programme haben oft ein „S“ für Secure im Namen. Das SSL/TLS-Protokoll enthält heute das TLS-Record-Protokoll das die über TCP, Transmission Controll Protocol, die zu transferierenden Datenblöcke behandelt. Darüber werden die TLS-Protokolle, TLS-Handshake, TLS-Cipher-Spec, TLS-Alert-Protocol und das TLS-Application-Protocol transportiert. Für die praktische Anwendung werden fast immer mehrere Algorithmen kombiniert eingesetzt um Identitäten fest zu stellen, das gemeinsame symmetrische Verfahren zu vereinbaren und den gemeinsamen geheimen Schlüssel zu erzeugen und für beide Seiten zugänglich zu machen. Über TLS-Handschake beginnt die Kommunikation, wer ist wer, über TLS-Cipher-Spec wird der Symmetrische Cipher mit Parametern vereinbart. Anschließend werden Meldungen über das Alert-Protocol und die Massendaten über das TLS-Application-Protokoll transportiert.
Das TLS-Handshake-Protocol arbeitet beim Verbindungsaufbau diese Schritte ab

  1. Client schickt zum Server ein Hello
  2. Server identifiziert sich beim Client mit seinem Zertifikat
  3. Client kann sich bei Server mit seinem eigenen Zertifikat ausweisen oder mitteilen dass er keines hat
  4. Sind die vorangegangenen Schritte akzeptiert wird ein einmaliger gemeinsamer Schlüssel nur für diese Verbindung vereinbart, und im Abstand von Stunden geändert

Über das Alert-Protocol verständigen sich die Kommunikationspartner über verschiedene Events während der Kommunikation wie zB Datenblöcke fehlerhaft übermittelt oder andere Ereignisse.
x509 Zertifikate können also auch zur Authentisierung von Clients gegenüber Servern verwendet werden, sodass ein Server dies Zertifikate auf Zugehörigkeit oder weitere Angaben prüfen und dann zur Kommunikation akzeptierten oder ablehnen und die Verbindung beenden oder mit User und Passwortcheck fortfahren kann. Dies Möglichkeit bietet sich für automatische Verbindungen zwischen Servern oder Systemkomponenten an. Eine solche hierarchische x509 Zertifikatskette wird von Icinga 2 zur Authentisierung verwendet. Dabei existiert ein Root-Zertifikat einer CA auf einem Icinga 2 Server. Mit dem privaten Schlüssel dieser CA werden dann für jeden Kommunikationspartner eine eigenes x509 Zertifikat erzeugt. Entscheidender Teil ist der korrekte Rechnername, FQDN, Full qualified Domain Name. Danach erhält jeder Kommunikationspartner sein eigenes Zertifikat, den privaten Schlüssel und das Rootzertifikat der Icinga 2 CA.
Damit kann nur kommunizieren wer die „Erlaubnis“ per Zertifikat hat, also ein Zertifikat das in diesem Baum signiert ist und wenn, dann nur verschlüsselt. Zur weiten Detaillierung können in Icinga 2 Konfigurationsdateien die TLS Version und die erlaubten symmetrischen Cipher definiert werden. In jedem Zertifikat ist der Servername hinterlegt und damit wird die Kommunikation nur von diesem System mit einem Zertifikat aus dem Icinga 2 CA Baum angenommen. Im Unterschied zu Zertifikaten von Webservern akzeptiert Icinga 2 keine Metazeichen im Rechnernamen.
Beispieleinträge in einer /etc/icinga2/features-enabled/api.conf Datei

protocolmin = "TLSv1.1"
cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256"

Als Erweiterung zur Erleichterung der Einrichtung und Erstkontaktaufnahme mit dem Icinga 2 Server von Systemen mit Agenten werden sogenannte Tickets verwendet. Solche Tickets leiteten sich aus dem Root-Zertifikat, und dem Systemnamen des Agenten, FQDN, ab.
Erzeugen kann man Tickets auf zwei Arten

icinga2 pki ticket --cn mein.agent.de
c4eb335a1e62c4779bed3901eaa245699d92817b

oder via rest-api

curl -k -s -u apiuser:apipassword -H 'Accept: application/json' \
-X POST 'https://IcingaCAServer:5665/v1/actions/generate-ticket' \
-d '{ "cn":"mein.agent.de" }' | python -m json.tool

Und dieser API-User muss natürlich angelegt sein und sollte nur Rechte für generate-ticket haben. Das wird in der api-users.conf eingestellt

object ApiUser "apiuser" {
  password =  "apipassword"
  permissions = [ "actions/generate-ticket" ]
}

Für Administratoren stellt sich Aufgabe solche Sicherheitseinstellungen zu kontrollieren. Und dazu gibt es ein Toolchen das solche Einstellungen einfach über Netz abfragt, das Skript collect_ssl_info.

collect_ssl_info 192.xx.yy.zz:5665

fragt vom Icinga 2 Server das Zertifikat ab

collect_ssl_info 192.xx.yy.zz:5665 -showcerts

fragt die komplette Zertifikateskette ab
Und nun ein kleines Beispiel zur Abfrage nach schwachen Ciphern.

collect_ssl_info -qp -u 192.xx.yy.zz:5665 -u www.xyz.de:443 \
 -c RC4-MD5 -c AES128-SHA256
===== begin ciphertest 192.xx.yy.zz:5665 =============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest 192.xx.yy.zz:5665 ===============
===== begin ciphertest www.xyz.de:443 ==============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest www.xyz.de:443 ===============

jetzt erzeugen wir listen für ein zweites Beispiel
host.txt

192.xx.yy.zz:5665
www.xyz.de:443

cipher.txt

RC4-MD5
AES128-SHA256

und erledigen den gleichen Job mit Anwendung dieser Listen

collect_ssl_info -qp -ul host.txt -cl cipher.txt
===== begin ciphertest 192.xx.yy.zz:5665 ===============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest 192.xx.yy.zz:5665 ===============
===== begin ciphertest www.xyz.de:443 ===============
RC4-MD5                          failed
AES128-SHA256                    success
===== end ciphertest www.xyz.de:443 ===============

Eine Übersicht über die Icinga 2 Konfigurationsparameter.
Configuration Attributes:

Name Description
cert_path Required. Path to the public key.
key_path Required. Path to the private key.
ca_path Required. Path to the CA certificate file.
crl_path Optional. Path to the CRL file.
bind_host Optional. The IP address the api listener should be bound to. Defaults to 0.0.0.0.
bind_port Optional. The port the api listener should be bound to. Defaults to 5665.
accept_config Optional. Accept zone configuration. Defaults to false.
accept_commands Optional. Accept remote commands. Defaults to false.
cipher_list Optional. Cipher list that is allowed.
tls_protocolmin Optional. Minimum TLS protocol version. Must be one of TLSv1, TLSv1.1 or TLSv1.2. Defaults to TLSv1.


Das Skript steht zum Download bereit und viel weitere Info zur Konfiguration von Icinga 2.

Automate Icinga 2 Agent Configuration for Installer

bild02Icinga 2 wird inzwischen oft mit dem Icinga 2 Web Module Director verwaltet. Verbreitet sind die Möglichkeit aus anderen Datenbanken wie cmdb, Configuration Management Database, Informationen über installierte Hosts automatisch in den Director zu importieren. Bei diesen Importjobs können Filter die Quelldaten automatisch anpassen oder durch DNS-Abfragen ergänzen. Icinga 2 wird dann aus dem Director mit Informationen über Hosts und Checks und deren Anwendung beliefert um Verfügbarkeiten von Datenbanken, Webservern und vielen anderen Diensten regelmäßig zu prüfen. Die Ergebnisse werden dann protokolliert und natürlich bei Ausfall von Diensten sofort alarmiert.
Zum Ausführen dieser Prüfungen werden oft verschiedene Commandbridges wie beispielsweise NRPE oder SSH verwendet. Bei Icinga 2 gibt es heute die Möglichkeit anstatt dieser „Brücken“, „richtige“ Agenten einzusetzen die den Vorteil bieten, über aktuelle Protokolle zu arbeiten. Die Kommunikation zwischen Icinga 2 und solchen Icinga-Agenten oder Satelliten erfolgt mit SSL, Secure Socket Layer, verschlüsselt inklusive sicherer Authentisierung. Wichtige Funktion ist hier die gegenseitige Authentisierung aller Kommunikationspartner mit x509 Zertifikaten. Für diese Agenten ist ein dediziertes Setup zur Konfiguration und Erstellen der Zertifikate und Authorisationstickets erforderlich. Das stellt sicher das nur vom Administrator definierten Agenten die Kommunikation gestattet wird und alle anderen Kommunikationsversuche zuverlässig ausgesperrt bleiben.
Icinga führt Checks durch aufrufen der Kommandos in unterschiedlicher Weise aus.
1. Icinga direkt und der check kommuniziert mit dem Ziel
2. Remote via „Brücken“ wie NRPE und am Zielsystem wird der Check ausgeführt
3. Verteilt auf Satelliten und Agenten die hier die Checks ausführen
Satelliten und Agenten erfordern eine Konfiguration der Kommunikation und Verteilung von Checks. Zur Konfiguration der Kommunikation ist für alle Kommunikationsendpunkte ein PKI, Public Key Infrastructure, Setup erforderlich. Und zum Management werden Zonen definiert die ein Who is Who im Icingasystem ermöglichen. Darauf bauen dann Einstellungen auf die festlegen wer was prüfen soll. Hier erleichtert der Director diese Verwaltung durch strukturierte Konfiguration von Hosts, Checks und „apply“, Anwendungsregeln in einem modernen GUI, Garphical User Interface. Beliebte Funktionalität ist die intelligente Aufteilung der Konfiguration in sogenannte Templates und Hostdefinitionen. Mit solchen Templates wird von vielen Hosts verwendete Information nur einmal definiert und dann in den Host-Definitionen darauf verwiesen. Und so bietet sich für Agenten ein Template an das die Agenteneinstellung beschreibt. Sind diese Agenten definiert steht die Installation der Agentensoftware und deren Konfiguration an.
Für jeden definierten Agenten kann im Director ein Skriptvorschlag abgerufen werden. Viele Anwender betreiben heute automatisierte Software Verteiler und deren Installer. Solche Installer führen auch Konfigurationskripte aus. Die benötigte Information zur Konfiguration der Agenten ist im Director vorhanden  und PKI Setups als auch Authtentisierungsstickets werden benötigt. Und so bietet sich eine Realisierung als Skript an.
Ein solches Skript sollte
1. Die Hosts mit Agent aus der Directordatenbank auslesen
2. Die Konfigurationsdateien für den Installer erzeugen
Eine solche Skriptingmöglichkeit habe ich in zwei Teilen erstellt.
Im ersten Teil stelle ich ein Skript zum erzeugen dieser Konfigurationsdateien vor. Dieses Skript benötigt vorbereitete Teilskripte für die jeweiligen Betriebssysteme wie zum Beispiel Windows oder Linux und eine Liste die den Hostnamen und die Betriebssystemvariante enthält. Ich stelle hier ein Konfigurationsskript für Linux vor.
Im zweiten Teil beschreibe ich ein Skript zum Auslesen von Hosts mit Agent aus dem Director.
Erstes Skript
Dieses Skript kann auf zwei Arten angewendet werden. Im ersten Fall werden eine oder mehrere Konfigurationsdateien eingelesen und oder direkt aus stdin im zweiten Fall. Das Skript fügt die Hostinformation mit den vorbereiteten Teilskripten zu vollständigen Installerskripten je Host mit Agent zusammen und legt diese in einem Unterverzeichnis ab, bereit für einen Installer.
Ein Beispiel einer Host-liste

# Kommentar
host1.firma.de windows
host2.firma.fr ubuntulinux
# host3.firma.de suselinux

Das Skript gen_agent_scripts

mkdir: created directory ‘gen_agent_scripts.out’
gen_agent_scripts: write file test14.out/Icinga2Agent-host1.firma.de.psm1
gen_agent_scripts: write file test14.out/Icinga2Agent-host2.firma.fr.sh
gen_agent_scripts: 2 config scripts written to gen_agent_scripts.out
execute a script on an agent
‘/etc/icinga2/zones.conf’ -> ‘/etc/icinga2/zones.conf.20161107_040216.bak’
information/base: Writing private key to '/etc/icinga2/pki/host2.fr.key'.
information/base: Writing X509 certificate to '/etc/icinga2/pki/host2.fr.crt'.
information/pki: Writing certificate to file '/etc/icinga2/pki/trusted-master.crt'.
information/cli: Writing signed certificate to file '/etc/icinga2/pki/host2.fr.crt'.
information/cli: Writing CA certificate to file '/etc/icinga2/pki/ca.crt'.

Dieses Skript liest Host-listen ein und erzeugt damit je Agent eine spezifisches Konfigurationsskript, bereit zur automatischen Konfiguration dieser Agenten. Die Optionen des Skripts sind ein oder mehrmals -l und eine oder mehrere Listendateien.
icinga-agent-linux.name.sh
Diese komplettierte Agentskript erzeugt eine Zonenkonfiguration, erweitert die Einstellungen in api.conf und erledigt die PKI Konfiguration.
Die Skripte stehen auf github zum download bereit und viele weitere information zu Icinga 2 hier.

Icinga 2 Notifications manuell testen

Bei jeder Installation von Icinga 2 sollte das Notificationsystem getestet werden.
Je nach Installation werden verschiedene Gruppen eingerichtet, die abhängig vom Service beachrichtigt werden sollen. Solche Testbenachrichtigungen können in der Oberfläche von Icinga Web 2 erzeugt und losgeschickt werden. Aber dazu muss der jeweilige Host oder Service rausgesucht werden. Diese Aufgabe kann auch eleganter über die REST-API von Icinga 2 angestoßen werden.
Ein kleines Skript und schon gehts von der Kommandozeile:

#!/bin/bash
#
unset ftp_proxy
unset http_proxy
unset https_proxy
apiuser="myuser"
apipasswd="mypasswd"
server="localhost"
while getopts h:s: opt
do
  case "$opt" in
    h) host=$OPTARG ;;
    s) service=$OPTARG ;;
    h) Usage
       exit 1 ;;
    ?) echo "ERROR: invalid option" >&2
       exit 1 ;;
  esac
done
shift $((OPTIND - 1))
if [ -n "${service}" ] ; then
  # Bitte in eine Zeile zusammenfassen
  curl -k -s -u "${apiuser}:${apipasswd}" -H 'Accept: application/json'
  -X POST 'https://'${server}':5665/v1/actions/send-custom-notification'
  -d '{ "type": "Service", "service" : "'${host}"!"${service}'", "author": "icingaadmin",
  "comment": "This is a testmessage", "force": true }' | python -m json.tool
  exit
fi
if [ -n "${host}" ] ; then
  # Bitte in eine Zeile zusammenfassen
  curl -k -s -u "${apiuser}:${apipasswd}" -H 'Accept: application/json'
  -X POST 'https://'${server}':5665/v1/actions/send-custom-notification'
  -d '{ "type": "Host", "host" : "'${host}'", "author": "icingaadmin",
  "comment": "This is a testmessage", "force": true }' | python -m json.tool
  exit
fi
root@icinga-node1:$ ./send_icinga2_message -h srv04 -s ping4
{
    "results": [
        {
            "code": 200.0,
            "status": "Successfully sent custom notification for object 'srv04!ping4'."
        }
    ]
}

In Icinga Web 2 sieht das ganze dann so aus 🙂 Wenn ihr mehr über Icinga 2 wissen möchtet, kommt einfach auf uns zu.
bildschirmfoto_2016-09-16_16-27-16bildschirmfoto_2016-09-16_16-28-28
Die Notification-Scripts für die in den Screenshots gezeigten Notifications basieren auf den Blogpost „Icinga 2 + Director + Notifications = <3“ von Marianne Spiller.