Mehr Sicherheit fuer die eigenen Daten – Einleitung und Aufraeumen

Im Kontext der NSA Affaere ist viel ueber Sicherheit und Verschluesselung geschrieben worden. Etwas zu aendern ist schwer, denn es koennen sich nur die Menschen aendern, die Dienste werden es nicht tun. Die Nutzer muessen das Thema Verschluesselung selbst in die Hand nehmen. Fuer viele ist das eigentlich unmoeglich, weil sie schlichtweg keine Ahnung haben. Fuer Menschen wie Dich und mich, die eigene Server betreiben, ist es jedoch machbar. Ich werde in der kommenden Zeit und in unregelmaessigen Abstaenden hier auf meinem Blog verschiedene Dinge vorstellen, die als direkte Reaktion aus diesen Ueberlegungen hervorgegangen sind.

Eine 100%tige Unabhaengigkeit ist nicht zu erreichen. Aber jeder kleine Schritt dahin ist richtig. Wir wollen alle kommunizieren ueber die Netze, und in der Regel bezahlen wir mit unseren Daten fuer die Services die wir nutzen. Das bedeutet im Umkehrschluss, dass wenn wir nicht mit unseren Daten bezahlen, wir auch keine Premiumdienste erwarten koennen die super einfach von der Hand gehen.

Der erste Schritt war fuer mich das Aufraeumen. Ich bin meine Rootserver durchgegangen und habe folgendes gemacht:

  1. Alle Zugaenge von mir und fuer Freunde ueberprueft die existierten und gegebenfalls gesperrt.
  2. Ich bin die Prozesstabelle durchgegangen und habe sichergestellt, dass ich keine Dienste laufen habe, die ich nicht laufen haben moechte. Gegebenenfalls habe ich diese deinstalliert.
  3. Ich bin im Apache alle vHosts durchgegangen und habe dort aufgeraeumt. Nicht mehr benoetigte deaktiviert und Konfigurationen angeglichen
  4. Ich habe meine DNS Konfigurationen durchgeschaut und sichergestellt, dass keine verwaisten Subdomains existieren etc.
  5. Ich bin das Dateisystem durchgegangen, habe mein Homeverzeichnis aufgeraeumt, die DocumentRoots der vHosts usw.

Kurz: Aufraeumen um eine gute Grundlage, einen Ueberblick, eine gute Struktur zu schaffen fuer die naechsten Arbeiten im Kontext Verschluesselung, die ich machen wollte. Stay tuned….

Eigene Debian-Pakete und Repository erstellen

Sobald als man Admin mehrere Server zu administrieren hat, kommt man in den Genuss ein- und das dasselbe auf viele Servern immer wieder machen zu muessen. Heute moechte ich mich dem Thema widmen auf vielen Servern z.B. eine neue Version des Backupskriptes einzuspielen. Dafuer brauche ich zwei Dinge

  1. ein Debian Paket mit meinem Skript
  2. ein Debian Repository ueber das das Paket verteilt wird

Der hier im folgenden vorgestellte Weg ist sehr simpel und rudimentaer gehalten und behandelt explizit Dinge wie SecureApt nicht.

Erstellen eines eigenen Debian-Paketes

Zum Erstellen des eigenen Debian Paketes benoetige ich nun zwei Dinge. Einmal mein Backupskript pregoBackup.sh und einmal eine control-Datei, die Informationen ueber das Debian Paket enthaelt. Die control Datei koennte z.B. wie folgt aussehen:

Package: pregoBackup
Version: 0.5
Section: server
Priority: optional
Architecture: all
Essential: no
Installed-size: 1024
Maintainer: prego presto
Description: pregos Backup Skript zum Sichern des Servers

Das ganze vorgehen jetzt in Worte zu fassen waere sehr umstaendlich. Deswegen in kurz: die control Datei liegt in dem Unterordner ./DEBIAN und neben das DEBIAN Verzeichnis packe ich das Skript an die Stelle, wo ich es im Dateisystem liegen haben moechte:

cd /tmp
mkdir pregoBackup
cd pregoBackup
mkdir ./DEBIAN
mkdir -p ./root/skripte
cp control ./DEBIAN
cp pregoBackup.sh ./root/skripte

Als naechstes wird das Debian-Paket erstellt:

cd /tmp
dpkg-deb --build pregoBackup

Danach sollten wir die Datei /tmp/pregoBackup.deb haben. Was darin enthalten ist koennen wir uns mit:

dpkg-deb --contents pregoBackup.deb

anzeigen lassen, und wer moechte kann es auch spasseshalber mal mit

dpkg -i pregoBackup.deb
aptitude show pregoBackup
aptitude purge pregoBackup

installieren, angucken und deinstallieren.

Anlegen eines Debian Repositories

An zweiter Stelle lege ich nun ein Repository an. Dafuer erstelle ich zuerst eine Verzeichnisstruktur dafuer:

mkdir -p /srv/myrepository/{binary,source}

Anschliessend lege ich einen simplen Apache vhost an mit einer Zugangsbeschraenkung fuer das Repository auf mein lokales Netz:

    ServerAdmin webmaster@example.net
    ServerName myrepository.example.net
    DocumentRoot /srv/myrepository/
 
                AllowOverride None
                Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order Deny,Allow
                Deny from all
                Allow from 192.168.0.0/255.255.0.0

Nun kann ich mein frisch erstelltes Debian-Paket in die Repository Dateisystemstruktur kopieren:

cp /tmp/pregoBackup.deb /srv/myrepository/binary/

Zu guter letzt muss noch der Repository Index erstellt werden. Dafuer muss das Paket dpkg-dev vorhanden sein:

aptitude install dpkg-dev
cd /srv/myrepository
dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz

Wenn das alles fertig ist, brauche ich nur noch auf meinem Server die entsprechenden Zeilen in die /etc/apt/sources.conf eintragen, die Liste der verfuegbaren Pakete von den apt-Quellen erneuern und dann kann das Paket installiert werden.

## my personal repository
deb http://myrepository.example.net binary/
deb-src http://myrepository.example.net source/
aptitude update
aptitude install pregoBackup

HowTo: multiple Apache2 vhosts mit unterschiedlichen SSL-Zertifikaten

Die Aufgabe: in Apache bei verschiedenen vhosts verschiedene SSL-Zertifikate fuer die Verschluesselung definieren.
Das Problem: mit mod_ssl laesst sich das ganze nicht so einfach realisieren.
Die Ursache: vhosts basieren auf Basis von HTTP-Headers, SSL liegt ein Layer darunter. Die Verbindung wird gesichert bevor HTTP gesprochen wird. Der Server kann bei Verbindungsaufbau nicht wissen welchen vhost er danach bedienen soll, deswegen kann er das richtiger Zertifikat nicht auswaehlen.
Die Loesung: mod_gnutls
HowTo: das ganze unter Debian Lenny

Ich gehe an dieser Stelle davon aus, dass man bereits SSL-Zertifikate generiert hat (blubs).

Als naechstes ist es nun wichtig das Modul zu installieren, anzupassen und zu aktivieren:

aptitude install libapache2-mod-gnutls

Danach die /etc/apache2/mods-available/gnutls.conf anpassen:

<IfModule mod_gnutls.c>
  GnuTLSCache dbm /var/cache/apache2/gnutls_cache
 
  AddType application/x-x509-ca-cert .crt
  AddType application/x-pkcs7-crl    .crl
 
  GnuTLSCacheTimeout 300
  NameVirtualHost *:443
</IfModule>

und das Modul aktivieren:

a2enmod gnutls

Nun noch die Zeile:

Listen 443

zu der /etc/apache2/ports.conf hinzufuegen und dabei darauf achten, dass die Zeile vor der „Listen 80“ steht, da es sonst in der /var/log/apache2/error.log zu den folgenden Zeilen kommen kann:

[Sun Dec 05 14:37:06 2010] [error] [client ::1] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.'

Nun koennen die vhosts entsprechend eingerichtet werden. Hier ein generisches Beispiel fuer einen vhost:

<VirtualHost *:443>
    ServerAdmin webmaster@example.net
    ServerName www.example.net
    ServerAlias example.net
    DocumentRoot /var/www/example.net/
 
    <Directory /var/www/example.net/>
        Options +Indexes
    </Directory>
 
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/ssl/myCA/private/www.example.net-key-cert.pem
    GnuTLSKeyFile /etc/ssl/myCA/private/www.example.net-key-cert.pem
    GnuTLSPriorities SECURE:!MD5
 
    CustomLog /var/log/apache2/example.net-access.log combined
</VirtualHost>

Nach einem Neustart von Apache2 kann nun per https auf den gewuenschten vhost zugegriffen werden, viel Spass beim Einrichten des zweiten und freien wenns klappt!