Schlagwort: password

Ein Versuch #Heartbleed fuer nicht-Techniker verstaendlich zu machen

prego Ein Kommentar

heartbleed

Eigentlich sollte ich keine Zeit haben zu schreiben, aber das ist die mit Abstand krasseste Sicherheitsluecke die es seit langem gegeben hat. Das Ausmass kann man nur erahnen, im Prinzip muessen alle persoenlichen Daten auf einem System das den Fehler hatte als unsicher erachtet werden. Es reicht nicht die gepatchte Version von OpenSSL einzuspielen und die betroffenen Prozesse wie Apache, Postfix, Dovecot oder OpenVPN neu zu starten. Es muessen private Schluessel und Zertifikate erneuert werden und wer den Konsequenzen der Luecke klar ins Gesicht schaut wird auch ueberall Passwoerter neu setzen muessen.

Heute beim Kaffee und Kuchen fragte unsere Nachbarin wie man sich das vorstellen koennte und ich habe versucht es wie folgt zu erklaeren:

Stell Dir vor auf dieser Welt gibt es einen Hersteller fuer Haustuerschloesser. Dieser Hersteller baut sehr sichere Schloesser und man kann sich darauf verlassen, dass wenn man seine Haustuer mit einem Schloss dieser Marke schuetzt, dass dort nicht eingebrochen werden kann. Das Schloss ist in diesen Fall OpenSSL, und das Haus der Server selbst.

Vor ein paar Jahren gab es dann den Trend zu sogenannter Perfect Forward Secrecy. Im uebertragenen Sinne kann man sich das so vorstellen, dass das Schloss kontinuierlich neue Schluessel generiert die jedes mal anders sind. Gelangt also mal ein Haustuerschluessel in die falschen Haende, dann kann man damit trotzdem nichts mehr anfangen, weil das Schloss sich geaendert hat.

Die Sicherheitsluecke in OpenSSL erlaubt es, das man von extern, ohne, dass man auf den Server einbrechen muss, an sehr sehr private Daten gelangen kann. Das koennen Zugangsdaten sein oder auch der private Key, mit dem man sich dann fuer den Server ausgeben kann ohne eben dieser zu sein.

Wenn man das wieder auf den Schlosshersteller und das Haus zurueckbringt, dann stelle man sich vor, das man zu jedem Haus mit einem Schloss von diesem Schlosshersteller hingehen kann, und ohne einzubrechen bekommt man die Information wie das Schloss jetzt Schluessel generiert. Man muss nichts stehlen, man muss nichts kaputt machen, man geht einfach hin und fragt und das Schloss sagt es einem.

Auch wenn in dem Beispiel viele Dinge vielleicht als Vergleich hinken, es zeigt ziemlich einfach welche Tragweite die Sicherheitsluecke hat. Man kann ja von aussen nicht sehen „ob jemand vorbeigekommen ist und gefragt hat wie sich das Schloss aendert oder nicht“. Aus diesem Grund muss man alle Server auf denen OpenSSL in der betroffenen Version eingesetzt wurde als unsicher betrachten. Der Fehler existiert seit dem 14. Maerz 2012 und man muss also davon ausgehen, dass es Menschen / Organisationen gibt, die seit zwei Jahren in alles rein gucken konnten was man irgendwie sichern wollte.

Fuer Sysadmins ist das der Supergau…

Eine ganz gute Zusammenfassung zu dem Thema gibt es bei Golem:

Weitere Infos:

Wer seine eigene Infrastruktur testen moechte (Router, NAS, Drucket etc) kann mit dem heartbleeder lokale IP Adressen probieren und findet dann auf einschlaegigen Seiten wie Packetstormsecurity die entsprechenden Exploits…

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

prego Schreib einen Kommentar

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: Change password on LUKS encrypted device

prego Schreib einen Kommentar

LUKS erlaubt bis zu 8 Keys, die in Slot 0-7 gespeichert werden koennen. Welche Slots belegt sind sieht man mit:

cryptsetup luksDump /dev/devicename

Einen neuen Key kann man mit dem folgenden Kommando hinzufuegen:

cryptsetup luksAddKey /dev/devicename

Einen vorhandenen Key kann man mit dem folgenden Kommando loeschen:

cryptsetup luksRemoveKey /dev/devicename