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
        }

Maintenance information with Apache

Inzwischen ist schon eine ganze Weile der unten stehende Block in den Apache Konfigurationsdateien von Servern die ich betreue drin. Sie erlaubt mir schnell und simpel eine Wartungsseite vorzuschalten um Besucher ueber Arbeiten zu informieren. Gleichzeitig behalte ich selbst uneingeschraenkten Zugriff auf das System.

##### BEGINN MAINTENANCE #####
RewriteEngine on
# exclude my ip
RewriteCond %{REMOTE_ADDR} !1.2.3.4 [NC]
# exclude server itself
RewriteCond %{REMOTE_ADDR} !127.0.0.1 [NC]
# forward to this website
RewriteRule !^/maintenance/wartungsarbeiten.*$ /maintenance/wartungsarbeiten.html [R=307,L]
##### END MAINTENANCE #####

Damit das ganze funktioniert muss mod_rewrite aktiviert werden. Alle Anfragen die nicht von meiner eigenen IP kommen, werden automatisch auf die Wartungsarbeiten-Seite umgeleitet.

Danke an dieser Stelle noch einmal an Michael Simons, von dem ich den Schnippsel damals erhalten habe.

Apache mod_alias, mod_rewrite und GET-Parameter

Das Umleiten von einer Seite auf eine andere ist mit mod_alias sehr einfach:

Redirect /mydestination http://example.net/

Das geht auch noch recht einfach mit Regex wenn man einzelne Bereiche woanders hinschreiben will. Um diese URL-Transformation zu machen:

  • http://foobar.net/mydestination/folder/page.php -> http://example.net/foobar/folder/stuff/page.php

den folgenden RedirectMatch verwenden:

RedirectMatch ^/mydestination/(.*)/(.*)$ http://example.net/foobar/$1/stuff/$2

Wenn man jedoch mit GET-Parametern rumhantieren will, muss man mod_rewrite anstatt mod_alias nehmen. Fuer die folgende URL-Transformation:

  • http://example.net/mydestination/getstuff?pagename=foo.bar -> http://exmpla.net/blafasel/foo.bar

kann man diese Regel nutzen:

RewriteEnginge On
RewriteCond %{REQUEST_URI}  ^/mydestination/getstuff$
RewriteCond %{QUERY_STRING} ^pagename=(.*)$
RewriteRule ^(.*)$ http://example.net/blafasel/%1? [R=302,L]