Schlagwort-Archive: nginx

NGINX verweigert Neustart – [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use)

In diesem Artikel möchte ich einige Informationen zur NGINX-Fehlermeldung „[emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use)“ wiedergeben.

Als ich heute Morgen die E-Mail-Reports meiner Server durchgesehen habe, fiel mir die Meldung ins Auge, dass auf einem meiner Server die NGINX-Konfiguration nicht erneut eingelesen werden konnte. Auch der Versuch eines manuellen Neustarts wurde mit folgender Meldung quittiert:

# sudo service nginx restart
* Restarting nginx nginx [fail]

Konfiguration überprüfen

Die obige Meldung gibt noch keinerlei Hinweise auf die Ursache des Fehlers. Mit dem folgenden Kommando lässt sich die Konfiguration des NGINX überprüfen und der Fehler etwas eingrenzen:

# sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] listen() to 0.0.0.0:80, backlog 511 failed (98: Address already in use)
nginx: configuration file /etc/nginx/nginx.conf test failed

Die Fehlermeldung sagt aus, dass der NGINX-Prozess nicht erneut an den Port 80 gebunden werden kann, da dieser bereits verwendet wird. Für mich noch immer etwas verwirrend, da NGINX ja noch läuft und selbstverständlich auf Port 80 lauscht. Weshalb dadurch plötzlich kein Neustart mehr möglich ist, erschließt sich mir noch nicht.

Eine Lösung

Bei der Internetrecherche nach einer Lösung, bin ich auf einen englischsprachigen Troubleshootingguide gestoßen, welcher empfiehlt, alle Prozesse, die auf Port 80 lauschen, mit dem folgenden Kommando zu beenden:

sudo fuser -k 80/tcp

Anschließend konnte ich den NGINX wie gewohnt neu starten (restart) oder die Konfiguration neu einlesen (reload). Das Problem scheint damit erstmal behoben zu sein.

Kurztipp: nginx_modsite

In diesem Post möchte ich ganz kurz das Skript nginx_modsite vorstellen.

Dieses ermöglicht die einfache De-/Aktivierung von Nginx-Konfigurationsdateien in den Standard-Verzeichnissen /etc/nginx/sites-available und /etc/nginx/sites-enabled.

Das Skript wurde ursprünglich 2010 von Michael Lustfield erstellt. Es ist u.a. in meinem GitHub-Repository1 zu finden.

Zur einfachen Verwendung kopiert man das Skript in das Verzeichnis /usr/local/sbin. Ruft man es mit den Argumenten -h bzw. --help auf, erhält man eine Übersicht der verfügbaren Optionen:

sudo nginx_modsite -h
Usage: nginx_modsite [options]
Options:
<-e|--enable> Enable site
<-d|--disable> Disable site
<-l|--list> List sites
<-h|--help> Display help

If is left out a selection of options will be presented.
It is assumed you are using the default sites-enabled and
sites-disabled located at /etc/nginx.

Somit müssen die Links in /etc/nginx/sites-enabled nicht mehr per Hand erstellt werden. Alles in allem ein sehr schönes Skript, welches ich nicht mehr missen möchte.

Kurz vorgestellt: Mozilla SSL Configuration Generator

In diesem Artikel möchte ich euch kurz den Mozilla SSL Configuration Generator vorstellen, auf den mich ein Kollege aufmerksam machte.

mozilla_ssl_configuration_generator

Mozilla SSL Configuration Generator

Es handelt sich dabei um eine Seite, die dabei hilft, valide Konfigurationen für verschiedene Webserver wie Apache, NGINX, Lighttpd, HAProxy oder AWS ELB zu erstellen. Man gibt dazu den verwendeten Webserver, dessen Version und die OpenSSL Version an. Die Seite erstellt daraufhin die Konfiguration, welche per Copy&Paste übernommen werden kann. Lediglich die enthaltenen Pfadinformationen sind an die eigenen Bedürfnisse anzupassen.

mozilla_ssl_configuration_generator_nginx

Konfiguration für nginx 1.4.6 | modern profile | OpenSSL 1.0.1e

Neben der Konfiguration erhält man auch noch die Information dazu geliefert, welche Browser mit der erstellten Version kompatibel sind.

In einer ersten Stichprobe scheint die Seite ganz brauchbare Ergebnisse zu liefern. Ich freue mich über eure Meinungen und Erfahrungen zu diesem Dienst.

Bei positiver Resonanz nehme ich einen Hinweis auf diesen Dienst in eine kommende Version meines TLS-Kochbuchs auf.

Certificate Pinning mit NGINX

Dieser Artikel beschreibt, was Certificate Pinning ist, wie es TLS/SSL-Verbindungen sicherer macht und wie man es für den Webserver NGINX konfiguriert.

Der Artikel steht in einer PDF-Version zum Download und Druck zur Verfügung: Certificate_Pinning_mit_NGINX

Einleitung

Um zu verstehen, wie Certificate Pinning hilft, TLS/SSL-Verbindungen sicherer zu machen, muss man sich zuerst der Schwachstelle der TLS/SSL-Verschlüsselung bewusst sein.

TLS/SSL-Verbindungen sollen die vertrauliche Kommunikation zwischen zwei Kommunikationspartnern sicherstellen. Bei den Kommunikationspartnern handelt es sich typischerweise um einen Client und einen Server. Die Sicherheit der Vertraulichkeit beruht darauf, dass der Client auch tatsächlich mit dem richtigen Server verbunden ist. Dazu weist sich der Server mit einem Zertifikat aus, welches von einer Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Die Zertifizierungsstelle prüft die Identität des Dienstbetreibers und beglaubigt mit ihrer digitalen Signatur das Zertifikat.

Die c’t schreibt in ihrem Artikel „Festgenagelte Zertifikate“ in Ausgabe Nr. 23 vom 17.10.2015: „Das Problem dabei: Es gibt weit über hundert solcher Zertifizierungsstellen, denen die gängigen Internet-Programme wie Browser und E-Mail-Client vertrauen. Als wäre das nicht unübersichtlich genug, haben die dann auch noch zahllose Unter-CAs, die berechtigt und in der Lage sind, im Namen dieser CAs zu unterschreiben.“1

Das Problem besteht nun nicht in der Anzahl der Zertifizierungsstellen, sondern darin, dass jede dieser Zertifizierungsstellen Zertifikate für beliebige Domains ausstellen darf. So können sich Dritte ein Zertifikat auf eine bereits existierende Domain ausstellen lassen und dieses zum Beispiel für einen Man-In-The-Middle-Angriff (MITM-Angriff) verwenden.

Das genannte Angriffsszenario existiert nicht nur in der Theorie. Wie die c’t berichtet nutzte die chinesische Regierung gefälschte Google-Zertifikate auf ihrer großen Firewall, um den Google-Mail-Verkehr ihrer Bevölkerung überwachen zu können. Darüber hinaus werden weitere Fälle wie der Hack der niederländischen Zertifizierungsstelle DigiNotar und TrustWave aufgeführt.2 Im ersten Fall wurden gefälschte Zertifikate für GMail und Facebook ausgestellt. Im zweiten Fall wurden Zertifikate für Firmen ausgestellt, welche diese Zertifikate nutzten, um den verschlüsselten Internet-Verkehr ihrer Mitarbeiter zu überwachen.

Die Man-In-The-Middle-Angriffe funktionieren, da die Zertifizierungsstellen, welche die gefälschten Zertifikate ausgestellt haben, in der Liste der vertrauenswürdigen Zertifizierungsstellen der gängigen Browser geführt werden. Für den Browser ist damit auch das gefälschte Zertifikat gültig. Der Benutzer kann den MITM-Angriff nicht erkennen und nimmt fälschlicherweise an direkt mit dem gewünschten Server zu kommunizieren.

Um einen MITM-Angriff erkennen zu können, muss der Client überprüfen können, ob das ihm vorliegende Zertifikat von der CA des Dienstbetreibers oder von einer anderen CA ausgestellt wurde. Hier kommt Certificate Pinning ins Spiel.

Certificate Pinning für TLS/SSL

Certificate Pinning wurde im RFC 7469 spezifiziert.3 Es handelt sich dabei um einen Mechanismus, bestimmte Eigenschaften eines Zertifikats festzunageln. Der Browser erhält dabei mit dem Zertifikat zusätzliche Informationen, mit denen er die Authentizität des Zertifikats überprüfen kann.

In der Praxis wird dem Browser ein Hash-Wert übermittelt, welcher über den öffentlichen Schlüssel des Zertifikats gebildet wurde. Dieser Hash-Wert wird in einem HTTP-Header-Field an den Browser übertragen und von diesem gespeichert. Wie dieses Verfahren genau funktioniert, beschreibt der RFC 7469 ab Abschnitt 2.1.14 Da nur der Dienstbetreiber über den dazugehörigen privaten Schlüssel verfügt, ist ein Missbrauch durch Dritte ausgeschlossen. Übermittelt nun nämlich ein Angreifer bei einem MITM-Angriff den zu seinem Zertifikat gehörenden öffentlichen Schlüssel, kann der Browser mit Hilfe des PINs erkennen, dass dieser Schlüssel nicht dem Dienstbetreiber gehört und den Angriff damit auffliegen lassen.

Eine Schwachstelle bleibt jedoch. Damit das beschriebene Verfahren funktioniert, muss die erste Verbindung, die ein Client zum Server aufbaut, integer und vertrauenswürdig sein. Findet bereits beim ersten Verbindungsaufbau ein MITM-Angriff statt, kann der Angreifer einen zu seinem öffentlichen Schlüssel passenden Hash übermitteln und das beschriebene Verfahren damit aushebeln.

Es existiert also ein gewisses Henne-Ei-Problem, welches im folgenden Abschnitt kurz angerissen wird.

TOFU: Trust On First Use

Nein, mit TOFU ist an dieser Stelle kein Nahrungsmittel gemeint. TOFU steht in diesem Kontext für das Trust-On-First-Use-Prinzip, welches die c’t in ihrem Artikel „Zertifikate festnageln“ erläutert.5

Das darin beschriebene Henne-Ei-Problem besteht darin, dass man zuerst eine sichere Verbindung benötigt, um die erforderlichen Informationen zu erhalten, mit denen zukünftige Verbindungen gesichert werden können.

Mittlerweile sollte jedoch bekannt sein, dass es keine hundertprozentige Sicherheit gibt. Damit ist der beschriebene Schutz besser als gar keiner. In der Praxis kann Certificate Pinning daher in sehr vielen Fällen helfen, die Sicherheit vertraulicher Kommunikation zu steigern.

Certificate Pinning auf dem eigenen Server

Dieser Abschnitt beschreibt, wie man Certificate Pinning auf dem eigenen Server konfigurieren kann. Es wird dabei auf notwendige Vorüberlegungen eingegangen und die Berechnung der PINs beschrieben. Im Anschluss wird das Certificate Pinning beispielhaft an einem NGINX-Server demonstriert.

Vorüberlegungen

In den vorangegangenen Abschnitten wurde erläutert, wie Man-In-The-Middle-Angriffe durch Certificate Pinning erheblich erschwert werden können. Nun stellt sich die Frage, welchen öffentlichen Schlüssel man festnageln möchte. Denn Certificate Pinning kann auf jeden öffentlichen Schlüssel der gesamten Zertifizierungskette angewendet werden. So kommen sowohl das eigene Serverzertifikat, als auch das der Intermediate CAs und das der Root CA in Frage.6

Pinnt man den öffentlichen Schlüssel einer Intermediate CA oder gar einer Root CA, so werden alle von diesen Zertifizierungsstellen ausgestellten Zertifikate vom Browser als gültig und sicher akzeptiert. Daher erscheint es am sichersten, wenn man den öffentlichen Schlüssel des eigenen Serverzertifikats festnagelt. Hierbei muss allerdings folgendes Risiko beachtet werden.

Wird der Schlüssel durch Kompromittierung unbrauchbar, oder geht durch Hardwaredefekt verloren, können Benutzer die gesicherten Dienste eventuell nicht mehr nutzen. Denn die Browser haben den Pin gespeichert und werden vor Ablauf der Lebensdauer keinen neuen Pin akzeptieren. Die Lebensdauer kann je nach Konfiguration mehrere Wochen bis Monate betragen.7

Um das im vorigen Absatz beschriebene Risiko zu minimieren definiert RFC 7469 die zusätzliche Verwendung eines Backup-PINs. Dabei wird ein Hash-Wert über den öffentlichen Schlüssel eines Schlüsselpaares gebildet, welches aktuell noch nicht genutzt wird.8 Dies kann zum Beispiel dadurch erreicht werden, dass ein Hash-Wert für den öffentlichen Schlüssel eines Certificate Signing Request (CSR) generiert wird.

Der Backup-Pin wird ebenfalls über ein HTTP-Header-Feld ausgeliefert und vom Browser eines Clients gespeichert. Der erzeugte Backup-CSR sollte sicher offline aufbewahrt werden. Er kann genutzt werden, um ein neues Zertifikat für die entsprechende Domain ausstellen zu lassen. Auf diese Weise können Zertifikate verlängert bzw. erneuert werden, ohne dass der Zugriff auf die entsprechende Domain unterbrochen wird.

Backupstrategie

In diesem Abschnitt wird eine konkrete Backupstrategie für den Backup-Pin beschrieben.

Der für den Backup-Pin verwendete CSR ist sicher aufzubewahren. Denn mit ihm kann ein Zertifikat für eine Domain bzw. einen Host ausgestellt werden, welches von Clients als gültig anerkannt wird, da sie den dazugehörigen Backup-Pin gespeichert haben.

Ich persönlich speichere den CSR und den dazugehörigen privaten Schlüssel in KeePassX9. Auf diese Weise werden die Informationen sicher in einer Datenbank mit einer 256 Bit AES-Verschlüsselung abgelegt. Die KeePassX-Datenbank selbst bewahre ich in einem TeamDrive10-Space auf. Dadurch wird die Datenbank sicher auf meine Endgeräte synchronisiert, so dass die Daten auch bei Ausfall eines Endgeräts erhalten bleiben.

Die lokalen Datenträger der zur TeamDrive-Synchronisation verwendeten Endgeräte sind ebenfalls verschlüsselt. So sind die Daten im Falle eines Diebstahls eines Endgeräts gleich doppelt geschützt. Erstens durch die Verschlüsselung des lokalen Datenträgers und zweitens durch die verschlüsselte KeePassX-Datenbank.

Die PINs berechnen

Die benötigten PINs werden auf der Kommandozeile mit openssl generiert.11 Für ein existierendes SSL-Zertifikat kann der Pin mit folgendem Code erzeugt werden:

openssl x509 -noout -in certificate.pem -pubkey | openssl asn1parse -noout -inform pem -out public.key
openssl dgst -sha256 -binary public.key | openssl enc -base64

Der erzeugte Pin wird auf der Standardausgabe ausgegeben und endet immer auf das Zeichen „=“.

Für den Backup-Pin wird zunächst ein neuer Certificate Signing Request erstellt:

openssl genrsa -out example.com.key 2048
openssl req -new -key example.com.key -out example.com.csr

Über den so erzeugten Certificate Signing Request (example.com.csr) wird nun ebenfalls ein Pin mit folgendem Code erzeugt:

openssl req -noout -in example.com.csr -pubkey | openssl asn1parse -noout -inform pem -out example.com_csr.key
openssl dgst -sha256 -binary example.com_csr.key | openssl enc -base64

Der erzeugte Backup-Pin wird ebenfalls auf der Standardausgabe ausgegeben und muss ebenfalls auf das Zeichen „=“ enden.

Konfiguration von NGINX

Sind die PINs erzeugt, kann anschließend der Webserver konfiguriert werden, diese auszuliefern. Neben der Pin-Direktive12 ist hier die Max-Age-Direktive13 von Bedeutung. Letztere gibt die Zeit in Sekunden an, für die ein Pin durch den Browser gespeichert wird.

Für die ersten Tests sollte die Max-Age-Direktive auf wenige Minuten gesetzt werden. Dieser Wert sollte erst bei reibungslosem Betrieb auf mehrere Wochen erhöht werden.

Das zusätzliche Header-Feld muss im SSL-Block der NGINX-Konfiguration hinzugefügt werden. Dazu wird folgender Code in den SSL-Block eingefügt:

add_header Public-Key-Pins 'pin-sha256="PRIMARY-PIN"; pin-sha256="BACKUP-PIN"; max-age=300; includeSubDomains';

Dabei sind PRIMARY-PIN und BACKUP-PIN durch die entsprechenden PINs zu ersetzen. Die optionale includeSubDomains-Direktive14 gibt an, dass die übermittelten PINs auch für alle Subdomains des Hosts gelten.

Anschließend muss die Konfiguration neue geladen werden, um diese zu aktivieren:

sudo service nginx reload

Fazit

Certificate Pinning ist ein in RFC 7469 spezifizierter Standard, welcher heute bereits von den weit verbreiteten Browsern Chrome und Firefox unterstützt wird. Auch die Konfiguration weit verbreiteter Webserver wie Apache, lighttpd und NGINX ist mit geringem Aufwand, wie hier am Beispiel von NGINX gezeigt, zu erledigen.

Lediglich die sichere Aufbewahrung des Backup-CSR ist sicherzustellen, um eine längere Nichterreichbarkeit einer Domain vermeiden zu können.

Damit ist Certificate Pinning grundsätzlich geeignet, die verschlüsselte Kommunikation im Internet noch sicherer zu machen.

Quellen:

  1. Schmidt, Jürgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, S. 118, Spalte 2-3.
  2. Schmidt, Jürgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, S. 119, Spalte 1.
  3. RFC 7469: Public Key Pinning Extension for HTTP
  4. RFC 7469 Section 2.1. Response Header Field Syntax
  5. Schmidt, Jürgen: Festgenagelte Zertifikate: TLS wird sicherer durch Certificate Pinning, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, S. 121, Kasten „TOFU: Trust On First Use.
  6. Schmidt, Jürgen: Sicher mit Pin: Zertifikats-Pinning auf dem eigenen Server, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, S. 122, Spalte 1.
  7. Schmidt, Jürgen: Sicher mit Pin: Zertifikats-Pinning auf dem eigenen Server, in: c’t magazin für computer technik, Nr. 23, 17.10.2015, S. 122, Spalte 2.
  8. RFC 7469, Abschnitt 4.3. Backup Pins
  9. The Official KeePassX Homepage
  10. TeamDrive Homepage
  11. RFC 7469: Appendix A. Fingerprint Generation
  12. RFC 7469: Abschnitt 2.1.1. The Pin Directive
  13. RFC 7469: Abschnitt 2.1.2. The max-age Directive
  14. RFC 7469: Abschnitt 2.1.3. The includeSubDomains Directive

Logging und logrotate mit NGINX

In diesem Artikel wird beschrieben, wie ich das Logging und logrotate meines NGINX-Servers konfiguriert habe. Dabei gehe ich kurz auf die beiden verwendeten Direktiven error_log und ngx_http_log_module ein.

Damit dient dieser Artikel meiner Dokumentation und evtl. euch als Anregung, ein eigenes Logging zu konfigurieren.

Logging

Informationen zum Logging findet man in der offiziellen NGINX-Dokumentation.1 Im folgenden werden die Direktiven error_log2 und ngx_http_log_module3 verwendet.

Mein Server liefert mehrere Webseiten aus. Ich möchte gern für jede Webanwendung ein separates Error-Log und Access-Log schreiben. Dabei wird folgendes Muster verwendet:

  • Log-Verzeichnis: /var/www//logs
  • Name für error_log: _error.log
  • Name für access_log: _access.log

Konfiguration des Error-Log

Die Error_log-Syntax ist denkbar einfach:

error_log log_file [ log_level ]

log_file gibt den Pfad zur Log-Datei an. Mit log_level wird bestimmt, wie viele Informationen protokolliert werden sollen.

Log-Level4

  • emerg: Notfall, in dem sich das System in einem nicht nutzbaren Zustand befindet
  • alert: Ernste Störung. Sofortiger Eingriff ist erforderlich
  • crit: Kritische Probleme, um die man sich kümmern sollte
  • error: Ein Fehler ist aufgetreten. Hier funktioniert etwas nicht
  • warn: Ein ungewöhnliches Ereignis ist aufgetreten. Dies ist jedoch kein Grund zur Sorge
  • notice: Normale Vorgänge werden ebenfalls protokolliert
  • info: Unnützes Wissen – Nice to know
  • debug: Debugging-Informationen, welche helfen, ein Problem näher zu analysieren

Die Log-Level sind nach Priorität angeordnet. Wird das Level auf „error“ gesetzt, so werden alle Events der Level error, crit, alert und emerg protokolliert.

Möchte man rein gar nichts protokollieren, muss das Log nach /dev/null umgeleitet werden.

error_log /dev/null crit;

Konfiguration des Access-Log

Das Modul ngx_http_log_module besteht aus den Direktiven access_log, log_format und open_log_file_cache, von denen ich hier nur die ersten beiden verwenden werde.

Mit der Direktive log_format kann das Format der Log-Dateien konfiguriert werden. Die einzelnen Formate werden über einen Bezeichner ausgewählt. Dies kann z.B. wie folgt aussehen:

log_format compression '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $bytes_sent '
                       '"$http_referer" "$http_user_agent" "$gzip_ratio"';

access_log /spool/logs/nginx-access.log compression buffer=32k;

Eine detaillierte Beschreibung aller verfügbaren Parameter kann der offiziellen Dokumentation entnommen werden.5

Ich selbst verwende aktuell ausschließlich das Format combined. Dieses ist bereits in der Standardinstallation enthalten. Es sieht wie folgt aus:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Für die Protokollierung meiner Webanwendungen wird daher folgendes in die jeweiligen Server-Direktiven eingetragen:

server {
...
access_log /var/www//logs/_access.log combined;
...
}

Falls man das Access-Log deaktivieren möchte, kann man dies durch den folgenden Eintrag erreichen:

access_log off;

Nun werden schon mal alle Log-Dateien nach Webanwendungen getrennt in das Verzeichnis /var/www//logs geschrieben.

Im nächsten Abschnitt gehe ich darauf ein, wie man verhindert, dass die Festplatte mit Log-Dateien vollgeschrieben wird.

Rotation der NGINX Log-Dateien

Zum Rotieren der Logs verwende ich die Anwendung logrotate. Diese ist bei Ubuntu bereits in der Standardinstallation enthalten.

Es wird ein Skript im Verzeichnis /etc/logrotate.d erstellt und folgender Inhalt eingefügt.

/var/www//logs/*.log {
        daily
        missingok
        rotate 31
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
                [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
        endscript
}

Mit diesem Skript wird logrotate angewiesen, die Log-Dateien im Verzeichnis /var/www//logs/ täglich zu rotieren und die letzten 31 Log-Dateien zu behalten. Die Log-Datei wird nicht rotiert, falls sie leer ist, also keine Einträge enthält. Die älteren Dateien werden dabei komprimiert, um Speicherplatz zu sparen.

Die generelle Beschreibung von logrotate würde den Rahmen dieses Artikels sprengen. Weitere Informationen sind in der Manpage zu finden.6

Damit ist der verspätete Frühjahrsputz auf diesem Server beendet.

SSL-Schwachstelle bedroht Web- und Mail-Server

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.1 2 3

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt „3.“ nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden „Cipher Suites“ und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.

Testinstanz für einen WordPress Blog erstellen

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.1 Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.2

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.3

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.4 Nutzer von Apache können .htaccess-Dateien5 verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. 🙂

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library6 gefunden. Es wird die try_files-Direktive7 verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.