Mittels sslh SSL, SSH und OpenVPN unter Raspbian Jessie Lite auf Port 443 betreiben

sslh erlaubt es mehrere Dienste wie SSL, SSH und OpenVPN gleichzeitig auf Port 443 zu betreiben. Es unterscheidet anhand des Headers beim Aufbau der TLS Verbindung an welchen Dienst die Anfrage weitergeleitet werden muss. Dies ist z.B. nützlich, wenn das WLAN in Hotels oder Cafés nur Verbindungen auf bestimmte Ports erlauben. In diesem Beitrag beschreibe ich wie sslh unter Raspbian installiert und konfiguriert werden kann.

Weiterlesen

Pi-hole unter Raspbian Jessie Lite mit nginx und SSL betreiben

Pi-hole ist ein Werbeblocker auf DNS-Ebene. Das heißt Werbung wird auch geblockt, wenn kein Adblocker verwendet wird, da die anfragen zum Anzeigen der Werbung ins Leere laufen. Im Beitrag Pi-hole unter Raspbian Jessie Lite mit nginx und SSL betreiben habe ich beschreiben wie es unter Raspbian Jessie Lite installiert werden kann.

Pi-hole erlaubt es standardmäßig nicht, dass über SSL auf das Webinterface zugegriffen werden kann. Außerdem verwendet es den lighttpd Webserver. Ich würde die Webseite aber gerne nur über SSL erreichbar machen sowie nginx als Webserver verwenden. In diesem Beitrag beschreibe ich wie nginx installiert und konfiguriert werden kann damit die pi-hole Webseite darüber via SSL erreichbar ist.

Weiterlesen

nginx unter Raspbian Jessie Lite mit sicherer SSL Konfiguration und PHP installieren und konfigurieren

In diesem Beitrag beschreibe ich wie nginx mit einer sicheren SSL Konfiguration und PHP auf Raspbian Jessie installiert und konfiguriert werden kann.

nginx & PHP installieren

Zuerst müssen nginx und PHP mit nachfolgendem Befehl installiert werden.

$ sudo apt-get install nginx php5-fpm

PHP testen

Nun sollte überprüft werden das PHP auch tatsächlich funktioniert. Dazu muss die Konfiguration der nginx Standardseite (/etc/nginx/sites-available/default) angepasst werden. Es müssen vor folgenden Zeilen die Kommentarzeichen entfernt werden.

location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
}

Anschließend muss noch die nginx Konfiguration neu geladen werden, damit die Änderungen wirksam werten. Vorher sollte getestet werden, dass die Konfiguration keine Fehler enthält.

$ sudo /etc/init.d/nginx configtest
[ ok ] Testing nginx configuration:.
$ sudo /etc/init.d/nginx reload
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.

Nun kann einfach eine Datei phpinfo.php mit nachfolgendem Inhalt im Verzeichnis der Standardwebsite (/var/www/html/) angelegt werden.

<?php phpinfo(); ?>

Abschließend kann die Datei einfach über den Webbrowser aufgerufen werden (z.B. über http://example.com/phpinfo.php). Die Ausgabe sollte folgendermaßen aussehen.

Beispielhafte Ausgabe von phpinfo()
Beispielhafte Ausgabe von phpinfo()

nginx Konfigurieren

Nach der Installation muss nginx noch konfiguriert werden. Dies ist etwas aufwendiger als für PHP. Die Hauptkonfigurationsdatei ist /etc/nginx/nginx.conf. Die Konfiguration der einzelnen Seiten befindet sich im Verzeichnis /etc/nginx/sites-available/ und die Konfiguration der aktuell aktivierten Seiten im Verzeichnis /etc/nginx/sites-enabled/.

/etc/nginx/nginx.conf

Schauen wir uns zuerst die Hauptkonfigurationsdatei genauer an.

Zu Beginn werden generelle Parameter festgelegt.

  • user definiert den Linux Benutzer unter dem nginx laufen soll. www-data ist der Standardnutzer unter dem Webserver unter Debian/Ubuntu laufen.
  • worker_processes ist die Anzahl der nginx Prozesse. auto versucht den besten Wert automatisch zu finden.
  • pid ist zur Kommunikation mit dem Betriebssystem und sollte auch bei dem Standardwert (\run\nginx.pid) belassen werden.
  • woker_connections innerhalb von events definiert die maximale Anzahl von Verbindungen pro nginx Prozess (768 ist der Standardwert).
user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {

worker_connections 768;
        # multi_accept on;
}

[...]

Der nächste Block (http) definiert die Parameter für die eigentlichen Verbindungen.

  • Basiseinstellungen
    • sendfile, tcp_nopush und tcp_nodelay erhöhen die Performance von nginx
    • keepalive_timeout definiert die Zeit in Sekunden zu welcher eine Verbindung vom Webserver geschlossen wird. Danach muss eine neue TCP und TLS Verbindung aufgebaut werden.
    • types_hash_max_size beschleunigt hashtable lookups
    • server_tokens gibt an ob nginx seine Version als Antwort mitsenden soll oder nicht
    • include /etc/nginx/mime.types lädt die mime Typen
    • defaul_type setzt den zu verwendenden Standardtyp
  • SSL (Die hier verwendeten Parameter orientieren sich an dem Beitrag Strong SSL Security on nginx)
    • ssl_protocols erlaubt nur TLS in Version 1.0, 1.1 oder 1.2.
    • ssl_ciphers erlaubt nur Algorithmen mit Perfect Forward Security. Das bedeutet, dass auch wenn später der Private Key kompromittiert wurde die alten Verbindungen nicht entschlüsselt werden können.
    • ssl_prefer_server_ciphers sagt das die Algorithmenpreferenz des Servers und nicht des Clients verwendet werden soll.
    • ssl_session_cache definiert, dass es einen 10 MB Cache gibt in welchem Verbindungsinformationen zwischengespeichert werden. Dies erlaubt es bei Wiederaufnahme einer Verbindung einige Schritte im Verbindungsaufbau zu sparen.
    • ssl_dhparam verweist auf selbst generierte EECDH/EDH Parameter welche verwendet werden sollen. Sie sind länger als die Standardmäßig verwendeten Parameter. Wie diese generiert werden beschreibe ich weiter unten.
    • ssl_stapling und ssl_stapling_verify sagt das der Server Informationen über die Gültigkeit des Zertifikates überprüfen und beim Verbindungsaufbau an den Client schicken soll.
    • ssl_ecdh_curve spezifiziert die Kurve welche für ECDHE verwendet werden soll. Die hier angegebene Kurve verwendet längere Schlüssel als die standardmäßig verwendete.
    • ssl_session_tickets deaktiviert Session Tickets, da diese Forward Security aushebeln können.
  • Header
    • add_header X-Content-Type-Options verbietet mime-sniff in Chrome und Internet Explorer
    • add_header X-Frame-Options verbietet es die Website auf einer anderen Domain in einem frame oder iframe zu laden.
  • Logging
    • access_log legt fest in welcher Datei alle Zugriffe geloggt werden sollen
    • error_log legt fest in welcher Datei alle Fehlermeldungen geloggt werden sollen
  • Gzip
    • gzip setzt ob gzip aktiviert werden soll oder nicht. Da all meine Webseiten nur per TLS erreichbar sind und gzip mit TLS ein Sicherheitsrisiko darstellt habe ich es deaktiviert.
  • Vitual Host Konfigurationen
    • Lädt zusätzliche Konfigurationsdateien aus dem Unterordner conf.d sowie die aktiven Seiten im Unterordner sites-enabled.
[...]

http {

        ##
        # Basic Settings
        ##

        sendfile                      on;
        tcp_nopush                    on;
        tcp_nodelay                   on;
        keepalive_timeout             65;
        types_hash_max_size           2048;
        server_tokens                 off;

        include         /etc/nginx/mime.types;
        default_type    application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers                     'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        ssl_prefer_server_ciphers       on;
        ssl_session_cache               shared:SSL:10m;
        ssl_dhparam                     /etc/ssl/certs/dhparam.pem;
        ssl_stapling                    on;
        ssl_stapling_verify             on;
        ssl_ecdh_curve                  secp384r1;
        ssl_session_tickets             off;

        ##
        # Header
        ##

        add_header X-Content-Type-Options       nosniff;
        add_header X-Frame-Options              "SAMEORIGIN";

        ##
        # Logging Settings
        ##

        access_log      /var/log/nginx/access.log;
        error_log       /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip    off;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

dhparam generieren

Da ich längere Parameter verwenden möchte als die Standardkonfiguration müssen die dhparam selber generiert werden. Dies kann wie nachfolgend beschrieben im Terminal erledigt werden – es kann einige Stunden dauern bis der Befehl zum Generieren erfolgreich ausgeführt wurde.

$ cd /etc/ssl/certs
$ sudo openssl dhparam -out dhparam.pem 4096

Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
 ........................................................................................................................................................................................................................................................................................................................+......................................................................................................................................................................................................+.............................................................................+..........................................................................................................................................................................................................................................................+...............................................................................................................+......................+..........................................+......................................................................................................................................+......................................+................................+........................................+........................................................................................+...............................................+..............................................................................................................................+..........................................................................+.................................................................................+........+......................................................+...................................................................................................................................................................................................+................+................................................+.............................................................+....................................................................................................................+...............................................+...................................................................................................................................................................................................................................................+......................

[...]

Konfiguration für eine neue Seite erstellen

Die Konfigurationsdateien der einzelnen Seiten befinden sich im Verzeichnis /etc/nginx/sites-available/. Ich verwende immer nachfolgendes Template als Basis für meine PHP-Seiten. Die Konfiguration leitet HTTP Verbindungen automatisch auf verschlüsselte HTTPS Verbindungen um. Parameter wie der Domainname, Pfad zum SSL-Zertifikat und das Verzeichnis müssen natürlich für jede Website angepasst werden.

Die Konfiguration besteht aus zwei server Blöcken. Einer für Port 80 (HTTP) und einer für Port 443 (HTTPS).

Die Konfiguration des ersten server Blocks (HTTP)

  • listen gibt an auf welchen IP-Adressen und Ports die Website reagieren soll. 80 sagt aus, dass über alle verfügbaren IPv4 Adressen Verbindungen auf Port 80 akzeptiert werden sollen. [xxx:xxx:xxx::42]:80 sagt aus, dass die Website via IPv6 nur über die IP-Adresse xxx:xxx:xxx::42 und Port 80 erreichbar ist. Falls die Konfiguration als Standard verwendet werden soll, falls keine andere zur Anfrage passt, muss jeweils hinter der 80 noch default_server ergänzt werden.
  • server_name gibt die Domain an, für welche die Konfiguration gilt.
  • return leitet auf eine andere Website weiter. In diesem Fall mittels 301 (Dauerhaft Verschoben) auf die verschlüsselte Verbindung (HTTPS).

Die Konfiguration des zweiten Blocks (HTTPS). Die Pfade zum SSL Zertifikat bzw. dem zugehörigen privaten Schlüssel entsprechen denen, wenn Let’s Encrypt mit certbot verwendet wird. Wie dies Konfiguriert wird habe ich im Beitrag Let’s Encrypt SSL Zertifikate unter Raspbian Jessie Lite mittels nginx und webroot Plugin beziehen beschrieben.

  • listen ist identisch wie für den ersten Block außer das der Block auf Port 443 hört und nicht 80.
  • server_name gibt wie beim ersten Block die Domain an, für welche die Konfiguration gilt.
  • ssl_certificate gibt den Pfad zum SSL Zertifikat der Website an.
  • ssl_certificate_key gibt den Pfad zum Privaten Schlüssel des SSL Zertifikats der Website an.
  • add_header Strict-Transport-Security sagt dem Client, dass er die Website nur über HTTPS aufrufen soll und dies auch für alle Subdomains gilt. An dieser Stelle muss man vorsichtig sein und prüfen ob dies auch wirklich für alle Subdomains gilt. Außerdem sagt max-age für wie lange diese Einstellung gilt. Innerhalb dieser Zeit leitet der Browser den Besucher automatisch auf HTTPS weiter. Das heißt es ist nicht einfach möglich HTTPS abzuschalten, sondern benötigt eine Vorlaufzeit. Der Wert 63072000 entspricht 2 Jahren. Zum Testen sollte ein niedriger Wert wie z.B. 300 (5 Minuten) verwendet werden, welcher langsam erhöht wird. Es kann auch beantragt werden diese Einstellung fest in die gängigsten Browser aufzunehmen. Details dazu gibt es auf der Website der HTST Preload List.
  • root gibt das Verzeichnis an, in dem die Website liegt.
  • index gibt den Dateinamen der Datei an, welche angezeigt werden soll, falls ein Verzeichnis als URL angegeben wurde. Damit dies geschieht muss eine Datei mit diesem Namen in dem angefragten Verzeichnis vorhanden sein.
  • location \ sagt, dass zuerst nach einer Datei mit dem angefragten Namen gesucht werden soll, anschließend ob ein Verzeichnis mit dem Namen existiert. Falls beides nicht existiert wird ein 404 Fehler zurückgegeben.
  • location ~ \.php$ leitet PHP-Dateien an den Interpreter weiter.
  • include snippets/certbot-webroot.conf lädt die Konfigurationsparameter zur Aktualisierung der Let’s Encrypt Zertifikate wie im Beitrag Let’s Encrypt SSL Zertifikate unter Raspbian Jessie Lite mittels nginx und webroot Plugin beziehen beschrieben.
server  {
        listen          80;
        listen          [xxx:xxx:xxx::42]:80;

        server_name     example.com;
        return          301 https://$server_name$request_uri;
}

server  {
        listen          443 ssl;
        listen          [xxx:xxx:xxx::42]:443 ssl;

        server_name     example.com;

        ssl_certificate         /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;
        add_header              Strict-Transport-Security "max-age=63072000; includeSubdomains;";

        root    /var/www/com.example;

        index   index.php;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass the PHP scripts to FastCGI server
        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
        }

        # snippet for updating letsencrypt certificates
        include snippets/certbot-webroot.conf;
}

Nun muss noch das Verzeichnis für die Webseitendaten erstellt werden.

$ sudo mkdir -p /var/www/com.example

Neue Seite aktivieren

Um die Konfiguration einer Seite im Verzeichnis /etc/nginx/sites-available/ zu aktivieren muss ein Symmetrischer Link zu dieser Datei im Verzeichnis /etc/nginx/sites-enabled angelegt werden.

$ sudo ln -s /etc/nginx/sites-available/com.example /etc/nginx/sites-enabled/

Konfiguration übernehmen

Nachdem die Konfiguration wie oben beschrieben geändert wurde muss sie nur noch von nginx neu geladen werden. Bevor sie geladen wird sollte allerdings noch geprüft werden, ob sie Fehler enthält.

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo /etc/init.d/nginx reload
[ ok ] Restarting nginx (via systemctl): nginx.service.

Nun kann noch die Seite des Qually Labs SSL Tests aufgerufen werden, welches die verwendete Sicherheitsverfahren und Algorithmen von Webservern prüft und bewertet. Wenn alles wie oben beschrieben konfiguriert wurde sollte die Bewertung A+ sein, was der Best möglichen Bewertung entspricht.

Ergebnis des Qualys SSL Labs SSL Server Test
Ergebnis des Qualys SSL Labs SSL Server Test

Let’s Encrypt SSL Zertifikate für Dienste ohne Website wie postfix oder dovecot unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen

Im Beitrag Let’s Encrypt SSL Zertifikate unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen habe ich beschrieben, wie es mithilfe des certbot Tools möglich ist SSL Zertifikate von Let’s Encrypt über nginx und das webroot Plugin zu beziehen. Dieser Mechanismus funktioniert aber nur für Webseiten. Für Dienste, welche keine Webseite über nginx bereitstellen ist dieses Verfahren nicht geeignet. Mit einer leichten Modifikation können aber auch SSL Zertifikate für Dienste ohne Webseiten wie postfix oder dovecot bezogen werden. In diesem Beitrag beschreibe ich die notwendigen Anpassungen dafür.

Weiterlesen

HTTP Anfragen mittels nginx automatisch auf HTTPS weiterleiten

In diesem Beitrag beschreibe ich wie mittels nginx Anfragen auf Port 80 (HTTP) automatisch auf verschlüsselte Verbindungen auf Port 443 (HTTPS) weiterleiten werden können.

Um die Weiterleitung zu ermöglichen muss die Konfiguration der Website aus zwei server Blöcken bestehen. Einen für HTTP (Port 80) und einen für HTTPS Verbindungen (Port 443). Die nachfolgende Konfiguration leitet mittels dem return Parameter alle Anfragen inklusive der angefragten URI an Port 80 auf die HTTPS Verbindung der Website weiter.

server  {
        listen          80;
        listen          [xxx:xxx:xxx::42]:80;

        server_name     example.com;
        return          301 https://$server_name$request_uri;
}

server  {
        listen          443 ssl;
        listen          [xxx:xxx:xxx::42]:443 ssl;

        server_name     example.com;

[...]

}

In dem Artikel nginx unter Ubuntu Linux 16.04 Server mit sicherer SSL Konfiguration, PHP und MariaDB oder MySQL installieren und konfigurieren beschreibe ich meine Standardkonfiguration für neue Seiten. Diese enthält auch die hier beschriebene automatische Weiterleitung von HTTP auf HTTPS Verbindungen.

Piwik Tracking-Code in WordPress einfügen

Piwik ist eine Open Source alternative zu Google Analytics, welches Webseitenaufrufe statistisch auswertet. Wie Piwik unter Ubuntu 16.04 mit nginx und MariaDB/MySQL installiert werden kann habe ich im Beitrag Piwik unter Ubuntu Linux 16.04 Server mit nginx und MariaDB/MySQL installieren und konfigurieren beschrieben. Um die Webseitenaufrufe zu Tracken muss ein Tracking-Code in die Website eingefügt werden. In diesem Beitrag beschreibe ich wie dies für WordPress erledigt werden kann.

Der Piwik Tracking-Code sollte im Header oder Footer der zu Trackenden Website eingefügt werden. In WordPress kann daher einfach die header.php oder footer.php bearbeitet werden um den Tracking-Code einzubauen. Dies hat aber den Nachteil, dass diese Änderungen nach jedem Update des Themes erneut gemacht werden müssen. Mit einem Child-Theme könnte dies umgangen werden. Jedoch ist einiges an Arbeit nötig um ein Child-Theme zu erstellen. Deshalb habe ich mich entschieden das Plugin WP-Piwik zu verwenden, welches den Tracking-Code automatisch in die Website einbaut. Es kann so konfiguriert werden, dass gewisse Benutzergruppen wie Administratoren von dem Tracking ausgenommen werden. Das Plugin kann außerdem dazu genutzt werden, die Piwik Statistiken direkt im WordPress Dashboard anzuzeigen. Ich gehe hier davon aus, dass in Piwik bereits eine Seite mit der Domain des Blogs estellt wurde. Falls noch keine Seite angelegt wurde kann die Anleitung im Beitrag Bei Piwik eine neue Website hinzufügen verwendet werden.

Installation

Das Plugin WP-Piwik kann einfach  im WordPress Administrationsbereich über die Pluginseite (1) zum Installieren (2) gesucht (3) und anschließend installiert (4) werden (Alternativ kann es von der WordPress.org Plugin-Seite heruntergeladen und manuell installiert werden).

WP-Piwik installieren
WP-Piwik installieren

Anschließend kann es direkt über die gleiche Seite aktiviert werden.

WP-Piwik aktivieren
WP-Piwik aktivieren

Konfiguration

Bevor WP-Piwik konfiguriert werden kann muss der Wert des token_auth herausgefunden werden. Dieser wird von dem Plugin benötigt um sich mit Piwik zu verbinden. Er wird in Piwik im Administrationsbereich (1) unter API (2) angezeigt. Es werden aus Sicherheitsgründen nur die ersten 6 Zeichen angezeigt. Mit einem Klick auf die Zeile (3) werden aber alle Zeichen angezeigt und sie können kopiert werden.

Piwik token_auth beziehen
Piwik token_auth beziehen

In die WP-Piwik Einstellungen gelangt man im WordPress Administrationsbereich über Einstellungen (1) WP-Piwik (2). Dort muss zuerst der Piwik-Modus ausgewählt werden. Dies ist für uns „Selbst-gehostet (HTTP API, Standard). Unter Piwik URL muss die Website unter welcher Piwik erreichbar ist eingegeben werden (am besten direkt mit https). Anschließend muss unter Auth-Token der token_auth, welchen wir uns im letzten Schritt kopiert haben eingefügt werden. Anschließend kann die Verbindung zu Piwik mit einem Klick auf „Änderungen übernehmen“ hergestellt werden.

WP-Piwik Einstellungen - Mit Piwik verbinden
WP-Piwik Einstellungen – Mit Piwik verbinden

Nachdem WP-Piwik mit Piwik verbunden ist kann das Tracking über „Tracking aktivieren“ aktiviert werden (1). Dazu sollte bei Tracking-Code einfügen „Standard-Tracking“ ausgewählt werden (2). Für die Position des JavaScript-Codes sollte der Header (3) ausgewählt werden. Zusätzlich kann ein Tracking-Filter gesetzt werden. Dieser erlaubt es z.B. die Seitenaufrufe von Administratoren nicht zu tracken (4). Abschließend können diese Einstellungen mit einem Klick auf „Änderungen übernehmen“ gespeichert werden.

WP-Piwik Einstellungen - Tracking aktivieren
WP-Piwik Einstellungen – Tracking aktivieren

Abschließend habe ich in der „Experten-Konfiguration“ (1) noch aktiviert, dass immer HTTPS/SSL verwendet werden soll (2). Dies muss auch mit einem Klick auf „Änderungen übernehmen“ (3) gespeichert werden.

WP-Piwik Einstellungen - Experten-Konfiguration
WP-Piwik Einstellungen – Experten-Konfiguration

Nun werden die Aufrufe des Blogs über Piwik unter der Verwendung von HTTPS/SSL getrackt, wobei die Seitenaufrufe der Administratoren ausgenommen sind.

nginx unter Ubuntu Linux 16.04 Server mit sicherer SSL Konfiguration, PHP und MariaDB oder MySQL installieren und konfigurieren

In diesem Beitrag beschreibe ich wie unter Ubuntu Linux 16.04 Server ein nginx Webserver mit sicherer SSL Konfiguration, PHP und MariaDB oder MySQL Unterstützung installiert und konfiguriert werden kann.

Installation

nginx

nginx ist in den offiziellen Paketquellen von Ubuntu 16.04 vorhanden und kann somit einfach über apt-get installiert werden.

$ sudo apt-get install nginx

PHP

PHP kann auch einfach über die offiziellen Paketquellen installiert werden.

$ sudo apt-get install php-fpm

MariaDB / MySQL

Wie ein MariaDB bzw. MySQL Server installiert und konfiguriert werden kann habe ich im Beitrag MySQL oder MariaDB unter Ubuntu Linux 16.04 installieren und konfigurieren beschrieben. Hier geht es darum PHP eine Verbindung zur Datenbank zu ermöglichen. Dazu kann einfach das entsprechende Paket aus den offiziellen Paketquellen installiert werden.

$ sudo apt-get install php-mysql

Konfiguration

PHP & MariaDB bzw. MySQL

PHP und MariaDB bzw. MySQL kann einfach zusammen konfiguriert werden. Für PHP muss die Datei /etc/php/7.0/fpm/php.ini angepasst werden. Dabei sollte folgende Zeile auskommentiert und der Wert auf 0 gesetzt werden.

[...]
cgi.fix_pathinfo=0
[...]

Anschließend muss php-fpm noch neu geladen werden – dies aktiviert auch die MySQL Unterstützung.

$ sudo /etc/init.d/php7.0-fpm reload
[ ok ] Reloading php7.0-fpm configuration (via systemctl): php7.0-fpm.service.

Damit sollte PHP mit MariaDB bzw. MySQL Unterstützung funktionieren.

PHP testen

Nun sollte kurz getestet werden das PHP auch tatsächlich funktioniert. Dazu muss zunächst die Konfiguration der nginx Standardseite (/etc/nginx/sites-available/default) angepasst werden. Es müssen vor folgenden Zeilen die Kommentarzeichen entfernt werden.

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

Anschließend muss noch die nginx Konfiguration neu geladen werden, damit die Änderungen wirksam werten. Vorher sollte getestet werden, dass die Konfiguration keine Fehler enthält.

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo /etc/init.d/nginx reload
[ ok ] Reloading nginx configuration (via systemctl): nginx.service.

Nun kann einfach eine Datei phpinfo.php mit nachfolgendem Inhalt im Verzeichnis der Standardwebsite (/var/www/html/) angelegt werden.

&amp;lt;?php phpinfo(); ?&amp;gt;

Abschließend kann die Datei einfach über den Webbrowser aufgerufen werden (z.B. über http://example.com/phpinfo.php). Die Ausgabe sollte folgendermaßen aussehen.

Beispielhafte Ausgabe von phpinfo()
Beispielhafte Ausgabe von phpinfo()

nginx

Nach der Installation muss nginx noch konfiguriert werden. Dies ist etwas aufwendiger als für PHP oder MySQL. Die Hauptkonfigurationsdatei ist /etc/nginx/nginx.conf. Die Konfiguration der einzelnen Seiten befindet sich im Verzeichnis /etc/nginx/sites-available/ und die Konfiguration der aktuell aktivierten Seiten im Verzeichnis /etc/nginx/sites-enabled/.

/etc/nginx/nginx.conf

Schauen wir uns zuerst die Hauptkonfigurationsdatei genauer an.

Zu Beginn werden generelle Parameter festgelegt.

  • user definiert den Linux Benutzer unter dem nginx laufen soll. www-data ist der Standardnutzer unter dem Webserver unter Debian/Ubuntu laufen.
  • worker_processes ist die Anzahl der nginx Prozesse. auto versucht den besten Wert automatisch zu finden.
  • pid ist zur Kommunikation mit dem Betriebssystem und sollte auch bei dem Standardwert (\run\nginx.pid) belassen werden.
  • woker_connections innerhalb von events definiert die maximale Anzahl von Verbindungen pro nginx Prozess (768 ist der Standardwert).
user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {

worker_connections 768;
# multi_accept on;
}

[...]

Der nächste Block (http) definiert die Parameter für die eigentlichen Verbindungen.

  • Basiseinstellungen
    • sendfile, tcp_nopush und tcp_nodelay erhöhen die Performance von nginx
    • keepalive_timeout definiert die Zeit in Sekunden zu welcher eine Verbindung vom Webserver geschlossen wird. Danach muss eine neue TCP und TLS Verbindung aufgebaut werden.
    • types_hash_max_size beschleunigt hashtable lookups
    • server_tokens gibt an ob nginx seine Version als Antwort mitsenden soll oder nicht
    • include /etc/nginx/mime.types lädt die mime Typen
    • defaul_type setzt den zu verwendenden Standardtyp
  • SSL (Die hier verwendeten Parameter orientieren sich an dem Beitrag Strong SSL Security on nginx)
    • ssl_protocols erlaubt nur TLS in Version 1.0, 1.1 oder 1.2.
    • ssl_ciphers erlaubt nur Algorithmen mit Perfect Forward Security. Das bedeutet, dass auch wenn später der Private Key kompromittiert wurde die alten Verbindungen nicht entschlüsselt werden können.
    • ssl_prefer_server_ciphers sagt das die Algorithmenpreferenz des Servers und nicht des Clients verwendet werden soll.
    • ssl_session_cache definiert, dass es einen 10 MB Cache gibt in welchem Verbindungsinformationen zwischengespeichert werden. Dies erlaubt es bei Wiederaufnahme einer Verbindung einige Schritte im Verbindungsaufbau zu sparen.
    • ssl_dhparam verweist auf selbst generierte EECDH/EDH Parameter welche verwendet werden sollen. Sie sind länger als die Standardmäßig verwendeten Parameter. Wie diese generiert werden beschreibe ich weiter unten.
    • ssl_stapling und ssl_stapling_verify sagt das der Server Informationen über die Gültigkeit des Zertifikates überprüfen und beim Verbindungsaufbau an den Client schicken soll.
    • ssl_ecdh_curve spezifiziert die Kurve welche für ECDHE verwendet werden soll. Die hier angegebene Kurve verwendet längere Schlüssel als die standardmäßig verwendete.
    • ssl_session_tickets deaktiviert Session Tickets, da diese Forward Security aushebeln können.
  • Header
    • add_header X-Content-Type-Options verbietet mime-sniff in Chrome und Internet Explorer
    • add_header X-Frame-Options verbietet es die Website auf einer anderen Domain in einem frame oder iframe zu laden.
  • Logging
    • access_log legt fest in welcher Datei alle Zugriffe geloggt werden sollen
    • error_log legt fest in welcher Datei alle Fehlermeldungen geloggt werden sollen
  • Gzip
    • gzip setzt ob gzip aktiviert werden soll oder nicht. Da all meine Webseiten nur per TLS erreichbar sind und gzip mit TLS ein Sicherheitsrisiko darstellt habe ich es deaktiviert.
  • Vitual Host Konfigurationen
    • Lädt zusätzliche Konfigurationsdateien aus dem Unterordner conf.d sowie die aktiven Seiten im Unterordner sites-enabled.
[...]

http {

##
# Basic Settings
##

sendfile                on;
tcp_nopush              on;
tcp_nodelay             on;
keepalive_timeout       65;
types_hash_max_size     2048;
server_tokens           off;

include         /etc/nginx/mime.types;
default_type    application/octet-stream;

##
# SSL Settings
##

ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                     'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers       on;
ssl_session_cache               shared:SSL:10m;
ssl_dhparam                     /etc/ssl/certs/dhparam.pem;
ssl_stapling                    on;
ssl_stapling_verify             on;
ssl_ecdh_curve                  secp384r1;
ssl_session_tickets             off;

##
# Header
##

add_header X-Content-Type-Options       nosniff;
add_header X-Frame-Options              "SAMEORIGIN";

##
# Logging Settings
##

access_log      /var/log/nginx/access.log;
error_log       /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip    off;

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

dhparam generieren

Da ich längere Parameter verwenden möchte als die Standardkonfiguration müssen die dhparam selber generiert werden. Dies kann wie nachfolgend beschrieben im Terminal erledigt werden – es kann einige Minuten dauern bis der Befehl zum Generieren erfolgreich ausgeführt wurde.

$ cd /etc/ssl/certs
$ sudo openssl dhparam -out dhparam.pem 4096

Generating DH parameters, 4096 bit long safe prime, generator 2
This is going to take a long time
 ......................................................................+.................................................................................................................................................................................................................................................................................................................+.......................................................................................+........................+............................................................................................+........................+........................................................................................................................................................................................................................................................................................................................+...................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................+.........................................................................................................................................+..............................................................+....................................................................................................................................................+................................................................................................................................................................................................................................................................................................................................................................................................................................................................+...............................................................................................................................................+....

[...]

Konfiguration für eine neue Seite erstellen

Die Konfigurationsdateien der einzelnen Seiten befinden sich im Verzeichnis /etc/nginx/sites-available/. Ich verwende immer nachfolgendes Template als Basis für meine PHP-Seiten. Die Konfiguration leitet HTTP Verbindungen automatisch auf verschlüsselte HTTPS Verbindungen um. Parameter wie der Domainname, Pfad zum SSL-Zertifikat und das Verzeichnis müssen natürlich für jede Website angepasst werden.

Die Konfiguration besteht aus zwei server Blöcken. Einer für Port 80 (HTTP) und einer für Port 443 (HTTPS).

Die Konfiguration des ersten server Blocks (HTTP)

  • listen gibt an auf welchen IP-Adressen und Ports die Website reagieren soll. 80 sagt aus, dass über alle verfügbaren IPv4 Adressen Verbindungen auf Port 80 akzeptiert werden sollen. [xxx:xxx:xxx::42]:80 sagt aus, dass die Website via IPv6 nur über die IP-Adresse xxx:xxx:xxx::42 und Port 80 erreichbar ist. Falls die Konfiguration als Standard verwendet werden soll, falls keine andere zur Anfrage passt, muss jeweils hinter der 80 noch default_server ergänzt werden.
  • server_name gibt die Domain an, für welche die Konfiguration gilt.
  • return leitet auf eine andere Website weiter. In diesem Fall mittels 301 (Dauerhaft Verschoben) auf die verschlüsselte Verbindung (HTTPS).

Die Konfiguration des zweiten Blocks (HTTPS). Die Pfade zum SSL Zertifikat bzw. dem zugehörigen privaten Schlüssel entsprechen denen, wenn Let’s Encrypt mit certbot verwendet wird. Wie dies Konfiguriert wird habe ich im Beitrag Let’s Encrypt SSL Zertifikate unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen beschrieben.

  • listen ist identisch wie für den ersten Block außer das der Block auf Port 443 hört und nicht 80.
  • server_name gibt wie beim ersten Block die Domain an, für welche die Konfiguration gilt.
  • ssl_certificate gibt den Pfad zum SSL Zertifikat der Website an.
  • ssl_certificate_key gibt den Pfad zum Privaten Schlüssel des SSL Zertifikats der Website an.
  • add_header Strict-Transport-Security sagt dem Client, dass er die Website nur über HTTPS aufrufen soll und dies auch für alle Subdomains gilt. An dieser Stelle muss man vorsichtig sein und prüfen ob dies auch wirklich für alle Subdomains gilt. Außerdem sagt max-age für wie lange diese Einstellung gilt. Innerhalb dieser Zeit leitet der Browser den Besucher automatisch auf HTTPS weiter. Das heißt es ist nicht einfach möglich HTTPS abzuschalten, sondern benötigt eine Vorlaufzeit. Der Wert 63072000 entspricht 2 Jahren. Zum Testen sollte ein niedriger Wert wie z.B. 300 (5 Minuten) verwendet werden, welcher langsam erhöht wird. Es kann auch beantragt werden diese Einstellung fest in die gängigsten Browser aufzunehmen. Details dazu gibt es auf der Website der HTST Preload List.
  • root gibt das Verzeichnis an, in dem die Website liegt.
  • index gibt den Dateinamen der Datei an, welche angezeigt werden soll, falls ein Verzeichnis als URL angegeben wurde. Damit dies geschieht muss eine Datei mit diesem Namen in dem angefragten Verzeichnis vorhanden sein.
  • location \ sagt, dass zuerst nach einer Datei mit dem angefragten Namen gesucht werden soll, anschließend ob ein Verzeichnis mit dem Namen existiert. Falls beides nicht existiert wird ein 404 Fehler zurückgegeben.
  • location ~ \.php$ leitet PHP-Dateien an den Interpreter weiter.
  • include snippets/certbot-webroot.conf lädt die Konfigurationsparameter zur Aktualisierung der Let’s Encrypt Zertifikate wie im Beitrag Let’s Encrypt SSL Zertifikate unter Ubuntu Linux 16.04 Server mittels nginx und webroot Plugin beziehen beschrieben.
server  {
listen          80;
listen          [xxx:xxx:xxx::42]:80;

server_name     example.com;
return          301 https://$server_name$request_uri;
}

server  {
listen          443 ssl;
listen          [xxx:xxx:xxx::42]:443 ssl;

server_name     example.com;

ssl_certificate         /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;
add_header              Strict-Transport-Security "max-age=63072000; includeSubdomains;";

root    /var/www/com.example;

index   index.php;

location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}

# pass the PHP scripts to FastCGI server
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

# snippet for updating letsencrypt certificates
include snippets/certbot-webroot.conf;
}

Nun muss noch das Verzeichnis für die Webseitendaten erstellt werden.

$ sudo mkdir -p /var/www/com.example

Neue Seite aktivieren

Um die Konfiguration einer Seite im Verzeichnis /etc/nginx/sites-available/ zu aktivieren muss ein Symmetrischer Link zu dieser Datei im Verzeichnis /etc/nginx/sites-enabled angelegt werden.

$ sudo ln -s /etc/nginx/sites-available/com.example /etc/nginx/sites-enabled/

Konfiguration übernehmen

Nachdem die Konfiguration wie oben beschrieben geändert wurde muss sie nur noch von nginx neu geladen werden. Bevor sie geladen wird sollte allerdings noch geprüft werden, ob sie Fehler enthält.

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo /etc/init.d/nginx reload
[ ok ] Restarting nginx (via systemctl): nginx.service.

Nun kann noch die Seite des Qually Labs SSL Tests aufgerufen werden, welches die verwendete Sicherheitsverfahren und Algorithmen von Webservern prüft und bewertet. Wenn alles wie oben beschrieben konfiguriert wurde sollte die Bewertung A+ sein, was der Best möglichen Bewertung entspricht.

Ergebnis des Qualys SSL Labs SSL Server Test
Ergebnis des Qualys SSL Labs SSL Server Test