Schlagwort: Nginx

Warum WordPress-Sicherheit wichtig ist

Posted on by Falk Jeromin

Wer einen kleinen Blog betreibt, mag sich vielleicht denken, dass ein sicheres Passwort oder 2-Faktor-Authentifizierung nicht so wichtig sind.

Das ist jedoch ein Trugschluss: auch ein Blog wenig nur ein paar Dutzend Zugriffen am Tag steht ausreichend im Fokus der „Hacker“, dass es pro Tag mehrere Login-Versuche täglich gibt.

Fail2Ban-Statistiken für drei Tage, nur WordPress-Logins

Mittels eines fail2ban-Plugins (ich verwende https://wp-fail2ban.com/) können fehlgeschlagene Login-Versuche protokolliert werden und die IP-Adressen, von denen die Angriffe ausgehen, blockiert werden.

In meiner Konfiguration werden IP-Adressen nach zwei Versuchen in einem Zeitraum von zwei Stunden für 24 Stunden komplett gesperrt. Die Sperre gilt nicht nur für den Login-Bereich, sondern für alle Seitenaufrufe.

Wer keine Möglichkeit hat, fail2ban für WordPress zu verwenden, sollte trotzdem ein Minimum an Sicherheitshinweisen befolgen: der Username sollte nicht unbedingt „admin“, „root“, „Administrator“ lauten, dass Passwort sollte mindestens 10 Zeichen inkl. Sonderzeichen & Zahlen lang sein und die Dateirechte für WordPress sollten möglichst restriktiv gesetzt sein. Für den letzten Punkt gibt es auf binary-butterfly.de eine sehr gute Anleitung: Dateirechte: warum eigentlich?

Wie sind eure Erfahrungen? Ist eure Webseite schon einmal Opfer eines Hackerangriffs geworden? Welche Sicherheitsmechanismen setzt ihr ein? Über Kommentare würde ich mich freuen!

Nginx: IP-Adresse nicht in Log-Files speichern

Posted on by Falk Jeromin

Wer aus Datenschutzgründen – DSGVO ist das Stichwort – möglichst wenige Daten speichern will, kann ein entsprechendes Logfile-Format definieren. Damit werden sowohl IPv4- als auch IPv6-Adressen anonymisiert.

Für die Error-Logs lässt sich leider kein neues Format definieren – hier kann man jedoch auch bei ausreichend kurzer Speicherfrist ein berechtigtes Interesse zum reibungslosen Betrieb annehmen. Die Einrichtung der anonymisierten Logfiles ist einfach: folgender Code wird in die zentrale nginx.conf eingefügt, dadurch werden bei IPv4-Adressen die letzten drei Ziffern durch „0“ ersetzt, bei IPv6-Adressen werden ebenfalls die letzten beiden Blöcke gelöscht.

map $remote_addr $ip_anonym1 {
default 0.0.0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" $ip;
"~(?P<ip>[^:]+:[^:]+):" $ip;
}

map $remote_addr $ip_anonym2 {
default .0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" .0;
"~(?P<ip>[^:]+:[^:]+):" ::;
}

map $ip_anonym1$ip_anonym2 $ip_anonymized {
default 0.0.0.0;
"~(?P<ip>.*)" $ip;
}

log_format anonymized '$ip_anonymized - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log anonymized;

Für die einzelnen Virtualhosts wird nun jeweils in der Access-Log-Zeile der Eintrag „anonymized“ hinzugefügt. Danach müssen einmal alle alten Logfiles gelöscht werden. Ab dem nächsten Server-Neustart werden dann die reduzierten Logfiles gespeichert, ansonsten funktioniert alles wie gewohnt. In Sachen Datenschutz ist man damit etwas näher an einer „sauberen Lösung“, die ganz im Sinne der EU-DSGVO-Datensparsamkeit ist. Diese Lösung wird auch auf diesem Server angewendet.

Let’s encrypt: Fallstricke bei Domainwechsel

Posted on by Falk Jeromin

Vor einiger Zeit habe ich die Domain meines Blogs gewechselt – von www.kadder.de auf www.techblogger.net. Dabei gab es einen Fallstrick durch die Verwendung von Let’s encrypt.

Der Ansatz: beim Wechsel der Domain soll natürlich von der alten Domain auf die neue weitergeleitet werden. Das Problem: läuft das Zertifikat der alten Domain ab, führen SSL-Aufrufe zu einem Zertifikatsfehler. Dadurch gehen dann auch Rankings und Besucher verloren, die bisher die alte Seite aufgerufen haben.

Nach einigen Experimenten mit den Nginx-Weiterleitungs-Regeln (um zu verhindern, dass das Verzeichnis .well-known, welches für die webroot-Zertifizierung von Let’s encrypt benötigt wird auf die neue Domain umgeleitet wird) ist die Lösung doch naheliegend.

Um die automatische Aktualisierung des Zertifikats weiterhin nutzen zu können (eine sehr gute Anleitung dafür gibt es bei Digitalocean) ist ein Ansatz die Erweiterung des bestehenden Zertifikats für die neue Domain. Dieses muss zusätzlich auch die bisherige Domain beinhalten.

Ist das erledigt, wird für die alte Domain das gleiche Zertifikat konfiguriert wie für die Neue, mit dem Ergebnis dass die Weiterleitungen auch wieder für SSL-Verbindungen funktionieren.

Nginx: ngx_pageespeed aktuell halten

Posted on by Falk Jeromin

Wer – wie ich auf tech-blogger.net und routerzwang.de – das Nginx-Pagespeed Modul verwendet, sollte dieses auch aktuell halten. Damit kann man sich etliches an Fehlersuche sparen.

Wenn man schon Nginx selbst kompiliert, und das Module „ngx_pagespeed“ verwendet, muss man nicht nur Nginx aktuell halten, was in den letzten Versionen HTTP/2-Support gebracht hat, sondern auch die entsprechende Module. Nachdem ich dies eine zeitlang vernachlässigt habe, konnte ich mich nicht mehr in das WordPress-Backend einloggen. Die dann nötige Fehlersuche sollte anderen erspart bleiben, deswegen hier die wesentlichen Schritte:

cd
NPS_VERSION=<span style="color: #ff0000;">1.9.32.10</span>
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${NPS_VERSION}-beta.zip
unzip release-${NPS_VERSION}-beta.zip
cd ngx_pagespeed-release-${NPS_VERSION}-beta/
wget https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz
tar -xzvf ${NPS_VERSION}.tar.gz

Die jeweils aktuelle Version bekommt man direkt bei Google, am 29.11.2015 war dies Version 1.9.32.10-beta. Nachdem man die oberen Schritte durchgeführt hat, kann man Nginx „regulär“ installieren, wobei man bei der Konfiguration darauf achten muss, auch die neue Version des ngx_pagespeed-Moduls verwendet wird.

Wer also unerklärliche Probleme mit seiner Webseite hat und Nginx 1.9.x mit ngx_pagespeed verwendet, sollte – wie eigentlich bei jeder Software – darauf achten, dass die jeweils aktuelle Version verwendet wird. Durch die einfachen Installationsschritte lässt sich dies einfach erreichen.

Nginx: PHP-Alternative HHVM

Posted on by Falk Jeromin

Wer in Sachen Ausführungsgeschwindigkeit von PHP-Scripten weitere Optimierungen vornehmen will, stolpert früher oder später über HHVM – ein Just-in-Time-Compiler für PHP.

nginx_logoHHVM kann einfach über die Debian-Paketverwaltung installiert werden. Ist das erledigt, kann es im Prinzip wie php5-fpm verwendet werden. Die ganze restliche Konfiguration innerhalb von Nginx habe ich gelassen – dadurch lassen sich gute Vergleiche in Bezug auf die Performance anstellen:

Pagespeed: WordPress in unter 1s laden (Nginx + HTTP/2)

Posted on by Falk Jeromin

Wer WordPress richtig schnell haben will, kommt ab einem gewissen Punkt mit gängigen Caching-Plugins nicht weiter. Nginx mit HTTP2 hilft weiter.

Seit der Version 1.9.5 unterstützt auch die Open-Source-Version von Nginx das HTTP/2-Protokoll direkt – eine mühsame Konfiguration bzw. das Verwenden von Patches ist damit nicht mehr nötig.

English Version below

Die HTTP/2-Implementierung läuft – zumindest bezogen auf einen Blog wie diesen – stabil und ohne weitere Auffälligkeiten. Der größte Vorteil: herausragende Seitenladezeiten. Um PHP nicht zu sehr zu fordern, verwende ich Microcaching. Dadurch sind die meisten Seiten bereits fertig erstellt und müssen nur noch an den Client ausgeliefert werden.

Nginx: HTTP/2 über Alpha-Patch verfügbar

Posted on by Falk Jeromin

HTTP/2 wird von immer mehr Browsern unterstützt, nur bei den Webservern klemmt es teilweise noch. Für Nginx ist nun ein erster Patch erschienen, der das neue Protokoll einbindet.

nginx_logoDafür ist es natürlich zuerst notwendig, dass Nginx selbst kompiliert wird. Ich verwende den aktuellen Mainline-Zweig (derzeit 1.9.4) als Basis, dazu muss noch OpenSSL 1.0.2 installiert sein. Im Nginx-Blog ist ein Beitrag mit dem passenden Patch erschienen.

Der Patch selbst ist recht einfach durchgeführt. Zuerst muss die Patch-Datei heruntergeladen werden:

wget http://nginx.org/patches/http2/patch.http2.txt

Ist das geschafft, sollte man zuerst einen Testlauf durchführen. Ansonsten kann es auch in einer Testumgebung zu unnützem Zeitaufwand kommen (folgendes im Nginx-Verzeichnis ausführen, ggf. den Pfad zur Patch-Datei anpassen):

patch -p1 --dry-run < patch.http2.txt


Pagespeed: combine_css mit WordPress

Posted on by Falk Jeromin

Wer WordPress mit mod_pagespeed bzw. ngx_pagespeed verwendet und den Filter combine_css verwendet, wird feststellen, das nichts passiert. Was ist zu tun?

Der Grund für die Probleme: Das Pagespeed-Modul berücksichtigt keine CSS-Einbindungen, die unterschiedliche IDs haben. WordPress setzt den Namen des CSS als ID bei der Einbindung, am Ende sieht es dann so aus:

link rel='stylesheet' id='wp-pagenavi-css' href='/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.70' type='text/css' media='all'/

Der Lösungsansatz: die ID sowie den dazugehörigen Wert entfernen. Dafür kann man eine entsprechende Funktion in der functions.php des Themes einbinden:

function remove_style_id($link) {
        return preg_replace("/id='.*-css'/", "", $link);
}
add_filter('style_loader_tag', 'remove_style_id');

Der Hintergrund: der Filter style_loader_tag beinhaltet die Einbindung, die Funktion remove_style_id macht nichts weiter als in der fertigen Ausgabe der CSS-Einbindung in WordPress die ID-Werte zu entfernen. Das „Problem“ besteht schon länger, auf Codecentric.de wurde dieser Lösungsansatz bereits 2011 beschrieben.

Insgesamt braucht man am Ende mit den funktionierenden combine_css das WordPress W3TC-Plugin nicht mehr: Caching wird via Microcaching direkt von Nginx gelöst, alle anderen Seitenoptimierungen erledigt das Pagespeed-Modul im Webserver. Dieser Blog läuft mit einer entsprechenden Konfiguration und erreicht damit sehr gute Speed-Index-Werte.

Managed vServer – die Vor- und Nachteile im Überblick

Posted on by Ingemar Schulz

Wer seinen eigenen Server nicht selbst warten und auf dem neusten Stand halten möchte, kann zu einem Managed vServer greifen. Immer mehr Privatpersonen oder auch Unternehmen greifen zu solch einer Lösung.

Dabei handelt es sich um einen Service, bei welchem eine externe Firma die Kapazitäten für einen virtuellen Server stellt und sich als Käufer lediglich um die Nutzung gekümmert werden muss. Worauf bei einem Managed vServer geachtet werden sollte und was ihn im Detail ausmacht, verrät der folgende Artikel.

Nginx selbst kompilieren

Posted on by Falk Jeromin

Wer Debian verwendet und auf Nginx setzt, wird früher oder später mit den integrierten Modulen nicht mehr auskommen. Die Lösung: Nginx selbst kompilieren.

Zuletzt aktualisiert am 01.06.2016

Was zuerst kompliziert klingt, ist in der Praxis recht einfach und für den Alltag tauglich – dieser Blog hier läuft mit einer selbst kompilierten Version Nginx 1.11.1. Obwohl unkompliziert, sind doch einige Voraussetzungen nötig, um Nginx unter Debian 7.6 bzw. Debian 8 (Jessie) selbst zu kompilieren:

# apt-get install build-essential
# apt-get install libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev