Mehr Sicherheit fuer die eigenen Daten – vollverschluesselte Festplatten auf Servern

Dieses ist der neunte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten acht Artikeln befinden sich am Ende des Blogposts. Im neunten Teil moechte ich meine Ueberlegungen zu selbstgehosteten Servern und deren Sicherheit im Kontext Verschluesselung der Festplatten vorstellen.

Wenn ich eine verschluesselte Verbindung zu einem anderen Rechner / Dienst im Internet aufbaue kann ich das ungewollte Mitlesen der Kommunikation erschweren bis verhindern. Speichere ich nun die Daten auf eigenen Servern und vertraue sie nicht Firmen wie Google (Mail, Drive), Microsoft (Outlook.com, Skydrive) oder Amazon Cloud (Dropbox) an, dann erschwere ich auch erst einmal das ungewollte Lesen meiner Daten. Ich bin ja schliesslich kein Administrator auf dem anderen Server und weiss nicht wann sich wo auf deren Seite jemand potentiell dazwischen schaltet.

Meine Daten liegen also auf einem selbstgehosteten Server und ich baue eine verschluesselte Verbindung dahin auf. Die Daten auf dem Server selbst sind aber immer noch unverschluesselt gespeichert. Es kann also potentiell jemand ins Rechenzentrum gehen, sich den Server schnappen, analysieren und die Daten dort herunter ziehen. Was liegt da naeher als die Festplatten zu verschluesseln.

Mit LUKS (klick) steht dafuer unter Linux auch eine gute Loesung zur Verfuegung. Auf meinem Laptop oder meinem Arbeitsplatzrechner setze ich sie bereits ein. Ist ja auch kein Problem beim Booten das Passwort einzugeben. Das bei einem Server zu tun ist es schon sehr viel umstaendlicher, denn man sitzt ja eigentlich nie direkt davor…

Ich werde hier nun keine Anleitung schreiben wie man die Schritte 1:1 geht um seine Festplatte mit LUKS zu verschluesseln. Davon gibt es bereits genuegend im Netz. Einige Distributionen wie Debian bieten es sogar im Installer gleich an die Festplatte mit LVM zu erzeugen und dann mit LUKS zu verschluesseln. Die Stichworte beim Suchen nach entsprechenden Dokumentationen sind Distributionsname + „LUKS“ oder „cryptsetup“ oder „encrypted filesystem“. Nicht zu vergessen auch unter /usr/share/doc/cryptsetup/ nach zuschauen!

Der Clou an der Geschichte ist nun, das man einen dropbear SSH Server in die initramfs seines Servers hinzufuegen kann. So ist es moeglich waerend des Bootvorgangs eine SSH Verbindung in die initramfs aufzubauen und dort das Passwort zum entschluesseln der Festplatte einzugeben. Damit das ganze komfortabel wird, nutze ich dafuer SSH-Keys ohne Passwort in Verbindung mit einem Miniskript pro Maschine.

Boese boese mag sich nun mancher denken, aber alles halb so wild. Ich habe eine Maschine die ist unverschluesselt. Einfach, weil Sie es nicht benoetigt und dort nichts wichtiges abgespeichert ist. Auf dieser Maschine habe ich einen Ordner mit ecryptfs verschluesselt (klick fuer Anleitung). In diesem Ordner bewahre ich folgendes auf:

  1. private Keys fuer die Verbindung zu dem Dropbear Servern im initramfs der virtuellen Maschinen
  2. eigene known_hosts Datei dafuer
  3. Ein Skript pro VM das mir die Eingabe des Passworts erleichtert.

Das Skript sieht schematisch wie folgt aus:

#!/bin/bash
 
ssh -o "UserKnownHostsFile=known_hosts/known_hosts.initramfs" -i "keys/servername" root@1.2.3.4 "echo -ne "**TOPSECRET**" >/lib/cryptsetup/passfifo"

Wenn ich nun einen Server neu starte bei dem die Festplatte verschluesselt ist, dann melde ich mich auf der unverschluesselten Maschine an, mounte den ecryptfs verschluesselten Ordner und muss dann nur noch das entsprechende Skript starten, z.B. ./unlock_servername und schon bootet die Maschine durch.

In diesem Kontext sicherlich noch einmal spannend ist auf einen drei Jahre alten Blogeintrag „Howto: virsh console“ zu verweisen um sich das ganze auch vom physikalischen Server aus anzuschauen ;-)

Vorherige Blogposts:

  • 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 bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.
  • Im sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.
  • Der siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.
  • Der achte Teil stellt webbasierte Dienste vor, die man selber hosten kann und dadurch die eigenen Daten unter mehr Kontrolle hat.

Mehr Sicherheit fuer die eigenen Daten – SSH Key Authentifizierung und pam_wheel

Dieses ist der sechste Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten fuenf Artikeln befinden sich am Ende des Blogposts. Im diesem sechsten Teil dreht es sich darum, wie man sich auf seinen Servern mit SSH aber ohne Passwort sicher authentifizieren kann.

Wie in meinem letzten Artikel geschrieben sind sichere und auch ueberall unterschiedliche Passwoerter im Rahmen des machbaren. Wenn man allerdings wie ich Systemadministrator ist und viele viele viele Server verwaltet, wuerde man sofort an Grenzen stossen wenn man sich fuer jeden Server ein eigenes Passwort merken muesste. Aus diesem Grund moechte ich hier noch einmal auf SSH Keys zur Authentifizierung sowie pam_wheel eingehen.

SSH-Key erzeugen

Wer es noch nicht weiss: Man kann bei SSH nicht nur Passwoerter sondern auch Keys zur Authentifizierung einsetzen. Das ist nicht nur extrem praktisch, sondern bei korrekter Nutzung auch sicherer als Passwoerter.

Einen eigenen SSH-Key mit dem Namen „example“ erzeugt man sich mit dem folgenden Kommando:

ssh-keygen -t rsa -f ~/.ssh/example

Dabei wird zur Eingabe und Bestaetigung eines Passworts aufgefordert. Hier sollte man ein definitiv eines eingeben und auch ein sicheres waehlen. Anschliessend hat man zwei neue Dateien:

  1. ~/.ssh/example -> der private und geheime Key
  2. ~/.ssh/example.pub -> der public Schluessel dazu

Wenn ich mich nun an einem Server mit diesem Schluessel anmelden moechte, dann muss ich den oeffentlichen Teil davon auf dem gewuenschten System in die ~./ssh/authorized_keys hinzufuegen. Das kann ich entweder ueber copy & paste machen, oder besser mit dem Befehl ssh-copy-id:

ssh-copy-id -i ~/.ssh/example.pub user@host:

Anschliessend kann ich mich mit dem Key und dem fuer diesen Key notwendigen Passwort an dem Server authentifizieren:

ssh -i ~/.ssh/example user@host

Wenn man moechte, kann man sich das ganze auch in der ~/.ssh/config noch ablegen. Vor allem praktisch, wenn man mehrere verschiedene Keys hat. Ein entsprechender Eintrag kann wie folgt aussehen:

Host                    foo
HostName                foo.example.org
User                    bar
IdentityFile            /home/user/.ssh/example
IdentitiesOnly          yes

SSH-Server absichern

Den SSH Server kann man dann auch absichern. Ich nutze grundsaetzlich die Konfigurationsoption nur den Nutzern einer bestimmten Nutzergruppe Zugriff per SSH zu erlauben. Dazu:

  • Benutzergruppe anlegen:
    addgroup ssh-allow
  • Den gewuenschten Nutzer der Gruppe hinzufuegen:
    adduser USERNAME ssh-allow
  • und dann den SSH-Zugriff auf diese Gruppe beschraenken, indem die folgende Zeile in die /etc/ssh/sshd_config hinzufuegegt wird:
    AllowGroups     ssh-allow

Merke: Testen ob es funktioniert solange man noch angemeldet ist, sonst kann es unangenehm werden ;-)

Weiter kann man auch die Passwortauthentifizierung fuer SSH komplett abschalten. Dann kann man sich nur noch per Key Authentifizieren. Ob man das moechte sei jedem dahingestellt, denn man muss seinen Key natuerlich auch immer dabei haben. Ich habe es bei einigen Maschinen im Einsatz. Dafuer muss in der /etc/ssh/sshd_config der Parameter

PasswordAuthentication no

gesetzt sein. Spannend ist in diesem Kontext noch zu erwaehnen, dass man das mit dem Match Block zum Beispiel fuer bestimmte IP-Adressen oder Netze Ausnahmen erlauben kann. So kann der Zugriff per Passwort deaktiviert sein, aber von einer (VPN) IP, einem bestimmten (Root)-Server oder dem Firmennetz dennoch erlaubt sein. Der Eintrag AM ENDE der sshd_config waere dann:

PasswordAuthentication no
 
Match address 1.2.3.4/16
    PasswordAuthentication yes

SSH-Agent nutzen

Damit das ganze auch noch komfortabel ist und man nicht permanent das sichere Passwort fuer seinen SSH-Key eingeben muss, gibt es den praktischen ssh-agent. Dieser wird unter Linux in der Regel beim Starten des bevorzugten Desktop Environments mit gestartet. Man kann mit einem Agent mehrere Keys verwalten. Der Agent haelt die privaten Keys im Speicher und man kann diese dann zur Authentifizierung nutzen. Bei mir ist es inzwischen zur Routine geworden morgens nach dem starten meines Arbeitsplatzrechners ein Terminal zu oeffnen und die Keys fuer die Arbeit zu laden.
Der SSH-Agent wird mit dem Befehl ssh-add gesteuert. Folgende Befehle sind wichtig zu kennen:

  1. Auflistung der im Agent geladenen Keys:
    ssh-add -l
  2. Key nach Eingabe des korrekten Passworts in den Speicher laden:
    ssh-add ~/.ssh/example
  3. Entfernen aller Keys aus dem Agentspeicher:
    ssh-add -D

Aus der Praxis dazu noch die folgenden beiden Informationen:

  1. Wenn man auf einem Server ohne X mit einem SSH-Key arbeiten moechte und man den ssh-agent starten muss, dann geht das mit:
    exec ssh-agent bash
  2. Wenn man kurzfristig seinen ssh-agent mitnehmen moechte, dann geht das mit dem ssh Parameter -A. So kann man sich mit seinem Agent dann auf Host A authentifizieren, und wenn der Key auch auf Host B erlaubt ist kann man sich von Host A dann auf Host B ohne weitere Passworteingabe verbinden. Diese Option aber nur mit Vorsicht auf vertrauten Systemen einsetzen, da ein Angreifer mit root Rechten ansonsten auf Host A Angriffe auf die Keys im Speicher fahren koennte. Beispielaufruf des sehr praktischen Features:
    ssh -p 12345 -A user@foo.example.org

pam_wheel konfigurieren

Zu guter letzt noch ein Hinweis auf pam_wheel. Das PAM Modul erlaubt – sofern aktiviert – nur Mitgliedern der Gruppe wheel root Rechte zu erlangen. Das kann man sehr praktisch dazu nutzen auch root Rechte zu bekommen ohne das Passwort einzugeben. Wenn man zum Beispiel SSH nur Key Authentifizierung erlaubt und ein 20 Stellen bcrypt Hash als Passwort gesetzt ist und man sich diesen nicht merken moechte, dann kann man folgendes machen:

  • Gruppe anlegen:
    addgroup wheel
  • Nutzer hinzufuegen:
    adduser USERNAME wheel
  • die folgenden beiden Zeilen der /etc/pam.d/su oben bei den anderen auth Eintraegen hinzufuegen:
    auth requisite pam_wheel.so group=wheel
    auth sufficient pam_wheel.so group=wheel trust use_uid

Auch hier gilt wieder. Ausprobieren solange man angemeldet ist, ansonsten kann es unangenehm werden.

Vorherige Blogposts:

  • 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 bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.
  • Der vierte Teil drehte sich um das Thema Komfort im Webbrowser und verwies in dem Kontext auf einen Artikel zum selbst gehosteten Firefox Sync Server.
  • Im fuenften Teil habe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern geschrieben.

Howto: Clone LDAP Server

Alles Zeugs mit slapcat und slapadd hat bei mir nicht funktioniert. Nur zum festhalten:

$ slapcat -l ldapdump-$(date -I).ldif
$ slapadd -l ldapdump-$(date -I).ldif

Hier hat jemand wohl erfolg gehabt…

Was bei mir gut funktioniert hat war den neuen LDAP erst einmal mehr oder weniger so aufzusetzen wie den alten, also gleiche DN und schemas drin (dpkg-reconfigure slapd). Anschliessend habe ich mit ldapsearch auf dem alten Server alles exportiert und mit ldapadd auf dem neuen Server importiert:

$ ldapsearch -x -LLL > ldapdump-$(date -I).ldif
$ ldapadd -x -D "cn=admin,dc=example,dc=org" -W -f ldapdump-$(date -I).ldif

Der entscheidene Hinweis kam von hier.

— UPDATE 2013-07-31 —

Bei dem Export mittels ldapsearch sicherstellen, dass auch die userPassword: Eintraege mit exportiert werden. Ansonsten muss man sich gegebenenfalls authentifizieren zum Beispiel mit:

$ ldapsearch -x -LLL -H ldap://127.0.0.1:389 -D "cn=admin,dc=example,dc=org" -W | gzip > $(date -I)-ldapdump.ldif.gz

HowTo: Firefox Sync Server from Mozilla self hosted

Ich habe nun schon so einiges ueber einen selbstgehosteten Sync-Service fuer Firefox geschrieben:

  1. Firefox Lesezeichen ueberall – Selfmade!
  2. Howto: Der eigene Weave Minimal Server / Firefox Sync
  3. Update des eigenen Firefox Sync Servers

Nachdem ich seit neustem Besitzer eines Google Nexus 4 bin und gerne Firefox Sync auch unter Android benutzen moechte, war ich gezwungen mein aktuelles Setup zu aktualisieren auf die Originalimplementierung von Mozilla. Vorher wurde mir auf meinem Handy immer von Firefox gesagt, dass diese Version von Sync nicht mehrere Geraete unterstuetzt.

Ich bin auf diese Anleitung gestossen und unter Debian sieht das ganze wie folgt aus:

Installation

Installation von Paketen:

$ aptitude install python-virtualenv sqlite3 mercurial

Einrichten eines Benutzeraccounts:

$ adduser --system --home /opt/ffsync --shell /bin/false --group ffsync

Erstellen der benoetigten Verzeichnisse:

$ su ffsync
$ cd /opt/ffsync
$ mkdir {data,tmp}
$ chmod 775 tmp
$ hg clone https://hg.mozilla.org/services/server-full
$ cd server-full
$ make build

Konfiguration

Editieren und Anpassen der folgenden Konfigurationsdateien:

sync.wsgi

os.environ['PYTHON_EGG_CACHE'] = '/opt/ffsync/tmp/python-eggs'

developement.ini

[handler_syncserver_errors]
args = (‘/opt/ffsync/tmp/sync-error.log’,)

etc/sync.conf

[storage]
sqluri = sqlite:////opt/ffsync/data/sync.db
 
[auth]
sqluri = sqlite:////opt/ffsync/data/sync.db
 
[nodes]
fallback_node = http://sync.example.net/

Ich habe hier nun noch die Rechte fuer den Ordner gesetzt:

$ chown -R ffsync.www-data /opt/ffsync

Apache

Zum Schluss noch Apache einrichten um darueber alles laufen zu lassen. Dafuer:

$ aptitude install libapache2-mod-wsgi

Und einen entsprechenden vhost erstellen:

<VirtualHost *:80>
    ServerName sync.example.net
    ServerAdmin webmaster@example.net
    DocumentRoot /opt/ffsync/server-full
 
    CustomLog /var/log/apache2/ffsync_access.log combined
    ErrorLog /var/log/apache2/ffsync_error.log
 
        Order deny,allow
        Allow from all
 
    WSGIProcessGroup ffsync
    WSGIDaemonProcess ffsync user=ffsync group=ffsync processes=2 threads=25
    WSGIPassAuthorization On
    WSGIScriptAlias / /opt/ffsync/server-full/sync.wsgi
</VirtualHost>

Nach einem Neustart von Apache konnte ich dann das Geraet trennen und anschliessend mich neu mit dem Server verbinden. Achtet auf den Slash am Ende der URL. Es wurde alles automatisch synchronisiert. Auch die Synchronisation mit Firefox auf meinem Android Handy klappte problemlos.

Zum Schluss habe ich noch die Funktion deaktiviert, mit der sich neue Benutzer selbststaendig anmelden koennen. Dafuer in der /opt/ffsync/server-full/etc/sync.conf noch in der auth Sektion die entsprechende Option einkomentieren

[auth]
allow_new_users = false

Danke nochmal an OpenShots an dieser Stelle fuer die Anleitung :-)