HowTo: https beim Anmelden an WordPress Blog Backend + Schutz gegen Brutforce

Bei meinem Blog hatte ich vor kurzem zwei Dinge die ich Aendern wollte:

  1. Der Blog soll ueber http:// lesbar sein, aber Anmelden soll grundsaetzlich immer https:// sein, damit das Passwort nicht unverschluesselt durch das Netz schwirrt
  2. Der Login Bereich soll gegen Brutforce Attacken abgesichert sein

Anmelden an Blog Backend nur ueber https://

Viele Menschen lesen diesen Blog oder finden hier hin. Ich bin immer wieder erstaunt darueber. Die Verbindung soll grundsaetzlich unverschluesselt sein, aber das Anmelden wollte ich – egal was ich eingebe – immer auf https:// landen, damit das Passwort nicht unverschluesselt durchs Netz uebertragen wird. Dafuer habe ich im vhost der auf Port 80 lauscht die folgende Rewrite Regel hinzugefuegt:

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/wp-login.php$
RewriteCond %{QUERY_STRING} ^(.*)$
RewriteRule ^(.*)$ https://blog.pregos.info/wp-login.php/%1? [R=302,L]

So werde ich immer auf https weitergeleitet ohne das ich darauf achten muss, das was ich eingebe. Es ist wichig mit mod_rewrite zu arbeiten und nicht nur einen Alias zu setzen, da wenn man sich aus dem Backend abmeldet man dann auch auf den Anmeldebildschirm zurueckgeleitet wird. Da haengen GET Parameter dran. Ein Alias wuerde dann nicht mehr greifen, die mod_rewrite Regel oben tut es hingegen.

Schutz gegen ungewollte (Brutforce) Anmeldeversuche am Blog Backend

Nach vielen vielen Jahren den ich diesen Blog nun schon schreibe bin ich auf das Plugin WP fail2ban gestossen. Es loggt fehlgeschlagene Loginversuche ins Backend mit, so das man diese mit fail2ban auswerten und behandeln kann. Ich habe mit ein bisschen schlechten Gewissen das Plugin installiert und mal geschaut was so passiert. Von der Anzahl der Attacken war ich echt ueberrascht. Teilweise Skriptkiddies die ueber Stunden hinweg von der gleichen IP probieren, teilweise aber auch Brutforce Attacken mit ueber 16000 Loginversuchen in ~3h.

Spannend zu sehen was mir vorher alles entgangen ist, aber so richtig gut fuehlt sich das nicht an, dass von tausenden von Hosts probiert wird und die immer erst nach drei Versuchen gesperrt werden. Deswegen ist es am einfachsten, wenn man das Backend mit einem Benutzernamen und Passwort direkt im Apache sichert. Das habe ich auf die folgende Art und Weise im vHost getan:

<Location /wp-admin/>
        AuthName "Wordpress Login"
        AuthType Basic
        AuthUserFile /var/www/pregos.info/htpasswd-blog
        Require valid-user
</Location>

Da die Angreifer einfach per POST Daten an die wp-login.php schicken habe ich die Datei selbst auch noch explizit wie folgt abgesichert:

<FilesMatch "wp-login.php">
        AuthName "Wordpress Login"
        AuthType Basic
        AuthUserFile /var/www/pregos.info/htpasswd-blog
        require valid-user
</FilesMatch>

In wieweit das Passwort ein komplexes Zufallspasswort oder ein einfacher zu merkendes ist, ist jedem selbst ueberlassen. Es hilft aber erstaunlich einfach und effizient gegen die Attacken auf meinen Blog.

HowTo: Apache SSL and perfect forward secrecy

Man liesst die Tage ueberall von perfect forward secrecy. Das bedeutet, dass man bei verschluesselten Verbindungen erst sichere Protokolle anbietet und gleichzeitig unsichere verbietet. Mit den folgenden Einstellungen kann man in Apache einen SSL vHost selber PFS like absichern und auch BEAST (Browser Exploit Against SSL/TLS) Attacken abschwaechen:

SSLProtocol all -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5

Um die SSL Konfiguration des vHosts zu testen ist noch der SSL Server Test von Qualys SSL Labs zu empfehlen.

(via)

Mehr Sicherheit fuer die eigenen Daten – Komfort mit Firefox Sync + Masterpasswort

Dieses ist der vierte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten drei Artikeln befinden sich am Ende des Blogposts. Im diesem vierten Teil moechte ich auf das Thema Komfort im Webbrowser eingehen und dabei auf meinen frueheren Artikel zum selbst gehosteten Firefox Sync verweisen.

Es gibt eine ganze Menge an Webbrowsern dort draussen, das sind zum Beispiel Google Chrome, Apple Safari, Microsoft Internet Explorer oder halt auch Mozilla Firefox. Ich bevorzuge den letzten weil er erstens OpenSource ist, zweitens gut unter Linux laeuft und drittens mich nicht versucht in irgendwelche Services zu zwingen. Ich nehme dabei bewusst in Kauf, dass die Performance der JavaScript Engine nicht so gut ist, wie zum Beispiel verglichen mit der von Google Chrome. Auf Annehmlichkeiten wie synchronisierte Lesezeichen oder Chronik moechte ich aber dennoch nicht verzichten. Ich persoenlich synchronisiere damit Daten zwischen drei Geraeten, davon ein Mobiltelefon.

Aus diesem Grund habe ich bereits vor laengerer Zeit mir einen selbst gehosteten Firefox Sync Server installiert. Dort ist alles in meiner Hand, auf meinen Servern, ich kann verschluesseln, und meine Passwoerter schwirren wenn ueberhaupt dann gesichert durchs Netz.

Im Prinzip ist bei mir alles noch genauso, wie ich es in der Anleitung damals beschrieben habe. Der einzige Unterschied ist der Apache vHost, der nun ueber SSL geht:

<VirtualHost *:443>
        ServerName ffsync.example.org
        ServerAdmin webmaster@example.org
        DocumentRoot /opt/ffsync/server-full
 
        SSLEngine on
        SSLCertificateFile /path/to/ffsync.example.org.crt
        SSLCertificateKeyFile /path/to/example.org.key
 
                Order deny,allow
                Allow from all
 
        WSGIProcessGroup ffsync
        WSGIDaemonProcess ffsync user=ffsync group=ffsync processes=2 threads=25
        WSGIPassAuthorization On
        WSGIScriptAlias / /opt/ffsync/server-full/sync.wsgi
 
        CustomLog /var/log/apache2/ffsync_access.log combined
        ErrorLog /var/log/apache2/ffsync_error.log
</VirtualHost>

Weiter habe ich in der etc/sync.conf die URL des fallback node auf https:// abgeaendert.

Ganz wichtig dabei ist natuerlich: WENN Passwoerter im Webbrowser abgespeichert werden, DANN MUSS ein Masterpasswort gesetzt sein. Das gilt fuer Mozilla Firefox genauso wie fuer Mozilla Thunderbird. Wenn KEIN Masterpasswort gesetzt ist, kann JEDER der Zugriff auf den laufenden Webbrowser oder das laufende Thunderbird hat mit fuenf Klicks ALLE gespeicherten Passwoerter einsehen. Diese fuenf Klicks sind:

  1. Firefox
  2. Einstellungen
  3. Sicherheit
  4. Gespeicherte Passwoerter
  5. Passwoerter anzeigen

An der gleichen Stelle kann man uebrigens auch das Masterpasswort setzen. In Thunderbird ist es auch Einstellungen -> Sicherheit -> Passwoerter…

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.

Mehr Sicherheit fuer die eigenen Daten – Zertifikate

Dieses ist der dritte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann. Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann. Der dritte Teil hier bezieht sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.

Oft probiere ich eine Software aus, erstelle mir fix eine Subdomain, richte einen vHost ein, und entweder das was ich ausprobiere ist gut und es geht in meinen digitalen Alltag ueber, oder eben nicht. Zurueck bleiben verwaiste Subdomains, deaktivierte vHosts und dann natuerlich Applikationen die ich taeglich nutze, und zu denen ich eine unverschluesselte Verbindung aufbaue, obwohl ich es selbst in der Hand habe die Verschluesselung einzustellen.

Ich habe mich an dieser Stelle bewusst gegen eine eigene CA entschieden. Das ist hinten raus sicherlich praktisch, haette meine Einstiegshuerde aber wieder zu hoch gelegt und ich bin mit frueheren Versuchen daran bisher immer an mir selbst und fehlender Kontinuitaet gescheitert. Schlichte einfache selbst signierte Zertifikate sind fuer mich immer noch am einfachsten.

Was ich jedoch gemacht habe, ist, das ich alle Zertifikate bei CAcert signieren lassen habe. Das hat fuer mich den Vorteil, dass ich ueber alle Zertifikate einen Ueberblick habe, und wenn ich will, kann ich mir auch das CAcert Rootzertifikat importieren und einfach denen vertrauen. Gemacht wie folgt:

  1. Key erzeugen:
    openssl genrsa -out example.org.key 4096
  2. CSR erzeugen:
    openssl req -new -key example.org.key -out example.org.csr

    Bei den Fragen ist nur wichtig, dass der „Common Name“ der Name der Domain oder Subdomain ist, die man sichern moechte. Ein Passwort ist nicht einzugeben.

Bei CACert dann den Inhalt der example.org.csr Datei eingeben und das Zertifikat was man angezeigt und per Email zugesendet bekommt unter example.org.crt abspeichern.

Ein einfacher Apache vHost mit SSL sieht wie folgt aus:

<VirtualHost *:443>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
SSLEngine on
SSLCertificateFile /path/to/example.org.crt
SSLCertificateKeyFile /path/to/example.org.key
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man auf den Dienst nur ueber https zugreifen moechte und eine einfache Weiterleitung von  HTTP auf HTTPS einrichten moechte, kann man das zum Beispiel mit einem kleinen vHost und einer entsprechenden rewrite Regel machen:

<VirtualHost *:80>
ServerAdmin webmaster@example.org
ServerName example.org
DocumentRoot /var/www/example.org
 
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
CustomLog /var/log/apache2/example.org-access.log combined
</VirtualHost>

Wenn man Zugriff auf ein Nagios hat, dann ergibt es Sinn das Ablaufdatum des SSL Zertifikates mit zu Ueberwachen, damit man da nicht irgendwann in Probleme rennt. Das folgende Kommando und der folgende Check warnen einen sobald das Zertifikat nur noch 30 Tage gueltig ist.

Command Definition:

define command{
        command_name    check_ssl_certexpire
        command_line    $USER1$/check_http -H $HOSTNAME$ -p $ARG1$  -C 30
        }

Check:

define service{
        use                             my-service
        host_name                       example.org
        service_description             SSL-Cert root
        check_command                   check_ssl_certexpire!443
        }