Store passwords like a boss #2

Als Programmierer von Webanwendungen, die Ihre Benutzer selbst verwalten, kommt man um das Thema Sicherheit nicht herum – so auch ich als Mitentwickler von Icinga Web 2.

Aus diesem Anlass habe ich recherchiert, wie Passwörter von Benutzern sinnvoll gespeichert werden können und mein neu gewonnenes Wissen geteilt.

Darüber hinaus habe ich vorgeschlagen, Icinga Web 2 dementsprechend zu erweitern. Eric hat diesen Vorschlag begutachtet und mich auf eine Alternative aufmerksam gemacht, nämlich…

password_hash()

PHP bietet seit Version 5.5 u. a. diese Funktion, um Passwörter zu verschlüsseln. Diese ersetzt meine selbst geschriebene Funktion aus dem Vorgänger-Blogpost vollständig:

$encryptedNewPassword = password_hash($newPassword, PASSWORD_DEFAULT);

Der Rückgabe-Wert kann direkt in einer Datenbank gespeichert werden – so einfach ist das.

Der zweite Parameter der Funktion bestimmt den Verschlüsselungs-Algorithmus. Damit kann man diesen zwar frei wählen, aber ich empfehle, den Standard vorzuziehen, denn dieser ändert sich (laut Doku) mit neueren PHP-Versionen zu Gunsten der Sicherheit. Damit bleiben zumindest die neuen/geänderten Passwörter aktuell was die Sicherheit angeht.

password_verify()

Wie der Name schon andeutet, überprüft diese Funktion ein vom Benutzer eingegebenes Passwort auf Übereinstimmung mit einem verschlüsselten Passwort:

$ok = password_verify($enteredPassword, $encryptedPassword);
if ($ok) {
    ...

password_needs_rehash()

Wie bereits erläutert: mit einem neuen Standard-Verschlüsselungs-Algorithmus werden automatisch alle neu verschlüsselten Passwörter sicherer. Aber was ist mit den bereits bestehenden?

Da bestehende Passwörter (aus gutem Grund!) nur verschlüsselt vorliegen, können sie nicht alle “in einem Abwasch” migriert werden. Die einzige Gelegenheit ist die Anmeldung eines Benutzers, die das Klartext-Passwort erfordert. Und als wäre die Funktion für diese Gelegenheit geschrieben…

if ($ok) {
    $outdated = password_needs_rehash($encryptedPassword, PASSWORD_DEFAULT);
    if ($outdated) {
        $encryptedPassword = password_hash($enteredPassword, PASSWORD_DEFAULT);
    }
    ...

Fazit

Der IT-Branche wird nicht umsonst nachgesagt, dass sie eine “permanente Innovation” vollbringe. Umso wichtiger ist es, aus Gründen der Datensicherheit, mit der dunklen Seite der Macht mitzuhalten.

Denn die sind böse, sehr böse…

Alexander Klimov

Autor: Alexander Klimov

Alexander hat Ende 2013 mit einem Praktikum bei NETWAYS gestartet. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 und seiner Ausbildung bei uns friedliche Wege.

Chrome, certificates and missing_subjectAltNames Part 2 of 1

Actually I wanted to cover this topic in the previous post, but somehow have missed it.

Using the mentioned one liner can lead to typos and/or some strange behaviour on the CA side, especially when using a Windows-CA.

To circumvent this issues, I mentioned “a specially designed *.conf file” which I’d like to elaborate today.

Following steps are necessary:

Create a file “req.conf” in etc/ssl/ (Ubuntu 14.04, pathes may vary) with the following content:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = $YourTLD
ST = $YourState
L = $YourCity
O = $YourCompany
OU = $YourDepatment
CN = $YourCName (e.g. internal.company.tld)
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.internal.company.tld
DNS.2 = internal.company.tld
DNS.3 = www.*.internal.company.tld

Essentially, these are the information provided by the “-subj section” in last weeks one liner.

Now you can generate a key:

openssl genrsa -out internal.company.tld.key 4096

and use your new key and the req.conf file to generate a CSR, which, as usually can be fed into your local CA.

openssl req -new -out internal.company.tld.csr -key internal.company.de.key -config req.conf -sha256

This *.conf file can be used as a template for other C/altNames as well and is, in my eyes, more lucid than a one liner.

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Chrome, certificates and missing_subjectAltNames

Google has been actively trying to ensure certificate security especially in the last months.

Sometimes this created quite some buzz in the IT World, e.g. when Symantecs policies came into the focus.

Current version 58 of Google Chrome has again adjusted the certificate policy.

Certificates provide two ways to store hostnames: CommonName and SubjectAltName (SAN). RFC 2818 specified in 2000 that CommonName should be deprecated, which Chrome now complies to.

Other browsers are currently still accepting the CommonName, which is mostly used by selfsigned certificates, as in our case :/

Users who wanted to access our internal sites encountered error messages and were forced to use quick and dirty workarounds, such as using a Windows registry “hack”:

Open a cmd-Shell as Administrator and enter:

reg add \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1 /f

which reactivates the fallback to CommonName

As this is just a temporary “solution”, you should issue an RFC 2818 conform certificate. This can be realized by using a complete and compliant certificate signing request (CSR).

You can either use a specially designed *.conf File for this or simply adapt the following shell command:

openssl req -new-key endpoint.com.key -sha256 -nodes  -subj '/C=US/ST=New York/L=New York/O=End Point/OU=Hosting Team/CN=www.endpoint.com/
         emailAddress=administrative-not-existent-address@our-awesome-domain.com/
         subjectAltName=DNS.1=endpoint.com,
         DNS.2=usually-not-convered-domain.endpoint.com,
         DNS.3=multiple-domains-crt.endpoint.com' > www.endpoint.com.csr
The created csr can be fed e.g. into your local CA to issue new certificates which can be rolled out in your environment.
Live long and prosper and be RFC compliant 🙂
Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Like meeting the family – OSDC 2017: Day 1

OSDC Logo
I was happy to join our conference crew for OSDC 2017 again because it is like meeting the family as one of our attendees said. Conference started for me already yesterday because I could join Gabriel‘s workshop on Mesos Marathon. It was a quite interesting introduction into this topic with examples and know how from building our Software-As-A-Service platform “Netways Web Services“. But it was also very nice to meet many customers and long-time attendees again as I already knew more than half of the people joining the workshops. So day zero ended with some nice conversation at the hotel’s restaurant.

As always the conference started with a warm welcome from Bernd before the actual talks (and the hard decision which talk to join) started. For the first session I joined Daniel Korn from Red Hat’s Container Management Team on “Automating your data-center with Ansible and ManageIQ“. He gave us an good look behind “one management solution to rule them all” like ManageIQ (the upstream version of Red Hat Cloudform) which is designed as an Open source management platform for Hybrid IT. So it integrates many different solutions like Openshift, Foreman or Ansible Tower in one interface. And as no one wants to configure such things manually today there are some Ansible modules to help with automating the setup. Another topic covered was Hawkular a time series database including triggers and alarming which could be used get alerts from Openshift to ManageIQ.

The second talk was Seth Vargo with “Taming the Modern Data Center” on how to handle the complexity of data centers today. He also covered the issues of life cycles shrinking from timeframes measured in days, weeks and month to seconds and minutes and budget moving from CapEx to OpEx by using cloud or service platforms. With Terraform he introduced one of HashiCorp’s solutions to help with solving these challenges by providing one abstraction layer to manage multiple solutions. Packer was another tool introduced to help with image creation for immutable infrastructure. The third tool shown was Consul providing Service Discovery (utilizing DNS or a HTTP API), Health Checking (and automatic removal from discovered services), Key/Value Store (as configuration backend for these services) and Multi-Datacenter (for delegating service request to nearest available system). In addition Seth gave some good look inside workflows and concepts inside HashCorp like they use their own software and test betas in production before releasing or trust developers of the integrated software to maintain the providers required for this integration.

Next was Mandi Walls on “Building Security Into Your Workflow with InSpec”. The problem she mentioned and is tried to be resolved by InSpec is security reviews can slow down development but moving security reviews to scanning a production environment is to late. So InSpec is giving the administrator a spec dialect to write human-readable compliance tests for Linux and Windows. It addresses being understandable for non-technical compliance officers by doing so and profiles give them a catalog to satisfy all their needs at once. If you want an example have a look at the chef cookbook os-hardening and the InSpec profile /dev-sec/linux-baseline working nicely together by checking compliance and running remediation.

James Shubin giving a big life demo of mgmt was entertaining and informative as always. I have already seen some of the demos on other events, but it is still exciting to see configuration management with parallelization (no unnecessary waiting for resources), event driven (instant recreation of resources), distributed topology (no single point of failure), automatic grouping of resource (no more running the package manager for every package), virtual machines as resources (including managing them from cockpit and hot plug cpus), remote execution (allowing to spread configuration management through SSH from one laptop over your data center). mgmt is not production ready for now, but its very promising. Future work includes a descriptive language, more resource types and more improvements. I can recommend watching the recording when it goes online in the next days.

“Do you trust your containers?” was the question asked by Erez Freiberger in his talk before he gave the audience some tools to increase the trust. After a short introduction into SCAP and OpenSCAP Erez spoke about Image inspector which is build on top of them and is utilized by OpenShift and ManageIQ to inspect container images. It is very good to see security getting nicely integrated into such tools and with the mentioned future work it will be even nicer to use.

For the last talk of today I joined Colin Charles from Percona who let us take part on “Lessons learned from database failures”. On his agenda were backups, replication and security. Without blaming and shaming Colin took many examples which failed and explained how it could be done better with current software and architecture. This remembers me to catch up on MySQL and MariaDB features before they hit enterprise distributions.

So this is it for today, after so many interesting talks I will have some food, drinks and conversation at the evening event taking place at Umspannwerk Ost. Tomorrow I will hand over the blog to Michael because I will give a talk about Foreman myself.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

kostenfreie TLS-Zertifikate mit Let’s Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase “nur” wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.

Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als “nicht sicher”.

Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.

Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.

Aber wie kommt man nun zu den Zertifikaten?

Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.

Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.

Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.

Zertifikat nur 90 Tage gültig – was tun?

Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.

Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.

Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

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.

Siegfried Eichhorn

Autor: Siegfried Eichhorn

Siegfried ist ein Urgestein der IT, das die Dinosaurier noch selbst erlebt hat. Bei den ersten Projekten mit Open Source und Linux gabs noch komische Bemerkungen, aber das ist längst Geschichte. Nach vielen Projekten und Eskapaden hat er jetzt das Abenteuer NETWAYS gewagt und arbeitet dort als Consultant. Und wenn er da mal nicht arbeitet, genießt er Nürnberg.