Andre's blog » GPG

Verschlüsselte Backups mit duply

Andre — Sun, 19 Sep 2010 10:16:03 +0000

Weit über ein Jahr ist es her, daß ich über die Erstellung von verschlüsselten Backups mit Hilfe von ftplicity geschrieben habe. Mittlerweile erstelle ich die Backups mit duply und duplicity. duply ist ein Frontend für duplicity und erleichert ein wenig die Arbeit.
Grundsätzlich gehe ich immer von einem klassischen Debian aus, dem entsprechend müssen ein paar Pakete zusätzlich installiert werden.

aptitude install python-dev librsync-dev ncftp

Damit sind die Grundvoraussetzungen geschaffen und wir können uns duplicity holen:

cd /usr/src
wget http://code.launchpad.net/duplicity/0.6-series/0.6.09/+download/duplicity-0.6.09.tar.gz
tar xfz duplicity-0.6.09.tar.gz
cd duplicity-0.6.09
python setup.py install

Das ging schnell, jetzt wird es noch schneller!

cd /usr/src
wget http://downloads.sourceforge.net/project/ftplicity/duply%20%28simple%20duplicity%29/1.5.x/duply_1.5.2.3.tgz
tar xfz duply_1.5.2.3.tgz
cd duply_1.5.2.3
cp duply /usr/local/bin

Aus dem Archiv die Datei duply entpacken und in /usr/(s)bin oder /usr/local/(s)bin kopieren.
Grundsätzlich ist duply nun funktionsbereit, es fehlt jedoch nocht der GPG-Schlüssel. Ohne diesen läuft nichts.

gpg --gen-key

Die Standardvorgabe für die Schlüsselart ist in Ordnung und kann mit [ENTER] bestätigt werden. Die Schlüsselgröße 2048 ist auch in Ordnung, wer mehr will, kann auch auf 4096 gehen. Der Schlüssel soll niemals ungültig werden, also bestätigen wir mit y die Gültigkeit “läuft niemals ab”. Zum Schluß noch Angaben wie Name und eMail und das Ganze mit O bestätigen.
Jetzt wird der Schlüssel generiert. Unter Umständen kann das mal ein paar Minuten dauern, je nach dem, wieviel auf dem Server los ist. Die Nummer des generierten Schlüssels müssen wir uns merken und im Folgenden in die Konfiguration von duply einfügen.
Hier eine Beispielausgabe von gpg mit einer zufälligen Schlüselnummer:
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 73FA48DA marked as ultimately trusted
public and secret key created and signed.

Nun erstellen wir eine Grundkonfiguration:

duply bkprofil create

bkprofil ist ein frei wählbarer Name des Backup-Profils.
Nun wurde, sofern wir duply als root ausgeführt haben, im ordner /root/.duply der Ordner bkprofil angelegt. Innerhalb dieses Ordners ist nun die Konfigurationsdatei conf. Hier wollen wir ein paar Einstellungen vornehmen.

nano /root/.duply/bkrpofil/conf

Wichtig sind hier die ID vom GPG-Key (GPG_KEY) und das entsprechende Passwort (GPG_PW). Bei den GPG_OPTS schalte ich die als Standard vorgegebene bzip2-Komprimierung mit Level 9 ein. (GPG_OPTS=’–compress-algo=bzip2 –bzip2-compress-level=9′)
In der Konfiguration sind Beispiele für das “Target” aufgeführt, also der Ziel-Server, auf dem das Backup abgelegt werden soll. Am weitesten verbreitet dürfte FTP sein, daher geben wir hier als Ziel einen FTP-Server vor: TARGET=’ftp://SERVER/VERZEICHNIS’
TARGET_USER und TARGET_PASS sind denke ich selbsterklärend.
SOURCE gibt an, welcher Ordner gesichert werden soll. Entweder man trifft hier schon eine Vorauswahl, z.B. /srv oder man nimmt das gesamte Dateisystem ‘/’ und verfeinert die Auswahl später. Ich nehme hier SOURCE=’/’ und spezifiziere später in einer anderen Datei die zu sichernden Dateien.
MAX_FULL_BACKUPS stellt die Anzahl der vorgehaltenen vollen Backups an. Je nach verfügbarem Speicherplatz und eigenen Wünschen kann hier gewählt werden, sinnvoll ist denke ich der Bereich zwischen 1 und 3.
Wenn MAX_FULLBKP_AGE gesetzt ist, wird automatisch bei erreichen dieser Zeit ein Vollbackup erstellt, anderenfalls ein inkrementelles Backup. Wird MAX_FULLBKP_AGE auf 2W gesetzt, wird beim ersten Aufruf von duply ein voller Backupsatz erstellt. Beim Aufruf z.B. am nächsten Tag wird der volle Satz erkennt und ein inkrementelles Backup gestartet. Sind nun 2 Wochen abgelaufen, wird wiederum ein neues, volles Backup angelegt.
Mit VOLSIZE wird die Größe der einzelnen Archivdateien eingestellt. Meine Favoriten sind 500 oder 750, also 500MB bzw. 750MB. Selbstverständlich kann hier auch mehr angegeben werden.

Würde jetzt ein Backup gestartet, würde der komplette Server gesichert werden, das ist nicht unbedingt immer gewünscht. Daher lege ich nun eine weitere Datei an, um mein Backup zu verfeinern.

nano /root/.duply/bkrpofile/exclude

+ /home
+ /var/www
- /

Diese drei Zeilen geben an, daß die Ordner /home und /var/www gesichert werden sollen. Das geschieht natürlich inklusive der jeweiligen Unterordner. Der Ordner / wiederum soll nicht gesichert werden, d.H. der gesamte Rest wird ausgeschlossen.

Nun steht dem ersten Backup nichts mehr im Wege.

duply bkprofil backup

Nun wird das bzip2-komprimierte und mit GPG verschlüsselte Backup erstellt und die Archive auf den FTP-Server geschoben.
Ist das Backup durchgelaufen, schauen wir uns einmal das Ergebnis an:

duply bkprofile status

Found primary backup chain with matching signature chain:

-------------------------
Chain start time: Sun Sep 19 09:02:01 2010
Chain end time: Sun Sep 19 09:02:01 2010
Number of contained backup sets: 1
Total number of contained volumes: 7
 Type of backup set:                            Time:      Num volumes:
 Full         Sun Sep 19 09:02:01 2010                 7
-------------------------
No orphaned or incomplete backup sets found.

Das Backup wurde mit 7 Archiven erstellt, keine unvollständigen Backupsätze gefunden. Sobald inkrementelle Backups angelegt wurden, werden diese hier entpsrechend angezeigt.
Den genauen Inhalt des Backups können wir uns wie folgt anschauen:

duply bkprofile list

Jedoch empfehle ich die Umleitung in eine Datei, da sie einfacher zu durchsuchen ist.

duply bkprofile list > output.txt

Zum Schluß automatisieren wir unsere Backups noch mit cron.

crontab -e

30 0 * * * /usr/local/bin/duply bkprofile purge-full --force
30 1 * * * /usr/local/bin/duply bkprofile backup

Hier wird jetzt jeden Tag um 0:30h das Kommando purge-full durchgeführt, d.H. sobald mehr als MAX_FULL_BACKUPS Vollbackupsätze vorhanden sind, werden die älteren Sätze gelöscht. Der Schalter –force gibt an, daß die Dateien nicht nur gelistet sondern auch gelöscht werden sollen.

Um 1:30h startet das eigentliche Backup.

So weit, so gut! Die Backups laufen und wir hoffen, daß wir sie nicht wirklich benötigen werden, doch wie man an seine Dateien im Ernstfall wieder heran kommt, beschreibe ich in der Fortsetzung.

public key für apt-get importieren

Andre — Mon, 16 Feb 2009 16:57:48 +0000

Es ist so weit! Debian lenny ist draußen! Wer jetzt sein System upgraden will, wird unweigerlich die Fehlermeldung

W: There is no public key available for the following key IDs:
4D270D06F42584E6
W: Probieren Sie „apt-get update“, um diese Probleme zu korrigieren.

erhalten. Der unbekannte Schlüssel lässt sich ganz einfach importieren:

gpg --recv-key --keyserver wwwkeys.eu.pgp.net 4D270D06F42584E6
gpg --export 4D270D06F42584E6|apt-key add -

Jetzt ist der public key im System bekannt und mit einem erneuten apt-get update ist alles wieder im Reinen.
Einem

apt-get update
apt-get dist-upgrade

steht nun nichts mehr im Wege.

Viel Erfolg!

Verschlüsseltes Backup mit ftplicity – Teil 1

Andre — Sat, 24 Jan 2009 18:34:30 +0000

Backups sind so lebenswichtig wie die Luft zum Atmen, wie der Strom für den Server.
Die meisten Web- bzw. Hostingdienstleister bieten in der Regel Speicherplatz auf einem FTP-Server an – einen FTP-Server, auf den viele andere Kunden Zugriff haben. Wer sonst noch Zugang zu diesem Server hat … man weiß es nicht. Daher ist man gut beraten, wenn man seine Daten dort nicht ungeschützt ablegt. Ein sehr hilfreiches Tool für diese Aufgabe ist ftplicity. Ftplicity legt mit Hilfe von GnuPG und duplicity verschlüsselte Backups auf einem FTP-Server ab.

Zuerst ggf. noch nicht installierte, benötigte Pakete installieren:

apt-get install python-dev librsync-dev ncftp python-gnupginterface python-pexpect

Danach holen wir uns duplicity an Bord:

cd /usr/src                                                                                                                                                                
wget http://savannah.nongnu.org/download/duplicity/duplicity-0.5.02.tar.gz                                                                                                 
tar xfvz duplicity-0.5.02.tar.gz                                                                                                                                           
cd duplicity-0.5.02                                                                                                                                                        
python setup.py install

Ich habe leider die Feststellungmachen müssen, daß die z.Zt. aktuelle Version 0.5.0.6 mit Debian etch leider nicht funktioniert, daher die v0.5.0.2. Für Hinweise, wie die aktuelle Version unter etch zum Laufen gebracht werden kann, würde ich mich freuen.
Wenn die Installation ohne Fehler durchgelaufen ist, kümmern wir uns um den GPG-Schlüssel:

gpg --gen-key

Die Schlüsselart, welche als standard eingestellt ist (DSA und Elgamal) ist in Ordnung und kann mit [enter] bestätigt werden.
Die Standardschlüsselgröße 2048 reicht im Regelfall auch aus, wer möchte, kann auf 4096 erhöhen.
Damit wir nicht vergessen, die Schlüssel rechtzeitig zu verlängern, wählen wir auch bei der Gültigkeit den Standard, also “läuft niemals ab”. Diese Auswahl noch einmal mit y bestätigen.
Um den Schlüssel leichter identifizieren zu können, vergeben wir einen Namen und eMail-Adresse, ggf. auch einen Kommentar. Wenn die Angaben in Ordnung sind, wird mit O bestätigt.
Zum Abschluß muß ein Passwort für den Schlüssel vergeben werden. Bitte gut merken! Danach wird der Schlüssel berechnet. In der Ausgabe von gpg notieren wir uns die Schlüssel-ID, welche im folgenden als zufälliges Beispiel fett geschrieben steht.
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 57FG85AC marked as ultimately trusted
public and secret key created and signed.

Jetzt geht es weiter mit fplicity.

cd ..
wget http://heanet.dl.sourceforge.net/sourceforge/ftplicity/ftplicity_1.4.1b.tgz
tar xfvz ftplicity_1.4.1b.tgz
cp ftplicity_1.4.1b/ftplicity /usr/local/bin

Das ging kurz und schmerzlos. Jetzt können wir uns ein Profil für das Backup anlegen.

ftplicity backup_profile create
chmod 600 /root/.ftplicity/backup_profile/conf
nano /root/.ftplicity/backup_profile/conf

Den Namen backup_profile habe ich frei gewählt, hier können nach Belieben andere Bezeichnungen verwendet werden. In die Config-Datei werden gleich zu Anfang die GPG-Schlüssel-ID und das dazu passende Passwort eingetragen, darunter die Zugangsdaten und das Zielverzeichnis vom FTP-Server. Wichtig ist auch der SOURCE-Eintrag, dort wird das Wurzelverzeichnis eingetragen, ab wo gesichert wird. “/” für das gesamte Dateisystem, “/home” z.B. nur für die Userverzeichnisse. Mehr dazu im Folgenden.

Bei GPG_OPTS kann die Komprimierung eingeschaltet werden. Hierzu einfach den ‘#’ vor der Zeile entfernen.

GPG_OPTS=’–compress-algo=bzip2 –bzip2-compress-level=9′

Die weiteren Parameter sind eigentlich gut erklärt. Folgender Parameter sollte jedoch noch geändert werden:

VOLSIZE=250
DUPL_PARAMS=”$DUPL_PARAMS –volsize $VOLSIZE ”

VOLSIZE gibt die Größe der einzelnen Sicherungsdateien an. Die Größe sollte nicht zu klein, aber auch nicht zu groß gewählt werden. Bei zu kleinen Dateigrößen werden für ein größeres Backup sehr viele Dateien erzeugt, bei zu großen Dateien kann es Übertragungsprobleme geben und das Backup wird mit einer Fehlermeldung (broken pipe) abgebrochen. Je nach Verbindung ist eine Größe von 250 bis 500 MB angebracht. Nicht vergessen, bei der Zeile DUPL_PARAMS= [...] unter VOLSIZE das ‘#’ zu entfernen.
Wer den Komfort von ftplicity nutzen möchte, aber auf die Verschlüsselung verzichten will, kann in der letzten Zeile der conf-Datei folgendes eintragen:

DUPL_PARAMS=”$DUPL_PARAMS –no-encryption”

So wird das Backup nicht verschlüsselt.

Eine weitere wichtige Datei ist die exclude-Datei. Hier können Dateien und Verzeichnisse angegeben werden, welche nicht gesichert werden sollen. Das Thema eclude bzw. include ist recht komplex und ist im Netz vielfach beschrieben, daher hier nur ein kleines Beispiel einer exclude-Datei.

nano /root/.ftplicity/backup_profile/exclude

+ /etc
+ /var/www
- /

Als SOURCE hatten wir “/” angegeben, also das Wurzelvereichnis, es würden also alle Dateien gesichert werden. In diesem Beispiel werden nur die Verzeichnisse /etc und /var/www inklusive ihrer Unterverzeichnisse, also z.B. /var/www/vhost/domain.tld, gesichert, “/” wird an letzter Stelle (!) wieder komplett ausgeschlossen. Es werden nur die Verzeichnisse, welche explizit mit “+” angegeben wurden, gesichert. Im umgekehrten Fall kann man auch einzelne Verzeichnisse, Dateien oder Dateitypen ausschließen.

Es ist Zeit für einen ersten Probelauf:

ftplicity backup_profile backup --preview

Werden keine Fehlermeldungen ausgeworfen, dann kann es losgehen. Einfach den preview-Schalter entfernen.

ftplicity backup_profile backup

Sobald das Backup fehlerfrei durchgelaufen ist, können wir den Status der Backups überprüfen.

ftplicity backup_profile status

Hier werden die Anzahl der Volumes und die einzelnen Backups (full, incremental) angezeigt, ggf. auch unvollständige Backups.
War das Backup erfolgreich, können die gesicherten Dateien mit

ftplicity backup_profile list

angezeigt werden. Da es im Normalfall mehrere Tausend Dateien sind, ist es ratsam, die Ausgabe in eine Datei umzuleiten.

ftplicity backup_profile list > output.txt

Im zweiten Teil beschäftige ich mich mit dem Einrichten eines cron-Jobs für tägliche Backups sowie mit der Wiederherstellung von Dateien.

De-Mail … und der Staat liest mit.

Andre — Wed, 07 Jan 2009 15:35:10 +0000

Wie würde ein bekannter Comedian das Thema kommentieren? “Ja nee, is’ klar!”
Für wie gutgläubig hält der Staat seine Bürger eigentlich? Nun, das eine sei ihm zugestanden: man kann es ja mal versuchen.
Vielleicht sollten die Politiker zuerst in den neuen Bundesländern anfangen, die Werbetrommel zu rühren. Die Bürger werden gerade dort bestimmt sofort zustimmen und sich wohl dabei fühlen, das letzte Bisschen Privatsphäre auch noch dem Staat zu überlassen, haben sie doch alle noch in Erinnerung, wie sehr sich der Staat um die Privatsphäre seiner Bürger bemüht.
Wer bitte soll einem Politiker Glauben schenken, daß seine Daten sicher seien, der den Bundestrojaner befürwortet?
Wer soll den durchführenden Unternehmen Glauben schenken, die selber in der letzten Zeit durch Datenskandale und Bespitzelungen der eigenen Mitarbeiter aufgefallen sind?
Wer bitte soll dem Staat noch glauben, daß die Einführung des neuen Systems funktioniert? Ich erinnere an dieser Stelle nur mal an das so hoch gelobte Mautsystem.
Warum das Rad neu erfinden? GnuPG und PGP tun bereits erfolgreich ihren Dienst und bei GnuPG kann ich wenigstens hinter die Kulissen schauen und weiß, von wem das Ganze kommt und was dahinter steckt. Bei De-Mail weiß keiner, was mit den privaten Daten passiert und wer den “Generalschlüssel” dafür bekommt. Durch die eMail-Adresse wird der Bürger eindeutig identifizierbar und auf einfachstem Wege weiß er Staat dann ganz genau, wer mit wem und wann, was …

Ich kann nur hoffen, daß das Gros der Bürger den Wolf im Schafspelz erkennt und die Finger davon lässt. Es wird sicherlich Versuche seitens des Staates geben, die Nutzung von De-Mail zu forcieren, sei es, daß Steuererklärungen zukünftig nur noch mittels De-Mail abzugeben sind oder man bei Neuausstellung eines Personalausweises diese eMail-Adresse gleich zwangsweise auf’s Auge gedrückt bekommt. Ich für meinen Teil nutze weiterhin GPG und bin damit sehr zufrieden. Für viele (gute) eMail-Clients gibt es bereits GPG-Unterstützung oder Plugins. An dieser Stelle seien nur einmal Thunderbird und das entsprechende Plugin Enigmail genannt, welche für Mac, Linux und Windows erhältlich sind.

Sicher mailen mit dem Mac

Andre — Sun, 04 Jan 2009 10:34:31 +0000

Jetzt mal ehrlich: Würden Sie Ihre Kontodaten, die Kreditkartennummer oder ähnliches auf einer Postkarte verschicken? Nicht? Aber per eMail haben Sie sicherlich keine Einwände und tippen munter drauf los!
Spätestens seit der Diskussion über die Vorratsdatenspeicherung sollten die meisten User doch mißtrauisch geworden sein. In dem nun folgenden Artikel beschreibe ich kurz und bündig, wie mit Apple Mail und GnuPG der Versand von Mails sicherer wird und Mails verschlüsselt werden können.

Wir benötigen GnuPG (z.Zt. in der Version 1.4.8 oder gpg2) sowie GPG Schlüsselbund (z.Zt. Version 0.7.0). Die Downloads gibt es bei Sourceforge.

Das wichtigste ist das Plugin GPGMail für Apple Mail. Den Download gibt es hier.

GnuPG und GPG Schlüsselbund sind schnell und unproblematisch installiert. Für Das Mail-Plugin muß ggf. ein neuer Ordner erstellt werden. Den Ordner $HOME/Library/Mail/Bundles bei Bedarf erstellen und GPGMail.mailbundle dort hineinkopieren.

In einem Terminal-Fenster muß nun folgendes ausgeführt werden:

defaults write com.apple.mail EnableBundles -bool true
defaults write com.apple.mail BundleCompatibilityVersion 3

Detaillierte und aktuelle Informationen zur Installation sind auf der Homepage von GPGMail zu finden.

Nun starten wir GPG Schlüsselbund. Da noch kein privater Schlüssel vorhanden ist, kommt eine entsprechende Meldung.

Mit “Anlegen” wird der Assistent gestartet. Im folgenden Schritt sollte das Häkchen für “Assisten verwenden” gesetzt sein. Für den privaten Schlüssel nutzen wir “DSA und ElGamal”, 1024 reichen normal als Schlüssellänge, mit 2048 ist man aber auch in der nächsten Zeit auf der sicheren Seite.
Möchte man den Schlüssel mit einem Ablaufdatum versehen, kann man dies im nächsten Schritt eingeben. Seit der Version 0.7.0.1 kann man sogar automatisch einen Eintrag in iCal generieren lassen, um an den ablaufenden Schlüssel erinnert zu werden.
Im nächsten Schritt werden nun Name und Mailadresse eingetragen, ggf. auf ein Kommentar.
Im folgenden Schritt muß ein Passwort für den zu erzeugenden Schlüssel angegeben werden. Bitte wähle ein anständiges Passwort! Der Name der Frau oder gar der eigene sind denkbar ungünstig. Ein anständiges Passwort besteht aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen.
Nach der zweimaligen Eingabe des Passwortes und Überprüfung der Angaben startet die Generierung des Schlüssels. Das kann je nach gewählter Schlüsselgröße einige Zeit in Anspruch nehmen. Nach dem Klick auf “Fertig” ist der Schlüssel angelegt und erscheint in der Übersicht vom GPG Schlüsselbund. Dort sind der öffentliche und der geheime Teil des Schlüssels einsehbar.

Mail kann nun neu gestartet werden und sollte im Menü “E-Mail” mit dem Unterpunkt “PGP >” aufwarten.

Apple Mail ist jetzt fertig eingerichtet und ist nun in der Lage, mit GPG signierte oder verschlüsselte Mails zu senden und empfangen.
Die weiteren Schritte, wie verschlüsselte Mails verschickt werden, beschreibe ich in einem weiteren Artikel.