Icinga2 GitLab Health Check

GitLab
Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).
Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.
Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.
Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):
GitLab Status
D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:
https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb
Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.
Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.
Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.
Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:
Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24
Stefan Gundel
Stefan Gundel
Senior Systems Engineer

Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.

Security Token für Jedermann: Der YubiKey

black_singleWie schützt man seine Daten am besten? Mit starken Passwörtern und genügend Entropie!
http://xkcd.com/936/
Besseren Schutz bieten zusätzliche Sicherheitsmerkmale wie 2-Faktor-Authentifizierung. Immer mehr Dienste bieten die Möglichkeit, sich mit einem zusätzlichen Einmalpasswort anzumelden. Dieses wird entweder auf einem anderen Medium dem Benutzer zugänglich gemacht (SMS, Abruf) oder wird von einem Token generiert. Tokens sind besonders spannend, da man jederzeit die Kontrolle darüber besitzt und unabhängig von Übertragungsproblemen ist (z.B. wenn man sich im Ausland aufhält). Nachteil: Teuer (z.B. SecurID) oder für Privatanwender zu aufwendig.
Mittlerweile bietet die Firma Yubico einen Token für $25 an. Günstig und viel Ausstattung. Die kleine Kunststoffplatte mit USB Kontakten ist wasserdicht und relativ unverwüstlich. Das Gerät wird vom System als Tastatur wahrgenommen und verschickt auf Knopfdruck verschiedene Strings, die zur Authentifizierung herangezogen werden können.
Der YubiKey kann selbst programmiert werden und unterstützt folgende Modi:

  • OTP (OTP YubiCloud oder OATH-HOTP)
  • Statisches Passwort mit 32 Zeichen
  • Challenge-Response

Diese Modi können in zwei Slots auf den Token programmiert werden. Die Slots werden durch den Druckknopf angesprochen: Weniger als 1,5 Sekunden für Slot eins und ungefähr 3 Sekunden für den zweiten.
Tools zum programmieren des Tokens gibt es für alle Systeme, jeweils in GUI oder CLI. Die GUI Version bietet praktischerweise auch den Upload des eigenen Keys in die YubiCloud an, was die Einrichtung deutlich vereinfacht.
Das OTP Modul für die YubiCloud erwartet auf der Gegenseite einen AES Key, welcher das eigentliche OTP Passwort entschlüsselt und dann auch validiert. Die ersten 6 Bytes des gesendeten Strings sind dabei der Public Identifier des Tokens. Anhand diesen Keys, kann der Schlüssel auf der Gegenseite identifiziert werden, um das eigentliche OTP zu entschlüsseln.
Alles weitere befindet sich in der ausführlichen Dokumentation von Yubico. Hier ist auch der Background und die Funktionsweise der Validierung und Provisioning von YubiKeys beschrieben.
Schön ist zu erwähnen, dass die Unterstützung des YubiKey stetig steigt: LastPass, Google, PAM, Radius, Windows Login, PayPal, KeePass et cetera.
Bleibt zu hoffen, dass es noch dauert bis jemand die erste Sicherheitslücke findet 😉

Bild Rechte v.l.n.r: CC-BY Marius Hein, (c) 2013 Yubico

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

One Time Password Authentifizierung mit MOTP

Eine OTP Authentifizierung ist eine praktische und vor allem sichere Angelegenheit. Aus verschiedenen Daten wird ein Passphrase errechnet, welcher nur für einen kurzen Zeitraum und einmalig gültig ist und somit nicht mehrmals verwendbar.
Es gibt viele Lösungen, welche auf Hardware-Tokens setzen und entsprechende Anschaffungskosten anfallen. Als gute Alternative bietet sich das Mobile One Time Password-Projekt an, kurz MOTP. MOTP ist mehr der eigentliche Algorithmus, auf dessen Basis diverse Clients für alle gängigen Betriebssysteme und mobilen Endgeräte (J2ME, Blackberry, Android, iOS, WebOS …) sowie serverseitig viele Implementierungen entwickelt worden sind. Heut möchte ich kurz ein Apache Modul und einen iOS Client vorstellen, mit denen eine einfache OTP Authentifizierung realisiert werden kann.
MOTP berechnet seine OTPs auf Basis dreier Komponenten:

  • PIN (bleibt gleich, wird beim Client eingegeben)
  • Secret (Im Regelfall ein Hash, welcher aus Zufallsdaten vom Client generiert wird)
  • Uhrzeit (MOTP setzt auf zeitbasierte Generierung, Zeiten müssen auf Client und Server übereinstimmen! – NTP)

Das verwendete Apache Modul, mod_authn_otp, muss zunächst compiliert werden. Eine Anleitung, welche Abhängigkeiten installiert werden müssen und wie es ordnungsgemäß installiert wird, findet sich im Projektwiki.
Angesprochen wird das Modul in der Apache Config als normales Basic Auth. Hier wird auch ein UserFile angegeben, wo die jeweiligen Nutzer mit ihren Secrets und dazugehörigen Pins angegeben werden. Zu beachten ist, dass dieses File vom Apache Benutzer schreibbar sein muss, damit das Modul einen Timestamp setzen kann. Dies bietet die Funktion, dass ein Token für einen festgelegten Zeitraum gültig ist, und somit der Nutzer nicht ständig aufgefordert wird, einen neuen Token eingeben zu müssen.
Als Client habe ich mOTP aus dem AppStore genommen. Diese App ist sehr einfach in der Bedienung und generiert selbst einen Secret, welcher in das UserFile übernommen werden kann. Auf der MOTP Projektseite gibt es eine große Auswahl an weiteren Clients für diverse Systeme. Beispielsweise wurde ein Client in Python geschrieben, welcher auf jedem gängigen OS funktionieren sollte.