1&1 cloud server unter Ubuntu 16.04.1 LTS, Teil 5, Apache und Let’s Encrypt, Fortsetzung

Der 5. Teil meiner Artikelserie beschäftigt sich mit den Sicherheitseinstellungen des Apache Servers, sowie der Konfiguration des Let’s Encrypt Clients und der Einrichtung einer automatischen Zertifikatserneuerung. Die Grundkonfiguration des Apache Servers und die erste Erstellung eines Let’s Encrypt Zertifikates haben wir im 4. Teil der Artikelserie besprochen. Nun wollen wir uns die Konfiguration des Apache und des Let’s Encrypt Clients noch im Details anschauen. Zunächst betrachten wir die Konfiguration für unsere Default HTTPS Seite, die der Let’s Encrypt Client erzeugt hat.

Wir sehen, dass der Let’s Encrypt Client das Zertifikatfile und das Schlüsselfile, sowie einen Server Namen eingetragen hat. Eine HTTPS Konfiguration ohne Servernamen ist hier sinnlos, da das Serverzertifikat für einen bestimmten Servernamen ausgestellt wurde. Ebenso wurden, wie angefordert, Header für HSTS und „Content-Security-Policy: upgrade-insecure-requests“ konfiguriert. Schliesslich hat der Let’s Encrypt Client noch eine Include Anweisung eingefügt. Die Datei /etc/letsencrypt/options-ssl-apache.conf enthält zusätzliche Anweisungen zur ssl Konfiguration.

Diese Datei und weitere Konfigurationsdateien des Apache werden wir im weiteren an unsere Bedürfnisse anpassen. Auf der einen Seite wollen wir eine möglichst sichere Konfiguration, auf der anderen Seite schränken wir damit den Zugriff auf moderne Browser und Clientprogramme ein. Hier ist ein vernünftiger Kompromiss zu suchen.

Hintergrundinfomationen zu den technischen Einzelheiten findet man in der technischen Richtlinie TR-02102-2 zur Verwendung von Transport Layer Security (TLS) des BSI, der RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) der Internet Engineering Task Force IETF und in den Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations des NIST.

Zur Zeit existieren mehrere Webseiten, auf denen man die Webserver-Konfiguration des eigenen Server scannen lassen kann. Wir werden uns die Ergebnisse dreier Testseiten anschauen. Dies sind der SSL Server Test der Qualys SSL Labs, der Free SSL Server Test der High-Tech Bridge SA, sowie das Mozilla Observatory.

Als erstes schauen wir uns die Ergebnisse unserer Default Konfiguration auf den drei Testseiten an, zunächst auf dem SSL Server Test der Qualys SSL Labs. Auf der Seite tragen wir die URL unseres Servers ein, setzen gegebenenfalls das Häkchen bei „Do not show the results on the boards“ und klicken den Submit Button. Der Test dauert mehr als eine Minute. Wenn der Testdurchlauf beendet ist gibt er uns einen detailierten Bericht zu unserem Webserver.

Das sieht ja schon mal gut aus, wir bekommen ein A+ Overall Rating, Details schauen wir uns später an. Zunächst interessiert uns das Ergebnis der anderen beiden Testseiten. Zunächst schauen wir uns das Ergebnis des Free SSL Server Test der High-Tech Bridge SA an. Auf dieser Seite geben wir ebenfalls unsere Domain ein, setzen gegebenenfalls das Häkchen bei „Do not display test results in statistics“ und klicken dann auf das blaue Dreieck im Domainnamenfeld. Der Test dauert ebenfalls etwa eine Minute und auch hier erhalten wir einen ausführlichen Bericht, der allerdings etwas andere Schwerpunkte setzt.

Hier erhalten wir FINAL GRADE A und wir können den Bericht als PDF herunterladen. Dokumentation zu den durchgeführten Tests finden wir unter den beiden Links im Kasten „SSL/TLS Security Test by High-Tech Bridge„. Details des Berichtes schauen wir uns später an.

Abschliessend lassen wir unseren Server durch das Mozilla Observatory scannen. Das Ergebnis ist etwas überraschend, aber auch hier sind die Schwerpunkte anders gesetzt.

Hier erhalten wir nur ein C- und nur 45 von 100 Punkten. Wenn wir weiter nach unten scrollen, finden wir den folgenden Abschnitt Suggestions:

Ein Click auf die Links Mozilla „Modern“ TLS configuration oder Mozilla „intermediate“ TLS configuration bringt uns auf der Mozilla wiki Security/Server Side TLS Seite zu den entsprechenden Tags. Wenn wir auf die Links „Wan’t the detailed technical nitty-gritty?“ klicken, werden Informationen zum Anpassen unserer Konfiguration eingeblendet, siehe folgende Abbildung.

Hier werden Vorschläge zu Änderungen an unserer Konfiguration gemacht. Unten im Bild gibt es eine Button Teleport me to Mozilla’s configuration generator!. Wenn wir diesen Button anklicken, landen wir beim Mozilla SSL Configuration Generator. Dort wählen wir Apache als unseren Webserver und unsere Version 2.4.18 aus. Dann geben wir noch unsere openssl Version 1.0.2g ein und wählen das „Modern“ Konfigurationsprofil aus. Damit erhalten wir eine Beispiel-SSL-Konfiguration für unseren Apache Webserver, siehe folgende Abbildung.

Diese Beispiel-Konfiguration, sowie die Empfehlungen auf den übrigen Testseiten, wollen wir zur Basis unserer Apache-SSL-Konfiguration machen. Zunächst erläutere ich die Änderungen an unserer Konfiguration, danach werden wir uns das Ergebnis auf den Testseiten anschauen.

Als erstes wollen wir OCSP Stapling konfigurieren. Dies sind die Zeilen aus der Beispiel-Konfiguration:

Für unsere Zwecke werden wir die Konfiguration aufteilen. Ich möchte die SSLStapling Optionen für den gesamten Apache-Server konfigurieren und die Aktivierung des Staplings in den einzelnen vhosts vornehmen.

Zunächst legen wir im Apache Konfigurationsverzeichnis ein neues Unterverzeichnis an.

Dort erzeugen wir eine Datei options-OCSPStabling-apache.conf mit dem folgenden Inhalt:

Per Include Anweisung binden wir dann diese Anweisungen in die Konfiguration des SSL Moduls /etc/apache2/mods-available/ssl.conf ein. Hier ein Auszug der geänderten Datei:

Zusätzlich müssen wir in unserer vhost Konfiguration, das OCSP Stapling aktivieren. Dies erreichen wir durch hinzufügen der folgenden Zeile zur vhost Konfiguration.

Ich habe eine entsprechenden Eintrag vor der SSLCertificateFile Anweisung eingefügt, siehe folgenden Auszug aus unserer vhost Konfiguration /etc/apache2/sites-enabled/000-default-le-ssl.conf:

Nun wenden wir uns nochmal unserer SSL-Konfiguration zu. Im folgenden Listing zeige ich meine aktuelle Konfiguration und werde sie im Anschluss erläutern.

Wie einfach zu sehen ist, habe ich verschiedene Konfigurationen für SSLProtocol und SSLCipherSuite eingetragen und die von mir nicht benutzten lediglich auskommentiert. Dies gestattet es später schnell zu einer anderen Konfiguration zu wechseln.

Ich habe mich hier für eine relativ strikte Konfiguration enzschieden, die auch eine Reihe älterer Clients aussperrt. Aber dies ist durchaus in meinem Sinne, denn ich gehe davon aus, dass derjenige der noch entsprechend alte Clients einsetzt nicht an diesen Sicherheits-Themen interessiert ist.

Das einzige SSLProtokoll das meine Konfiguration momentan unterstützt ist TLSv1.2. Wenn TLSv1.3 veröffentlicht ist, würde es ebenfalls unterstützt.

Die gewählten CipherSuites unterstützen alle PFS (Perfect Forward Secrecy). Die unterstützen Schlüsselaustauschverfahren sind ECDHE und DHE, zur Hintergrundinfomation siehe auch Diffie–Hellman key exchange, Elliptic curve Diffie–Hellman auf wikipedia.org und SSL/TLS & Perfect Forward Secrecy von Vincent Bernat.

Zur Authentifizierung wird unser RSA-Zertifikat mit 4096 bit Schlüssellänge benutzt. Let’s Encrypt unterstützt inzwischen auch die Benutzung von ECDSA-Zertifikaten, der Certbot aber noch nicht. Bis dies soweit ist, wird sicher noch einige Zeit ins Land gehen, siehe ECDSA subject key support #2660. Einzelheiten zu ECDSA sind ebenfalls auf wikipedia.org zu finden.

Zur Verschlüsselung verwenden die eingesetzten Suiten AES mit 256 oder 128 bit Schlüssellänge, mit 128 Bit Blocklänge im GCM oder CBC Modus. Der GCM Modus ist der Bevorzugte, siehe hierzu auch Galois/Counter Mode auf wikipedia.org. Als Message Authentication Code (MAC) kommt SHA384 oder alternativ SHA256, sowie SHA1 zum Einsatz. Zum Hintergrund von SHA siehe den wikipedia Artikel SHA-2.

Die Varianten mit Streamcipher ChaCha20 und MAC Poly1305 sind zwar konfiguriert, aber unser openssl 1.0.2g beherrscht diese noch nicht. Dazu ist openssl 1.1.0 erforderlich. Details zu ChaCha20 und Poly1305 sind ebenfalls auf wikipedai.org zu finden.

Die beiden SSLOpenSSLConfCmd Anweisungen setzen die ECDH-Parameter auf 384 bit bzw. wählen die Kurve secp384r1 aus.

Das Ergebnisse dieser Einstellungen auf den verschiedenen Testseiten wollen wir uns nun nochmals im Detail anschauen, zunächst für den SSL Server Test der Qualys SSL Labs.

Wie wir sehen erhalten wir wieder ein Overall Rating A+, einziger Test der nicht die volle Punktzahl erhalten hat ist der Test für die Cipher Strength. Dies erklärt sich dadurch, dass die Punktzahl für die stärkste Verschlüsselung, in unserem Falle AES mit 256 bit (100/100), und die Punktzahl für die schwächste Verschlüsselung, hier AES mit 128 bit (80/100), addiert und durch zwei dividiert wird. Details zur Bewertung findet man im SSL Server Rating Guide.

Nun wollen wir uns aber auch die Details des Tests näher anschauen. IN der folgenden Abbildung sehen wir Details zum Server Schlüssel und zur Zertifikatskette.

Die nächste Abbildung zeigt uns Details zu den konfigurierten Protokollen und Cipher Suiten.

Besonders interessant ist ein Blick auf die folgende Handshake Simulation.

In rot sehen wir, die nicht erfolgreichen Verbindungsversuche. Dies betrifft vor allem, alte Windows Versionen mit altem Internet Explorer, alte Android Versionen, sowie Java 6 und Java 7. Wenn wir Java überhaupt nicht unterstützen müssen, können wir die Cipher Suiten mit 128 bit AES-Verschlüsselung entfernen und somit volle Punktzahl erreichen. Der einzige der gezeigten Clients, der 128-bit AES Verschlüsselung anfordert, ist Java 8.

Zum Schluss schauen wir uns noch die Protokol Details an.

Das sieht alles in allem gut aus. Public Key Pinning (HPKP) wollen wir momentan nicht implementieren.

Damit wenden wir uns dem Free SSL Server Test der High-Tech Bridge SA zu, beginnend mit der Summary.

Auch hier erhalten wir wieder einen Final Grade von A+. Auch hier werfen wir noch eine kurzen Blick auf die Details.

Hier sehen wir, dass unsere Konfiguration nicht den Anforderungen der NIST Guidelines entspricht. Es fehlen uns das TLSv1.1 Protokol, sowie drei Cipher, die von der NIST vorgesehen sind, dies ist aber so gewollt.

Die folgenden beiden Abbildungen zeigen die Übereinstimmung mit den PCI DSS Anforderungen, bzw. den „Industry Best-Practices“.

Das sieht Gut aus.

Zuletzt sehen wir den „Web Server Security Overview“.

Hier sehen wir, dass wir bei der Konfiguration der HTTP Header noch einiges zu tun haben. Dem wollen wir uns aber erst später zuwenden. Zunächst wollen wir noch einen Blick auf die Ergebnisse des Mozilla Observatorys werfen.

Wenig überraschend erhalten wir immer noch nur ein C-, da wir die HTTP Header noch nicht richtig konfiguriert haben. Dies wollen wir nun nachholen.

Zunächst nehmen wir ein paar Änderungen an der Datei /etc/apache2/conf-enabled/security.conf vor. Als erstes ändern wir den HTTP response Header. Dieser wird gleich im zweiten Block der Datei mit der ServerTokens Directive gesetzt. In der Ubuntu Standardkonfiguration ist hier ServerTokens OS gesetzt. Diese Zeile kommentieren wir aus und fügen eine neue Zeile ServerTokens Prod ein. Der gesamt Block in der Datei sieht dan aus wie folgt:

Am Ende der Datei finden wir die beiden auskommentierten Anweisungen #Header set X-Content-Type-Options: "nosniff" und #Header set X-Frame-Options: "sameorigin". Bei beiden entfernen wir das Komentarzeichen. Das Ende der Datei /etc/apache2/conf-enabled/security.conf sieht dan wie folgt aus:

Abschliessend fügen wir noch zwei Anweisungen in unsere virtual host Konfiguration ein. Am Ende des VirtualHost Blocks in der Datei /etc/apache2/sites-available/000-default-le-ssl.conf fügen wir die folgenden beiden Zeilen ein:

Einen netten Hintergrundartikel zum Thema XSS und Content Security Policy von Hendrik Brummermann findet bei Heise, XSS-Bremse Content Security Policy. Der Artikel ist nicht mehr ganz aktuell (die modernen Browser verstehen inzwischen die Content-Security-Policy Anweisungen), gibt aber einen guten Überblick, über die Zusammenhänge. Die Content Security Policy Reference findet man hier.

Nun starten wir den Apache nochmals neu, systemctl restart apache2 und schauen uns anschliessend die Ergebnisse des Mozilla Observatorys an.

Jetzt erhalten wir auch hier ein A+, 100 von 100 Punkten. Wir können uns auch hier noch die Details anschauen. Interessant ist der Abschnitt „Third-party Scan Results“.

HSTS Preload wird von unserer Konfiguration nicht unterstützt, deshalb das X bei hstspreload.appspot.com. Das einzige was bei securityheaders.io angemahnt wird, ist das Fehlen von HPKP (Public Key Pinning). Ich habe momentan allerdings auch nicht vor dieses zu implementieren.

Mit dieser Konfiguration bin ich nun sehr zufrieden. Es bleibt jetzt nur noch eine automatische Erneuerung der Zertifikate einzurichten. Zunächst legen wir eine Konfigurationdatei für Let’s Enrypt im Verzeichnis /etc/letsencrypt an. Dazu kopieren wir die Beispielkonfiguration /usr/share/doc/python-letsencrypt-doc/examples/cli.ini in das Verzeichnis /etc/letsencrypt und passen sie an unsere Bedürfnisse an.

Ich habe hier nur meine E-Mail Adresse und die Schlüssellänge eingetragen, alles andere steuere ich über Kommandozeilenparameter.

Dann testen wir die automatische Zertifikatserneuerung auf der Kommandozeile.

Wir erhalten die folgende Ausgabe:

Danach wechseln wir in unser Home Verzeichnis und legen dort ein Verzeichnis „bin“ an.

In diesem Verzeichnis erstellen wir ein Script letsencrypt-updatecerts.sh mit dem folgenden Inhalt.

Anschließend setzen wir noch die Permissions.

Jetzt führen wir noch einen Testlauf unseres Scripts durch.

Das sieht gut aus. Unser Zertifikat ist noch nicht zur Erneuerung fällig. Abschließend legen wir einen crontab Eintrag an, der das Script einmal am Tag um 1:33  Uhr ausführt.

Am einfachsten rufen wir dazu crontab -e  auf und ergänzen am Ende der Datei die folgende Zeile:

Dann speichern wir ab und überprüfen mit crontab -l , ob der Eintrag korrekt ist. Die Meldungen, die das Script bei der Ausführung ausgibt, werden an den Benutzer, in diesem Falle „root“, gemailt. Dadurch haben wir die Kontrolle über auftretende Fehler.

Es gibt momentan noch einen Schönheitsfehler. Da der Mailserver noch nicht richtig konfiguriert ist, landen die Mails des cron jobs im lokalen Postfach für nobody. Das kann für den produktiven Betrieb so nicht bleiben. Da meine Domain, zu der unser Server gehört, auf einem Hostingvertrag ebenfalls bei 1&1 läuft und die E-Mails dort gehostet werden, ist die Lösung des Problems denkbar einfach. Wir müssen nur Postfix richtig für ausgehende Mail konfigurieren. Postfix ist als Mailserver vorkonfiguriert und läuft bereits.

Als erstes fügen wir noch einen Eintrag für unseren Server in der Datei /etc/hosts an.

Danach konfigurieren wir Postfix neu.

Die folgenden Abbildungen zeigen den Ablauf der Konfiguration. Der erste Dialog gibt uns einige Informationen zu den möglichen Server Konfigurations Typen.

Auf der nächsten Seite wählen die Konfiguration Satellite system.

Auf der nächsten Seite geben wir den voll qualifizierten Namen unseres Server als Sytem Mail Name an.

Auf der folgenden Seite tragen wir den Empfänger der System Mails ein. An diese Adresse werden Mails an root oder postmaster weitergeleitet.

Den Eintrag für den SMTP Relay Host lassen wir leer, damit sollte der MX-Record im DNS ausgewertet werden und dazu führen, dass der 1&1 Mailexchanger als Relayhost fungiert.

Auf der nächsten Seite wird angegeben, für welche Netzwerke unser Server Mails weiterleiten soll. Diesen Eintrag übernehmen wir unverändert nur für die lokalen Netzwerkadressen.

Auf der folgenden Seite konfigurieren wir synchrone Updates für die Mailqueue.

Auch den Eintrag auf der nächsten Seite übernehmen wir unverändert. Er legt fest für welche Domänen sich unser Server als Empfänger betrachtet.

Die nächste Dialogseite legt die maximale Postfachgröße fest. Wir belassen den Wert bei Null, das bedeutet unbegrenzte Mailboxgrösse.

Auch den nächsten Eintrag belassen wir bei der Standardeinstellung.

Für die lokale Auslieferung der Mail benutzen wir procmail. Wir müssen in diesem Fall daran denken nach dem Abschluss der Postfix Konfiguration ein entsprechendes Alias für root in der Datei /etc/aliases anzulegen.

Zuletzt setzen wir ipv4 als zu benutzendes Internet Protokol, öffentliche ipv6 Adressen haben wir ja nicht.

Nachdem wir den Konfigurationsdialog abgeschlossen haben, bekommen wir noch folgende Ausgabe:

Hier erhalten wir nochmals die Erinnerung, dass wir noch ein root alias einrichten müssen. Dazu ergänzen wir in der Datei /etc/aliases eine Weiterleitungszeile folgender Form.

Bitte eine sinnvolle E-Mail-Adresse eintragen, damit die Mails bei Euch ankommen. Diese Änderung muss noch in die aliases Database übernommen werden. Dazu müssen wir das Kommando  newaliases  ausführen.

Beim Testen musste ich feststellen, dass meine ausgehende Mail vom 1&1 Mailexchanger nicht akzeptiert wird. Doch ein Blick in die Datei /etc/postfix/main.cf zeigt sehr schnell wo das Problem liegt. Verursacher ist die folgende Zeile:

Dies ändern wir von Hand mit einem Editor.

Anschliessend starten wir Postfix neu.

Jetzt können wir testen, ob ausgehende Mail funktioniert.

Der Mailtext wird mit der Eingabe von Strg+D auf einer neuen Zeile beendet. Daraufhin wird die Möglichkeit angeboten eine CC Adresse anzugeben. Hier drücken wir einfach Return. Die Testmail sollte dann an der oben angegebenen E-Mail-Adresse ankommen.

Somit haben wir nun die Konfiguration eines Webservers mit Let’s Encrypt Zertifikaten abgeschlossen. Zum Abschluss machen wir noch einen Backup und nehmen dabei die Postfix Konfiguration ins Backup mit auf.

Im 6. Teil meiner Artikelserie werden wir dann auch Postfix für die Benutzung unserer Let’s Encrypt Zertifikate konfigurieren.