Select Page

NETWAYS Blog

Kommende Icinga Web-Funktion: Rememberme

Wir freuen uns immer über Feedback von euch, um Icinga noch besser zu machen. Viele Icinga-Benutzer haben die Meinung geäußert, dass sie gerne eine Rememberme-Checkbox auf der Login-Seite von Icinga Web hätten, damit sie sich nicht jedes Mal anmelden müssen, wenn sie Icinga Web besuchen.
Wir haben an diesem neuen Feature speziell während des Home-Office gearbeitet und planen, es in der nächsten Version von Icinga Web zu veröffentlichen.

Hier sind einige Schritte, wie dies funktioniert:

  • Wir führen ein neues “remember me” Cookie und ein “Stay logged in” checkbox auf der Login Seite ein.
  • Alle sensiblen Benutzerinformationen werden mit einem RSA-Schlüsselpaar verschlüsselt.
  • Das Cookie läuft nach 30 Tagen ab.
  • Die Erneuerung erfolgt automatisch nach einer erfolgreichen “remember me” Authentifizierung und beinhaltet die Neuerstellung des RSA-Schlüsselpaares und des Cookies mit 30 Tagen Ablaufdatum.
  • Die Authentifizierung über das “remember me” Cookie löst unseren normalen Authentifizierungsprozess aus, d. h. die Anmeldung mit dem Benutzernamen und dem Kennwort und die Erstellung eines neuen Sitzungs-Cookies bei erfolgreicher Authentifizierung.
  • Das Cookie wird gelöscht, wenn die Authentifizierung fehlschlägt oder ein Logout ausgelöst wird.

Um die Geheimnisse des Benutzers sicher zu speichern, erzeugen wir auf der Serverseite ein RSA-Schlüsselpaar bei der Erstellung des “remember me” Cookies. Das Schlüsselpaar wird in unserer Web-Datenbank gespeichert. Der Inhalt des Cookies sieht wie folgt aus:

  • Öffentlicher Schlüssel
  • Benutzername und Kennwort, verschlüsselt mit dem öffentlichen Schlüssel

Damit ist der öffentliche Schlüssel unser gemeinsames Geheimnis. Bei der Authentifizierung über das “remember me” Cookie suchen wir den öffentlichen Schlüssel in unserer Datenbank, entschlüsseln die Geheimnisse mit dem privaten Schlüssel und lösen unsere normale Authentifizierung mit dem entschlüsselten Benutzernamen und Passwort aus.

Warum lösen wir die normale Authentifizierung aus?

Die normale Authentifizierung beinhaltet bereits die Überprüfung der Kombination aus Benutzernamen und Passwort. Auf diese Weise prüfen wir, ob der Benutzer existiert oder das Passwort geändert wurde.
Wenn das Cookie bereits existiert und der Benutzer die Seite besucht, entschlüsseln wir die Benutzergeheimnisse und versuchen, uns damit anzumelden. Das funktioniert genauso, als ob der Benutzer diese Informationen manuell eingegeben und auf Login geklickt hätte.

Du kannst die Entwicklung dieser Funktion auf Github verfolgen. Wenn Du einen anderen Vorschlag oder einen neuen Feature Vorschlag hast, den Du gerne sehen würdest, kannst Du gerne ein Issue auf Issue auf Github öffnen.

 

Sukhwinder Dhillon
Sukhwinder Dhillon
Junior Developer

Sukhwinder ist seit Januar 2020 bei NETWAYS und macht bei uns seine Ausbildung als Fachinformatiker für Anwendungsentwicklung. In seiner Freizeit fährt er gerne Fahrrad, trifft sich mit Freunden, oder sitzt vorm Computer und lernt etwas Neues.

Mein erstes Icinga Web 2 Modul

Im Laufe meiner Ausbildung habe ich nun ein PHP Projekt bekommen. Ich soll ein Modul für unser heiß begehrtes Icinga Web 2 schreiben. Thema des Modules, ist die Darstellung deiner aktuellen System und Icinga 2 Daten. Von Zonen bis Firewall eine komplette Übersicht.

Das Thema des Blogposts soll aber nicht das Modul sein. Sondern möchte ich euch einen kurzen und einfachen Überblick darüber geben, wie ein solches Modul aufgebaut ist:

Das wichtigste was du wissen musst: Icinga Web 2 Module basieren auf dem icinga Web 2 Framework! Was das für dich als Modul Entwickler bedeutet, möchte ich dir kurz erläutern.

Icinga Web 2 Framework

Bei dem Icinga Web 2 Framework handelt es sich um ein objektorientiertes Framework für PHP. So ist es zum Beispiel nötig, einen Controller und eine View, pro Anzeigeseite zu erstellen.
Die Ordnerstruktur dazu kann wie folgt aussehen:


└── example
|      └── application
|         ├── controllers
|         |   ├── BaseController.php
|         |   └── IndexController.php
|         └── views
|            └── scripts
|               ├── base
|               |   ├── config.phtml
|               |   └── index.phtml
|               └── index
|                  └── index.phtml
└── configuration.php

Durch den Controller und die view wird automatisch die URL gebaut: localhost/icingaweb2/”Modulname”/”Controllername”/”viewname”.

Controller

Was ist ein Controller im Icinga Web 2 Framework?

Der Controller ist der Ort an dem all deine Magie passiert. Also die ‘main’ der jeweiligen Seite.

Um einen Controller richtig zu definieren, hier einige wichtige Tipps, die unbedingt zu beachten sind:

Neben der korrekten Ordnerstruktur deines Modules und der richtigen Groß und Kleinschrebung, muss auch ein eindeutiges Namensschema deiner Dateiein eingehalten werden. Die Dateien müssen beispielsweise das dazu gehörige Schlagwort beinhalten.
Solltest du also einen Controller Index bauen wollen, besteht dein Filename aus dem ‘Controller Namen’ und dem Schlagwort ‘Controller’: IndexController.php

In deinem Controller werden Actions´s erstellt. Innerhalb dieser Actions wird der Quellcode geschrieben und deine Seitentabs erstellt.
Auch hier ist wieder auf Namensgebung und Groß und Kleinschreibung zu achten.

Beispielcode:

views

Was ist eine view?

Damit der Endbenutzer eine Ausgabe in seinem Icinga Web 2 erhält, werden die Ergebnisse deines Controllers an eine view weitergegeben.

Der Ordnername deiner view ist nicht frei wählbar. Er wird aus dem Namen deines Controller´s abgeleitet. Solltest du einen Controller namens Base haben, muss der Ordnername ebenfalls den Namen base haben (Man beachte, den Ordner klein zu schreiben).

In deinem Ordner werden nun die eigentlichen Views erstellt.
Die Standart Seite ist deine index.phtml. Solltest du eine Unterseite erstellen wollen, ist die view genauso zu nennen wie deine Action.

Ein Beispiel dafür wäre wie folgt:

configuration.php

In deiner configuration.php werden die Menüpunkte und sections erstellt. Solltest du für dein Modul also einen Reiter oder Unterreiter haben wollen, sind diese also hier zu definieren.

 

Solltest du ein eigenes Modul entwickeln wollen, oder dich nun mehr für das Thema interessieren, findest du unter dem Training-Module einen ausführlicheren Guide.

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.

User aus LDAP in Icinga Director Importieren

Ich hatte das Vergnügen mich etwas mit dem Icinga Director zu beschäftigen dabei war eine der Aufgabenstellungen die User aus unserem LDAP in den Director zu Importieren. Im Folgenden werde ich erläutern, welche Schritte notwendig sind, um dies zu tun. Dabei ist zu beachten, dass jede LDAP-Umgebung anders aussieht und diese nicht ganz genau für jede passen.

Zuerst legen wir im Backend an, woher der Director sich die Daten ziehen soll. Das tun wir in der resources.ini, welche unter /etc/icingaweb2/ liegt.
Dort fügen wir das Untenstehende ein und passen die Daten an unsere LDAP-Umgebung an.

[ActiveDirectory]
type = "ldap"
hostname = "example.com“
port = "389"
encryption = "starttls"
root_dn = "dc=example,dc=com"
bind_dn = "cn=serviceuser,ou=users,dc=example,dc=com"
bind_pw = "password"
timeout = "5"

Wenn das geschafft ist, wechseln wir zu Icinga Web 2 und gehen dort auf Configuration > Application > Resources und klicken dort auf ActiveDirectory um unsere Konfiguration zu überprüfen. Dort steht dann das, was wir gerade in die ressources.ini eingetragen haben. Natürlich kann dies auch gleich hier grafisch konfiguriert werden, aber der nächste Schritt muss eh auf der Kommandozeile erfolgen.

Die Vertrauenstellung zu Certificate Authority (CA) des Active Directory funktioniert überall ein bisschen anders:
Auf CentOS sind die LDAP-Clienttools gegen OpenSSL und Mozilla NSS gelinkt, heißt sie nutzen den zentralen Truststore und man kann die eigene CA folgendermaßen hinzufügen:

# cp /tmp/ca.pem /etc/pki/ca-trust/source/anchors/
# update-ca-trust extract

Möchte man den zentralen Truststore nicht nutzen, kann man in der ldap.conf den Pfad unter TLS_CACERTDIR abändern und die Methode c_hash nutzen:

# cd $(grep TLS_CACERTDIR /etc/openldap/ldap.conf | cut -f2 -d" ")
# cp /tmp/ca.pem .
# ln -s ca.pem $(/etc/pki/tls/misc/c_hash ca.pem | cut -f1 -d" ")

Alternativ dazu kann auch eine Datei mit allen zu vertrauenden Zertifikaten genutzt werden, wozu die Konfiguration auf TLS_CACERT geändert werden muss.

# vi /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/ca.pem

Dies ist beispielsweise bei Ubuntu, wo die LDAP-Clients gegen GnuTLS gelinkt sind, der Standard und man kann das CA-Zertifikat an die Datei:

TLS_CACERT /etc/ssl/certs/ca-certificates.crt

Wenn das geschafft ist und man die Daten Quelle hinzu gefügt hat, muss man noch den PHP-FPM-Service neustarten via systemctl restart rh-php73-php-fpm.service. Ab jetzt wechselt man in das web und konfiguriert von dort aus weiter.

Danach wechseln wir auf den Icinga Director, und gehen zu „Import Data Sources“, dort fügt man dann eine neue Datenquelle hinzu. Diese könnten so aussehen:

Add import source

Hier noch zur Erklärung des LDAP-Filters:
(memberof=CN=icinga,OU=Groups,DC=example,DC=com)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*)
Hinter memberof steht der Distingushed Name einer Gruppe, in der alle gewünschten benutzer enthalten sind, die userAccountControl steht für gesperrte Benutzer und wird entsprechend durch das ! negiert und da wir per Mail benachrichtigen wollen muss auch das Attribute mail gesetzt sein.

Zum Schluss wieder auf Add drücken und dann ist auch schon die Import Source erstellt.

Um die Daten noch anzupassen können Modifiers unter Icinga Director > Automation > Import source > Modifiers hinzugefügt werden. In unserem Fall wollen wir die Gruppenmitgliedschaft in den Abteilungen in einem einfacheren Format.


 

Zunächst wechseln wir in Icinga Director > Users > Contacts > User Templates > Add um ein Template zu erstellen bevor wir mit der Sync Rule beginnen können.
Hier sind ein paar Felder wichtig, welche geändert werden sollten, wenn man nicht den Default von Icinga 2 übernehmen möchte. Das sind folgende:

 

Dann auf Add drücken und dann sollte auf der linken Seite „User aus LDAP – not in use – ” stehen.

Als nächstes oben in der Tabliste zu Groups wechseln und dort dann Usergruppen anlegen. (Beispielsweise jede Abteilung als eigene Gruppe o. ä. )

 

Danach wieder links auf Icinga Director > Synchronize > Add, dort muss dann ein Rule name, Object Type, Update Policy sowie Purge eingestellt werden. Zum Schluss wieder Add drücken.

Damit ergibt sich folgende Liste an Properties für den User.

Jetzt noch die Properties setzen diese sind wieder in der Tablist zu finden. Hier müssen folgende Eigenschaften für jede Property gesetzt werden:

Jetzt muss nur Import und Synchronisation einmal gelaufen sein und das wars. Schon sind alle Benutzer aus dem LDAP in Icinga und können ggf. benachrichtigt werden.

Nathaniel Donahue
Nathaniel Donahue
Junior Consultant

Nathaniel hat 2019 die Wirtschaftsschule abgeschlossen. Wegen seinem Interesse am IT-Bereich entschied er sich dafür eine Ausbildung zum Fachinformatiker im Bereich Systemintegration zu machen und fing im September 2019 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er gerne am Computer, allerdings meistens zum Spielen, oder er unternimmt etwas mit seinen Freunden.

Benachrichtigungen mit Icinga 2 mal anders

Vor Kurzem stand ich im Rahmen eines Kundentermins vor der Anforderung noch die Benachrichtigungen für das Icinga 2 Setup umzusetzen. “Soweit kein Problem” dachte ich mir, allerdings war die genaue Anforderung dann doch etwas speziell: Sowohl bei Hosts als auch bei Services können SLA’s gesetzt werden (“gold”, “silver” oder “bronze”). Wenn bei einem Service kein SLA gesetzt ist, greift das Servicelevel des Hosts. Hier der erste Entwurf dazu:

apply Notification "host-mail-gold" to Host {
  import "mail-host-notification"

  period = "gold"
  users = host.vars.contacts

  assign where host.vars.sla == "gold"
}

apply Notification "service-mail-gold" to Service {
  import "mail-service-notification"

  period = "gold"
  users = service.vars.contacts

  assign where (host.vars.sla == "gold" && ! service.vars.sla) || (service.vars.sla == "gold")
}

read more…

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Computer Viren in der Cloud

Verschiedene Anbieter von Anti-Virus Produkten bieten mittlerweile SaaS Platformen an um eine zentrale Übersicht über den Status aller Systeme zu bekommen. Dort wird dann neben allen Details eine Übersicht von Alarmen bzw. Bedrohungen verfügbar.

Ein Kunde stellte mich vor die Herausforderung aus diesen Platformen per API die aktuellen Alarme und Probleme abzufragen, daraus sind zwei neue Plugins entstanden.

Hinweis: Wir machen hier keine Werbung für die Produkte, nur unsere Plugins. Wir stehen aktuell in keiner Geschäftsbeziehung zu beiden Anbietern.

read more…

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Veranstaltungen

Wed 21

Icinga 2 Advanced Training | Online

April 20 @ 09:00 - April 22 @ 17:00
Wed 21

InfluxDB & Grafana | Online

April 20 @ 09:00 - April 21 @ 17:00
Tue 27

Elastic Stack Training | Online

April 27 @ 09:00 - April 29 @ 17:00
Tue 27

Graylog Training | Online

April 27 @ 09:00 - April 28 @ 17:00
May 04

GitLab Fundamentals Training | Online

May 4 @ 09:00 - May 5 @ 17:00