Mehr Sicherheit fuer die eigenen Daten – verschluesseltes Backup

prego Schreib einen Kommentar

Dieses ist der siebte 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 sechs Artikeln befinden sich am Ende des Blogposts. Dieser siebte Teil behandelt das Thema Backup und zeigt eine Moeglichkeit wie man selbiges einfach konfiguriert und verschluesselt auf einem externen Speicher ablegen kann.

Natuerlich moechte ich von meinem Server ein Backup machen. Es waere aber dumm, wenn ich alle meine Daten die ich dort sammle und verschluesselt dorthin transportiere, anschliessend unverschluesselt auf einen Speicherplatz lege, den ich nicht selber ueberwache.
Bei mir ist es nun so, dass mir der Hostinganbieter (Hetzner) 100GB kostenlosen FTP Speicherplatz fuer Backups anbietet. Wenn ich den nutzen moechte muss ich also das Backup verschluesseln. Viele Jahre habe ich mit Backup Manager dort ein unverschluesseltes Backup abgelegt und war damit immer zufrieden. Das Projekt scheint inzwischen eingeschlafen zu sein, und durch meinen Arbeitskollegen bin ich auf duply hingewiesen worden. Ich moechte an dieser Stelle das Setup vorstellen, mit dem ich Full und Incremental Backups mit duply erzeuge und GPG verschluesselt auf dem Hetzner FTP Speicher ablege.

duply installieren

duply kann aus den Standardrepositories installiert werden:

aptitude install duply

Damit die Konfigurationsdateien unter /etc/duply/ und nicht unter ~/.duply/ liegen muss das Verzeichnis unter /etc angelegt werden:

mkdir /etc/duply

Als naechster Schritt wird ein neues Profil erzeugt. Ich habe dafuer den Hostname genommen:

duply create HOSTNAME

Die Konfigurationsdatei des Profils befindet sich nun unter /etc/duply/HOSTNAME/conf

GPG Key generieren und duply konfigurieren

Nun wird fuer die Verschluesselung des Backups ein GPG Key benoetigt. Mit dem folgenden Befehl wird ein neuer Key erzeugt. Ich habe alle voreingestellten Werte beibehalten:

gpg --gen-key

Wenn der Vorgang abgeschlossen ist wird etwas gesagt nach dem Motto: „Schluessel ABC123D4 ist als uneingeschraenkt vertrauenswuerdig gekennzeichnet“. Die Schluessel ID in diesem Fall merken und zusammen mit dem vergebenen Passwort in die /etc/duply/HOSTNAME/conf eintragen:

GPG_KEY='ABC123D4'
GPG_PW='B1-r6UF9s:Mb<%'

Der naechste wichtige Schritt ist in der Konfigurationsdatei anzugeben wo das Backup gespeichert werden soll. Dafuer gibt man – in diesem Fall den Hetzner FTP – wie folgt ein:

TARGET='ftp://u12345:abc123def456ghj7@u12345.your-backup.de/backup_HOSTNAME'

Ich habe bewusst einen Unterordner backup_HOSTNAME angegeben, damit ich auf den gleichen Speicher mehrere Hosts sichern kann und dabei nicht durcheinander gerate. Weiter habe ich die folgenden Optionen gesetzt, die ich hier inklusive Kommentare aus der Konfigurationsdatei aufliste::

# base directory to backup
SOURCE='/'
 
# Time frame for old backups to keep, Used for the "purge" command.  
# see duplicity man page, chapter TIME_FORMATS)
# defaults to 1M, if not set
MAX_AGE=3M
 
# Number of full backups to keep. Used for the "purge-full" command. 
# See duplicity man page, action "remove-all-but-n-full".
# defaults to 1, if not set 
MAX_FULL_BACKUPS=2
 
# verbosity of output (error 0, warning 1-2, notice 3-4, info 5-8, debug 9)
# default is 4, if not set
VERBOSITY=5
 
# activates duplicity --full-if-older-than option (since duplicity v0.4.4.RC3) 
# forces a full backup if last full backup reaches a specified age, for the 
# format of MAX_FULLBKP_AGE see duplicity man page, chapter TIME_FORMATS
# Uncomment the following two lines to enable this setting.
MAX_FULLBKP_AGE=1M
DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "
 
# sets duplicity --volsize option (available since v0.4.3.RC7)
# set the size of backup chunks to VOLSIZE MB instead of the default 25MB.
# VOLSIZE must be number of MB's to set the volume size to.
# Uncomment the following two lines to enable this setting. 
VOLSIZE=256
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "

Damit aber nicht das gesamte System gesichert wird wie oben unter SOURCE=’/‘ definiert, muss eine exclude Datei definiert werden. Diese liegt neben der conf Datei und sieht bei mir wie folgt aus:

/bin
/cdrom
/lib
/lib64
/media
/selinux
/sys
/usr
/boot
/dev
/lib32
/lost+found
/mnt
/sbin
/tmp
/var/archives
/var/cache
/proc

Damit habe ich alles fuer mich wichtige wie /etc, /home oder auch /var/www gesichert.

MySQL Dump vor Backup erstellen

duply bietet weiter die Moeglichkeit vor und nach dem Backup Kommandos auszufuehren. Dafuer muss neben der conf Datei eine oder auch die beiden Dateien pre und/oder post liegen. Dies sind Skripte die ausgefuehrt werden, es ist wichtig dass sie das auch sind (chmod ug+x pre). Ich erzeuge vor dem Backup damit einen Dump der Datenbanken auf dem Server. Das Skript sieht wie folgt aus:

#!/bin/bash
 
## create backup directory if not exist
if [ ! -d "/opt/backup" ]; then mkdir /opt/backup; fi
 
## delete old backup files older than 1 month
find /opt/backup -name "*.gz" -type f -mtime +31 -delete
 
## create dump of all databases
mysqldump --opt --routines --add-drop-database --default-character-set=utf8 --create-options --events --all-databases | gzip > /opt/backup/$(date -I)-all-databases.sql.gz

Das MySQL Zugangspasswort habe ich in der /root/.my.cnf abgespeichert:

[client]
password=B1-r6UF9s:Mb<%

Es befinden sich nun die folgenden drei Dateien unter /etc/duply/HOSTNAME/:

host:/etc/duply/HOSTNAME# ll
insgesamt 16
-rw------- 1 root root 4633  1. Sep 17:20 conf
-rw-r--r-- 1 root root  168  7. Aug 21:26 exclude
-rwxr-x--- 1 root root  415  1. Sep 17:30 pre
host:/etc/duply/HOSTNAME#

cron Eintrag anlegen

Damit jede Nacht das Backup ausgefuehrt und gegebenfalls alte Backupsets geloescht werden, habe ich die Datei /etc/cron.daily/duply_HOSTNAME erstellt:

#
# nightly duply backup of profile "HOSTNAME"
#

5 4 * * * root /usr/bin/duply HOSTNAME backup_verify_purge --force

weitere duply Befehle

Die folenden Befehle finde ich wichtig:

  • Status des Backups: 
    duply HOSTNAME status
  • Datei aus dem Backup wiederherstellen: 
    duply HOSTNAME fetch /path/to/my/file /tmp/restore
  • Datei von vor einer Woche aus dem Backup wiederherstellen: 
    duply HOSTNAME fetch /path/to/my/file /tmp/restore 7D
  • Alle Dateien im Backup auflisten von vor zwei Wochen die passwd enthalten: 
    duply HOSTNAME list 2W | grep passwd

Monitoring mit Nagios

Wenn man nun ueber eine Nagios Installation verfuegt, moechte ich an dieser Stelle noch auf zwei Checks hinweisen. Der erste ist check_duply um zu pruefen, ob das Backup auch wie gewuenscht durchgelaufen ist. Bei einer Pruefung ueber NRPE kann der Eintrag wie folgt aussehen:

command[check_backup]=sudo /usr/lib/nagios/plugins/check_duply -P HOSTNAME -w 36 -W 32 -c 48 -C 36

Die Parameter bedeuten:

  -w WARNINC   Number of hours allowed for incremental backup warning level
  -W WARNFULL  Number of days allowed for full backup warning level
  -c CRITINC   Number of hours allowed for incremental backup critical level
  -C CRITFULL  Number of days allowed for full backup critical level
  -P PROFILE   duply profile name

Der zweite Check ist check_ftpspace um zu ueberwachen, dass der FTP Speicher nicht volllaeuft. Wenn der Check ebenfalls ueber NRPE ausgefuehrt wird ist das hier ein beispielhafter Eintrag:

command[check_backupspace]=/usr/lib/nagios/plugins/check_ftpspace ftp://u12345.your-backup.de u12345 abc123def456ghj7 7000 15000 100000

Die Reihenfolge der Parameter setzt sich wie folgt zusammen:

HOSTNAME USER PASS WARN CRIT TOTAL

wobei die Werte fuer WARN CRIT und TOTAL jeweils MB sind.

Am Ende sei noch darauf hingewiesen, dass ich mir das nicht alles selber aus den Fingern gesaugt habe, sondern mich bei den folgenden Quellen bedient habe:

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.

HowTo: Change password on LUKS encrypted device

prego Schreib einen Kommentar

LUKS erlaubt bis zu 8 Keys, die in Slot 0-7 gespeichert werden koennen. Welche Slots belegt sind sieht man mit:

cryptsetup luksDump /dev/devicename

Einen neuen Key kann man mit dem folgenden Kommando hinzufuegen:

cryptsetup luksAddKey /dev/devicename

Einen vorhandenen Key kann man mit dem folgenden Kommando loeschen:

cryptsetup luksRemoveKey /dev/devicename

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

prego Ein Kommentar

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.

Mehr Sicherheit fuer die eigenen Daten – sichere Zugangsdaten / Passwoerter

prego 4 Kommentare

Dieses ist der fuenfte 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 vier Artikeln befinden sich am Ende des Blogposts. Im diesem fuenften Teil schreibe ich etwas zu meinen Ueberlegungen zu sicheren Zugangsdaten und Passwoertern.

Ich gebe zu: Ich war faul! Ja, ich hatte Standardpasswoerter unterschiedlicher Staerke und unterschiedlichen Typs, die ich an verschiedenen Stellen wiederholt habe. Ich weiss, es ist boese, ich habe es aber trotzdem getan.

Wenn man ueber Einbrueche bei Diensten im Internet und die damit verbundene Aufforderung doch bitte sein Passwort zu aendern liesst, dann wird meistens gesagt, das wenn man die Kombination aus Benutzername und Passwort noch woanders genutzt hat, das man ueberall dort zur Sicherheit das Passwort aendern muss. Daraus ist relativ einfach zu schliessen, dass man die Kombination aus Benutzernamen und Passwort nie zweimal verwenden sollte. Der Haken an der Sache ist aber, das man sich die ganzen Passwoerter ja auch merken koennen muss. Aus diesem Grund kann man entweder ein Passwortschema benutzen, oder man generiert wirklich konsequent Zufallspasswoerter. Diese Passwoerter kann mann dann zum Beispiel im Webbrowser speichern oder man notiert sie sich in einer Datei in einem verschluesselten Container.

Ich habe mich fuer eine Kombination aus verschiedenen Modellen entschieden, die fuer mich am praktischsten ist. Als erstes verwende ich bei Diensten als Benutzername nach Moeglichkeit eine Emailadresse. Da ich alle meine Emails ueber einen eigenen Mailserver versende lege ich mir fuer jeden neuen Account einen neuen Alias an. Das ist zwar zu Anfang nervig, hat aber den witzigen Nebeneffekt, das man sofort mitbekommt wo die eigene Emailadresse unautorisiert weitergegeben wurde ;-). Der Zugangsname ist also in der Regel unterschiedlich.

Bei den Passwoertern habe ich lange ueberlegt wie ich es mache, und habe mich am Ende fuer einen webbasierten Passwortgenerator entschieden, den ich bei mir auf meinem eigenen Server installieren kann. Dort wird aus der Kombination von Benutzername, Domain und eigenem Passwortstring ein bcrypt Hash gebildet, den ich dann als Passwort nutze. Weitere Informationen zu dem Tool gibt es hier:

Leider sind die bcrypt Hashes in der freien Wildbahn manchmal schon zu sicher, da sie Zeichen enthalten, die bestimmte Dienste nicht erlauben. Dies liegt (meistens) an der verwendeten Programmiersprache. In WordPress ist zum Beispiel kein Backslash erlaubt. Diese unerlaubten Zeichen filtere ich von Hand aus dem generierten Hash heraus. Da ich die Passwoerter ja aber sicher abgespeichert habe muss ich sie nicht oft generieren. Wenn ja, muss ich fuer zusaetzliche Sicherheit damit leben, dass ich mir manche Passwoerter erst zusammenbasteln muss.

Am Ende habe ich aber wieder zwei Arten von Passwoertern. Einmal die bcrypt Hashes, die ich nach Moeglichkeit ueberall verwende. Aber mal ehrlich, wer moechte sich Passwoerter wie:

  • B1-r6UF9s:Mb<% (test, test, test im Generator)

schon gerne merken um es bei Firefox als Masterpasswort oder beim verschluesselten Container als decrypt Phrase einzugeben? Ich nicht! Aus diesem Grund existiert auch weiterhin ein einfach zu merkendes, aber dennoch nach den Regeln der Kunst sicheres Passwort in meinem Kopf, das je nach genutztem Dienst noch etwas hinten dran bekommt.

Durch die Kombination aus moeglichst jeweils unterschiedlichem Loginnamen, bcrypt Hashes als Passwoertern und nur ganz minimal gebrauchtem sicheren Passwort in meinem Kopf habe ich einiges an Sicherheit gewonnen. Nach und nach wechsle ich nun ueberall meine Passwoerter auf dieses neues System.

 

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.