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 🙂

 

OpenVPN Cipher Speedtest

Aufgrund des Upgrades meiner Internetleitung auf 400/25MBit bei Vodafone Kabel und darauf folgend geringer OpenVPN Tunnel Performance habe ich mal ein paar Benchmarks gemacht.

Zuerst etwas zur Vorgeschichte:

Ich habe hinter dem Provider Router (Jetzt FritzBox 6490) schon lange eine pfsense Firewall laufen. Diese läuft auf einem kleinen, sparsamen Atom N2800 und macht neben Firewalling und Routing auch ein OpenVPN Tunnel zu meinem Root im RZ auf, um an die internen VMs zu kommen und Backups zu fahren.

Bei den bisherigen Leitungen (2MBit, 16MBit, 25MBit Downstream) war dies für die CPU kein Problem, mit AES-128-CBC als Cipher und SHA1 als Auth, die Bandbreite zu nutzen. Mit dem Upgrade auf die 400er Leitung blieb der Tunneldurchsatz allerdings bei etwa 30MBit „stecken“. Die CPU ist nicht die performanteste und unterstützt noch kein AES-NI oder AVX, aber mich hat natürlich interessiert, wie weit ich Upgraden müsste, um genug Durchsatz zu bekommen.

Leider finden sich kaum aktuelle Vergleiche im Netz, welche Kombination wie viel Durchsatz mit OpenVPN und verschiedenen Ciphern bringt. Der Server im RZ hat selber genug Power, dort werkelt ein Intel Core i7 6700, also aktueller Stand der Technik und AES-NI sowie AVX support. OpenVPN Cipher Speedtest weiterlesen

LineageOS – Ein erster Blick

Ich bin seit gut 2 Wochen auf LineageOS unterwegs, nachdem ich vorher schon lange CyanogenMod benutzt habe.

Im Einsatz ist es auf einem Samsung Galaxy Note 10.1 2014 LTE (lt03lte) und einem LG G4 (h815), bei beiden läuft es bisher ohne großen Problemen.

Anfangs hat et etwas gedauert, bis ich auf der Homepage http://lineageos.org/ die Firmware gefunden habe: Community –> Wiki –> devices list. Noch ist das Wiki recht leer, aber nach und nach füllt es sich. Als Anleitung gibt es häufig noch Links zu den archivierten Cyanogen-Wiki-Pages.

Inzwischen geht es auch einfacher über https://download.lineageos.org/

Auf dem Note 10.1 läuft soweit alles Rund, nicht mal die Amazon Prime App hat Probleme gemacht 🙂 Auf dem G4 gibt es noch eine Macke, die ich schon unter Cyanogen hatte: Die Kamera ist recht Zickig, egal ob die Google oder Cyanogen Version. Bilder mit Blitz sind häufig trotz Auslösen einfach nur schwarz und die App hängt sich häufig auf. Ich hoffe, hier wird es noch Besserung geben. Die Kamera des G4 ist eigentlich verdammt gut, wäre schade drum.

Jetzt fehlt nur noch eine passende Version für mein HTC HD2 sowie Motorola Atrix, das werden aber wohl Träume bleiben. Die Geräte sind einfach schon zu alt, schwer da noch passende Kernel Treiber zu bekommen.

Ich bin gespannt wie es weiter geht, hoffe auf eine lange Zukunft.

PS: Wenn jemand über die Update-App ein Update geladen hat uns es dann im Recovery sucht, der Pfad ist (Stand 16.02.2017) /data/data/org.lineageos.updater/app_updates.

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.

UBNT Unifi mit SSL und fhem auf dem RaspberryPi

Anleitungen, Unifi auf dem Raspberry zum laufen zu bringen gibt es inzwischen wie Sand am Meer. Ich stelle meinen aktuellen Weg ebenfalls Online.

Basis-Installation:

echo "deb http://www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti" > /etc/apt/sources.list.d/ubnt.list

apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50

apt-get update

apt-get install unifi -y

Dann sollte die Standard-Instanz vom MongoDB noch deaktiviert werden, da diese nicht genutzt wird und nur eh schon knappe Ressourcen frisst. Außerdem werden die Journal-Dateien auf 128M statt 1GB pro File, und maximal 512MB in Summe, festgelegt:

echo "ENABLE_MONGODB=no" | sudo tee -a /etc/mongodb.conf > /dev/null

echo "smallfiles = true" | sudo tee -a /etc/mongodb.conf > /dev/null

service mongodb restart

Damit ist der Unifi Controller einsatzbereit.

UBNT Unifi mit SSL und fhem auf dem RaspberryPi weiterlesen