Schlagwort: nginx

HTTP-Header-Hardening

Ich bin immer dabei, Ausschau zu halten wie man das Web, oder zumindest ich meine Seiten, sicherer gestalten kann. Dabei bin ich heute auf den folgenden Test aufmerksam geworden:

https://securityheaders.io/

Von einem anfänglichen D bin ich inzwischen auf ein A gekommen, die PKP-Laufzeit will ich wegen der recht kurzen Gültigkeit der LetsEncrypt Zertifikate aber aktuell nicht höher als eine Woche ansetzen:

Sehr viele Tipps und super Beschreibungen gibt es in diesem Blogbeitrag:

https://scotthelme.co.uk/hardening-your-http-response-headers/

Vielen Dank von meiner Seite für die dortigen Beiträge, der Blog kommt mit in meine beobachteten Seiten.

Der Vollständigkeit halber hier mal meine auf dem nginx gesetzten Headers:

### Secure Headers ###
add_header      Strict-Transport-Security       "max-age=31536000; includeSubDomains; preload" always;
add_header      Public-Key-Pins                 'pin-sha256="HkAH1iFqrQ902FeSM8bcR5g1Vhmjs7DZf36qBYnsHxk="; pin-sha256="fseSS72aNBsbopCJnqT/rkFjFhOm+F6fiQ5KwYryXaI="; max-age=604800; includeSubDomains' always;
add_header      X-Xss-Protection                "1; mode=block" always;
add_header      X-Frame-Options                 "SAMEORIGIN" always;
add_header      X-Content-Type-Options          "nosniff" always;
add_header      Referrer-Policy                 "strict-origin-when-cross-origin" always;
add_header      Content-Security-Policy         "default-src https: data: 'unsafe-inline' 'unsafe-eval'" always;

(Stand: 12.04.2017)

Unerwähnt sollte natürlich nicht der Test von SSL Labs bleiben, hier kann man sehr gut seine Cipher-Einstellungen und Browser-Kompatiblität testen:

Settings hierzu:

### Add SSL specific settings here ###
ssl_protocols                   TLSv1.2 TLSv1.1 TLSv1;
ssl_ciphers                     'EECDH+AESGCM EDH+AESGCM EECDH EDH !NULL !aNULL !eNULL !EXPORT !LOW !MEDIUM !DES !3DES !RC4 !SEED !CAMELLIA !MD5 !PSK !DSS !ECDSA';
ssl_prefer_server_ciphers       on;
ssl_dhparam                     /etc/nginx/dh2048.pem;
ssl_stapling                    on;
ssl_stapling_verify             on;
ssl_trusted_certificate         /etc/letsencrypt/live/blog.2-cpu.de/chain.pem;
ssl_session_timeout             10m;
ssl_session_cache               shared:SSL:10m;
ssl_session_tickets             on;
ssl_session_ticket_key          /etc/nginx/nginx_ticketkey;

(Stand: 12.04.2017)

Wenn jemand Probleme bei meiner Seite bemerkt freue ich mich über jedes Feedback 🙂

 

WordPress, nginx, htaccess, Plesk…

Ich teste derzeit das eine oder andere Hosting-System, so natürlich auch Plesk.

Bisher gefällt mit das System sehr gut und die Preise sind auch in Ordnung.

Angenehm finde ich die Möglichkeiten, für einzelne vServer unterschiedliche PHP Versionen zu nutzen und auch ein nginx als Proxy vorzuschalten.

Allerdings gibt es genau hier ein Problem in Verbindung mit WordPress:
Nutzt man Permelinks, funktionieren diese nicht. Die .htaccess Datei, welche der Apache nutzen würde, wird von dem nginx nicht ausgewertet wenn dieser als PHP Interpreter genutzt wird.

Ein Workaround für WordPress ist es, für alle vServer die Direktiven zu ändern, was für mich einfach keine Option ist, da es hier nur um einen Bruchteil aller Sites, auf dem WordPress überhaupt genutzt wird, geht. Alternativ gibt es dort noch ein nginx-Config-Snippet, was bei mir aber auch nicht sauber funktioniert hat. Es waren beispielsweise alle CSS Files nicht mehr erreichbar und das Design total im Eimer.

Die Lösung ist eine Anpassung den Snippets:

if (!-e $request_filename)
{
rewrite ^/(.+)/$ /index.php last;
}

Einzutragen unter Plesk > Domains > domain.tld > Einstellungen für Apache & nginx > Zusätzliche nginx-Anweisungen.
Damit funktioniert es bei mir mit drei WordPress Installationen sauber, ohne alle anderen vServer zu beeinflussen.

Nachtrag:
Nachteil hierbei, der mir aufgefallen ist: Ein Zugriff auf die von Plesk erstellten AWstats/Webalizer Statistiken ist für diese Domain/Subdomain nicht mehr möglich, da auch diese URL umgeschrieben wird.