Archiv für ‘Sicherheit’

Neuere Einträge »

DNSSEC mit BIND9

11. Juni 2009 00:00 | Autor: Marc | Keine Kommentare | Kategorie(n): Netzwerke, Sicherheit

Da die Verwendung von DNSSEC für die Root-Zone ja momentan heiß diskutiert wird, habe ich mir mal angesehen, wie ich denn meinem DNS-Resolver (BIND9) DNSSEC beibringe.

DNSSEC funktioniert, um es mal ganz grob zu umschreiben, mit zwei Schlüsselpaaren. Einem zone-signing-keypair (ZSK) und einem key-signing-keypair (KSK). Hiervon wird jeweils der öffentliche Schlüssel dem Resolver (aka Client) bekannt gemacht, indem dieser in das Zonefile auf einem DNS-Master integriert wird (hierzu später mehr).

Um das Ganze dann auch wirklich sicher zu machen, wird vom DNS-Resolver die trust-chain in der DNS-Hierarchie "nach oben" aufgelöst. So sucht der Resolver beim Auflösen einer DE-Domain nach den Schlüsseln für die Zone DE und danach für die Root-Zone "."

Klingt erstmal schlüssig. Nur sind weder DE-, noch Root-Zone mit entsprechenden Schlüsselpaaren signiert. Bis jetzt sind dies nur eine handvoll TLDs. Darunter .se, .pl, .gov, .museum und einige weitere. Um dennoch eine trust-chain zu schaffen, gibt es DLV (DNSSEC lookaside validation). Geht es in der normalen DNS-Hierarchie mit der trust-chain nicht weiter, versucht der DNS-Resolver per DLV einen trust-anchor zu finden.

In BIND9 (ab Version 9.3.3) wird das Ganze dann folgendermaßen implementiert (Dateinamen entsprechen Debian-Standardkonfiguration):

Zunächst den public key der ISC herunterladen, ggf. per wget. Ich habe diesen Key dann übersichtshalber in die Datei /etc/bind/named.conf.keys gespeichert. In der /etc/bind/named.conf.options werden dann folgende Zeilen hinzugefügt:
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside . trust-anchor dlv.isc.org.;

Natürlich muss dem BIND noch der public key der ISC bekannt gemacht werden. Und zwar durch folgende Zeile in der /etc/bind/named.conf:
include "/etc/namedb/named.conf.keys";

Nach einem BIND-restart kann nun per dig +dnssec iks-jena.de soa, bzw. dig iks-jena.de soa getestet werden, ob der Resolver DNSSEC spricht. Wird dig die Option +dnssec mitgegeben, sollten RRSIG-resource records ausgegeben werden.

 

Apache2 mit mehreren SSL-VirtualHosts

6. Februar 2009 17:05 | Autor: Marc | 4 Kommentare | Kategorie(n): Netzwerke, Sicherheit

Wer mehrere Domains auf einem Webserver betreibt, wird möglicherweise den Wunsch haben, hier verschiedene SSL-Zertifikate für die jeweiligen Domains zu installieren. Allerdings kann der Server erst nach dem SSL-Handshake entscheiden, welchen Host der Browser angefragt hat.

Abhilfe schafft das die TSL-Erweiterung SNI (Server Name Indication). Unterstützt wird diese doch recht sinnvolle Neuerung aber bisher nur von gnutls. Die Installation auf einem Debian-Server wird hier kurz beschrieben und sollte auch auf anderen Systemen mit geringen Anpassungen machbar sein.

Als Allererstes steht die Installation des Pakets apache2-threaded-dev auf dem Programm (sofern noch nicht geschehen). Dann wird die aktuelle gnutls-Version benötigt. Und zwar von gnu.org. Herunterladen, entpacken, konfigurieren, kompilieren, installieren kennt man ja. Dann benötigen div. Systeme noch einen Aufruf von ldconfig. Anschließend kann dann bereits das Apache-Modul heruntergeladen und installiert werden. Zu bekommen ist es hier.
Die Installationsprozedur verläft hier auch unspektakulär normal. Ich musste configure allerdings den Pfad von apxs2 mitgeben:
./configure --with.apxs2=/usr/bin/apxs2

make install
kopiert das Apache-Modul dann (hoffentlich) an die richtige Stelle. In diesem Fall /usr/lib/apache2/modules

Die Datei /etc/apache2/mods-enabled/gnutls.load wird nun mit folgendem Inhalt erstellt: LoadModule gnutls_module /usr/lib/apache2/modules/mod_gnutls.so
Und auch die Datei /etc/apache2/mods-enabled/gnutls.conf muss erstellt werden. Sie sollte Folgendes enthalten:
<IfModule gnutls_module>
GnuTLSCache dbm /var/cache/mod_gnutls_cache
GnuTLSCacheTimeout 300
</IfModule>

Natürlich müssen die virtuellen Hosts noch angepasst werden. Jeder vHost, der SSL verwenden soll, benötigt folgende Zeilen:
<VirtualHost 192.168.1.250:443>
ServerName www.example.de
GnuTLSEnable on
GnuTLSPriorities NORMAL
GnuTLSCertificateFile /etc/certs/example_server.pem
GnuTLSKeyFile /etc/certs/example_key.pem
DocumentRoot "/var/www/example.de"
...
</DocumentRoot>

Die möglicherweise bisher vorhandenen Zeilen, beginnend mit SSL, müssen selbstverständlich den neuen Angaben weichen.
Achtung: Die VirtualHosts-Direktiven müssen mit IP-Adresse definiert werden. Ggf. werden also für ein DocumentRoot 2 Einträge erstellt, beispielsweise bei paralleler Verwendung von IPv4 & IPv6.

 

Mails verschlüsseln mit GnuPG

10. Dezember 2008 23:58 | Autor: Marc | 1 Kommentar | Kategorie(n): Linux, Sicherheit

Zwar gehe ich nicht unbedingt davon aus, dass das BKA oder sonstirgendwer bewusst meine Mails mitliest, aber man weiß ja nicht, ob der Empfänger einer Mail nicht möglicherweise von solchen Maßnahmen betroffen ist. Und aus diesem Grund habe ich mich nun ein wenig mit dem Ver- und Entschlüsseln von Mails per GnuPG beschäftigt.

Zu aller erst benötigt man ein eigenes Schlüsselpaar. Dieses besteht aus einem privaten und einem öffentlichen Schlüssel. Eine kurze, aber verständige Anleitung zur Erstellung findet sich im Wiki des CCC Mainz.

Um eine verschlüsselte und signierte Mail versenden zu können, benötigt man außerdem den öffentlichen Schlüssel des Empfängern. Und genauso benötigt der Empfänger den öffentlichen Schlüssel des Absenders, um die Mail entschlüsseln zu können.

Zahlreiche Mailprogramme bieten native Unerstützung für GnuPG/PGP. Für die meisten anderen gibt es entsprechende Plugins.

Um die Schlüssel nicht immer manuell austauschen zu müssen, gibt es öffentliche Keyserver, auf denen man in aller Regel fündig wird (vorausgesetzt natürlich, der Mensch auf der Gegenseite hat seinen Schlüssel veröffentlicht).

Um besser einschätzen zu können, ob man veröffentlichten Schlüsseln vertrauen kann, gibt es das GnuPG-Web of Trust. Die Idee basiert auf der Signierung des eigenen Schlüssels durch Personen, die einem (möglichst persönlich) bekannt sind. Wie dies technisch umgesetzt ist, kann im Ubuntu-Users Wiki nachgelesen werden.

 

SSL-Zertifikate in Symbian

9. Dezember 2008 00:48 | Autor: Marc | 3 Kommentare | Kategorie(n): Mobile Kommunikation, Sicherheit

Die Aktualisierung meiner SSL-Zertifikate auf dem Mailserver stand an. Mithilfe von CAcert war dies auch schnell erledigt.

Zu besagtem Anbieter lassen sich im Internet eigentlich alle notwendigen Informationen finden, darum gehe ich hier nicht weiter auf die Prozedur ein.

Eher wenige Informationen finden sich dagegen zum Import von Root-Zertifikaten auf Geräten mit Symbian-Betriebssystem. Dies ist nämlich nicht so ohne Weiteres machbar, wie ich feststellen musste. Und die CAcert Root-Zertifikate sind, wie auf den meisten anderen Systemen auch, nicht von vornherein enthalten. Somit erhält man bei jedem Verbinden mit dem Server eine Warnmeldung, die eine manuelle Bestätigung erfordert. Und das nervt auf Dauer wirklich.

Ein Download des Root-Zertifikats, in jeglichen zur Verfügung stehenden Formaten, mit anschließender Installation per Browser funktioniert jedenfalls nicht. Und dies ist auch unabhängig vom verwendeten Browser. Meine Hoffnung stützte sich zunächst auf den standardmäßig mitgebrachten Browser meines Nokia E65. Hier schlug der Import des Zertfikats aber genau so fehlt, wie mit Opera oder Skyfire. Das Gerät behauptete, obwohl offensichtlich unwahr, das Zertifikat wäre ungültig.

Die Lösung war allerdings einfacher, als man nun annehmen sollte. Das Zertifikat muss im DER-Format einfach im Telefonspeicher oder – Präsenz vorausgesetzt – der Speicherkarte abgelegt werden. Schon hierfür wird allerdings ein Alternativbrowser benötigt, da der Standardbrowser die Option, Daten einfach nur zu speichern, nicht kennt.

Mit dem Dateimanager (Office -> Dateimanager) kann man dann die abgelegte Datei öffnen; danach wird das Root-Zertifikat installiert. Nachfolgend akzeptieren alle Anwendungen dieses Zertifikat und Verbindungen zum Server werden ohne Notwendigkeit weiterer Interaktion hergestellt.

 

Neuere Einträge »