Webserver

Nginx Reverse Proxy mit dynamischem Zielhost

Für meine Statusseite https://status.trashserver.net setze ich aus verschiedenen Gründen einen eigenen Reverse Proxy ein, um auf der Übersichtsseite von Uptimerobot.com HTTPS TLS-Verschlüsselung anbieten zu können. Nach der Einrichtung meines Nginx Webproxies war die Statusseite jedoch regelmäßig nicht mehr erreichbar (“502 - Bad Gateway”). Erst nach einem Neustart von Nginx konnte die Seite wieder aufgerufen werden. Die Ursache für die regelmäßigen Unterbrechungen war eine dynamische IP-Adresse hinter dem Zielhost “stats.uptimerobot.com”. Mit folgender, klassischer Konfiguration wird der Zielhost nur ein Mal beim Start von Nginx aufgelöst:

PHP-Anwendungen unter eigenem Systembenutzer ausführen

Kaum einer meiner Server läuft nur mit einer einzigen Anwendung. Der Webserver, auf dem dieser Blog läuft, beherbergt nicht nur thomas-leister.de, sondern auch noch zwei andere Blogs und weitere PHP-basierte Webdienste, die ich zur Verfügung stelle. Aus Sicht eines Hackers ein lohnenswertes Ziel: Wird über eine PHP-Anwendung wie z.B. einen schlecht gepflegten Wordpress-Blog Zugriff auf das Dateisystem des Servers erlangt, kann der Hacker nicht nur die unsichere Webapplikation angreifen, sondern auch alle anderen Anwendungen, die unter dem PHP-User laufen. Aus diesem Grund ist es sinnvoll, die PHP-Anwendungen etwas voneinander abzuschotten, sodass ein Angreifer von der einen PHP-Anwendung aus keine andere PHP-Anwendung beeinträchtigen kann. Dies erreicht man, indem man für jede Anwendung einen eigenen User anlegt, der PHP ausführt. Die Verzeichnisrechte werden so gesetzt, dass nur der jeweils zugedachte PHP-User Zugriff auf die Anwendungsdateien hat und keine weiteren Änderungen im Dateisystem vornehmen kann.

Kostenlose TLS-Zertifikate mit Let's Encrypt

Das Let’s Encrypt Projekt (hinter dem unter anderem Mozilla, Facebook und Cisco als Sponsoren stecken) ist gestern in den Public Beta Betrieb übergegangen. Von nun an können nach belieben kostenlose TLS (aka SSL)-Zertifikate für die eigenen Domains erstellt werden. Für den Erhalt eines Zertifikats sind nur wenige, einfache Schritte erforderlich, die ich im Folgenden erkläre:

Let’s Encrypt nutzt ein Protokoll namens “ACME” zur Kommunikation mit den CA-Servern. Ich habe den Referenz-ACME-Client “Certbot” von LE genutzt - um den soll es hier gehen. Außerdem wird der Client in dieser Anleitung direkt auf dem Zielserver ausgeführt - das ist die einfachere Methode. Wer den Client nicht auf dem Zielserver der Domains ausführen will oder kann (oder den laufenden Webserver-Betrieb nicht unterbrechen will), kann alternativ den “Manual Mode” verwenden (siehe Dokumentation unter: https://certbot.eff.org/docs/)

Selbst signierte Zertifikate mit eigener OpenSSL CA ausstellen

OpenSSL bringt umfassende Werkzeuge mit, um eine eigene, kleine Certificate Authority (CA) betreiben zu können. Die Nutzung einer eigenen CA ist besonders dann sinnvoll, wenn mehrere Dienste über SSL/TLS kostenlos abgesichert werden sollen. Neben dem Nachteil, dass die eigene CA vor Benutzung zuerst auf den Clientrechnern bekannt gemacht werden muss, gibt es aber auch einen Vorteil: Mit einer CA unter der eigenen Kontrolle ist man im Zweifel auf der sicheren Seite: In den letzten Jahren wurden immer wieder Fälle bekannt, in denen große Certificate Authorities falsche Zertifikate ausgestellt haben. Es gibt Grund genug, die Vertrauenswürdigkeit großer CAs anzuzweifeln.