Journal « Raphael Kallensee » security

Server Name Indication (SNI) mit Ubuntu 10.04 (“Lucid Lynx”)

Raphael Kallensee — Tue, 29 Jun 2010 22:47:04 +0000

Bei “Name-based virtual hosts” in Verbindung mit SSL gibt es ein Problem: “by design” war es nicht möglich, mehrere virtuelle SSL-Hosts mit unterschiedlichen Domains und Zertifikaten parallel auf einer IP-Adresse und demselben Port zu betreiben. Problem ist, dass zuerst zwischen Client und Server die verschlüsselte Verbindung aufgebaut wird (bei der das Zertifikat bereits benötigt wird). Erst anschließend werden die HTTP-Header über die verschlüsselte Verbindung gesendet, in denen dann auch der Hostname steht, der jetzt möglicherweise aber gar nicht mehr zum Zertifikat passt. Einzige Lösung war bisher, pro SSL-IP eine eigene IP-Adresse (bzw. notfalls einen anderen Port) zu verwenden.

Abhilfe gibt es theoretisch bereits seit mehreren Jahren: Server Name Indication (SNI) ist eine Erweiterung des SSL-Protokolls, bei der einfach bereits beim Verbindungsaufbau vor dem SSL-Handshake der gewünschte Hostname mitgesendet wird.

Serverseitig benötigt diese Erweiterung insbesondere OpenSSL ab Version 0.9.8f sowie Apache ab 2.2.12 – außerdem müssen beim Kompilieren diverse Flags gesetzt sein. Seit Ubuntu 9.10 “Karmic Koala” sind sämtliche Voraussetzungen erfüllt, ich habe SNI nun erstmalig problemlos mit 10.04 “Lucid Lynx” im Einsatz. SNI funktioniert mit Apache und OpenSSL nun ohne Neu-Kompilieren “out of the box”.

Die Vorgehensweise ist im Prinzip ganz einfach: nach einem

NameVirtualHost *:443

können in den Apache-Konfigurationsdateien mehrere virtuelle SSL-Hosts definiert werden, die jeweils eigene SSL-Zertifikate besitzen. Weitere Infos sind im Apache-Wiki sowie hier zu finden.

Eine weitere Option erlaubt das Erzwingen von SNI: übermittelt ein Client nicht die SNI-Header, kann er den jeweiligen virtuellen SSL-Host nicht erreichen. Diese Option ist standardmäßig auf “off”.

SSLStrictSNIVHostCheck on

Der Haken: neben dem Server muss natürlich auch der Client SNI unterstützen. Internet Explorer unter Windows XP unterstützen SNI generell nicht (wobei es Berichte gibt, dass mit XP SP3 die Unterstützung vorhanden ist), Konqueror beherrscht SNI ebenfalls nicht. Ein Überblick über die Browser-Unterstützung findet sich hier. Ob ein Browser SNI unterstützt, kann man bei sni.velox.ch testen.

Zumindest in einigen Bereichen kann man SNI trotz der teilweise fehlenden Client-Kompatibilität bereits einsetzen – die client-seitige Unterstützung wird sich in Zukunft weiterhin verbessern.

Ein Artikel zum Thema ist in der c’t 23/09 erschienen und ebenfalls bei sni.velox.ch zu finden.

Selbstsigniertes SSL-Zertifikat erstellen

Raphael Kallensee — Sat, 07 Feb 2009 01:14:42 +0000

Eher als Notizzettel für mich: kurz und knapp – so erstellt man ein selbstsigniertes SSL-Zertifikat mit OpenSSL:

Private Key erstellen
openssl genrsa -des3 -out server.key 1024

Private Key ohne Passwortschutz erstellen (für Apache u.a.)
openssl rsa -in server.key -out server.key.decrypted

Certificate Signing Request erstellen
openssl req -new -key server.key -out server.csr

Zertifikat ausstellen
openssl x509 -req -days 3650 -in server.csr -signkey server.key.decrypted -out server.crt

PEM-Datei (für Courier etc.) erstellen
cat server.key.decrypted server.crt > server.pem openssl gendh >> server.pem

Trusted Computing

Raphael Kallensee — Tue, 23 Oct 2007 18:50:45 +0000

Falls ihn jemand noch nicht gesehen hat: der preisgekrönte Animationsfilm von Benjamin Stephan und Lutz Vogel zum Thema Trusted Computing.

Bei netzpolitik.org gibt es außerdem noch zwei Podcasts zum Thema.

fail2ban: Abwehren von Brute-Force-Attacken

Raphael Kallensee — Sat, 06 Oct 2007 00:01:01 +0000

Wer seine Logs regelmäßig ansieht, dürfte in der Regel feststellen, dass er größeren oder kleineren Brute-Force-Attacken ausgesetzt ist.

Um solchen “Wörterbuch”-Attacken zu begegnen, gibt es unter Linux ein kleines Tool: fail2ban. Die Paketbeschreibung unter Debian sagt:

fail2ban - bans IPs that cause multiple authentication errors

Das Tool überwacht verschiedene Log-Dateien auf Login-Fehlversuche und sperrt die fremden IP-Adressen via iptables aus. Welche Logs ausgewertet werden und wie lange die Sperre andauern soll, bis die IP wieder freigegeben wird, lässt sich recht einfach konfigurieren.

Eine gute, knappe Anleitung zum Einrichten gibt es bei howtoforge.

w00tw00t.at.ISC.SANS.DFind

Raphael Kallensee — Fri, 05 Oct 2007 23:46:38 +0000

Schon seit längerem sind in den (Apache-)Logs meines neuen Servers einige seltsame Zeilen zu finden, denen ich dann zuweilen mal nachgehe. Folgendes Rätsel ist gelöst (Ursprungs-IP wurde unkenntlich gemacht):

xxx.xxx.xxx.xxx - - [30/Sep/2007:12:48:33 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 395 "-" "-"

Diese Zeilen sind der Fingerprint von DFind, einem vulnerability Scanner, der den Server auf Schwachstellen durchsucht. Bei Symantec kennt man das Tool als “Hacktool.DFind” – dort ist auch eine Liste von Schwachstellen, auf die das Programm mögliche Opfer testet.

In letzter Zeit häufen sich Angriffsversuche von IP’s, die aus Adressbereichen von Hostern kommen – Leute, sichert Eure Server!