Admins stehen oft vor der Aufgabe, Backups möglichst schnell zurückzuspielen. Dabei ist es nicht besonders effizient, jedes Mal das Tape-Drive anzuwerfen. Das Werkzeug Rsync sichert kritische Bereiche auf einem zweiten Rechner. Sie wiederherzustellen ist eine Sache von Minuten. SSH sorgt für sichere Transfers.

Wie der vorige Admin-Workshop[1] gezeigt hat, sollten Komplettbackups auf separaten Datenträgern Teil jeder Backup-Strategie sein. Aber je öfter Nutzer auf Daten (schreibend) zugreifen, desto höher ist die Wahrscheinlichkeit, dass sie versehentlich Dateien löschen. Eine Sicherung auf Tapes, CDs oder DVDs ist im Fall der Fälle nur umständlich zurückzuspielen. Es ist daher sinnvoll, zusätzlich Online-Backups zu verwenden, die nur den Aufruf eines Skripts zur Rücksicherung benötigen. Dazu gibt es bereits fertige Lösungen wie Rsnapshot[2]. Dieser Admin-Workshop zeigt die Details dieser Vorgehensweise.

Kooperation

Die Übertragung zu sichernder Dateien übers Netz auf einen zweiten Rechner übernimmt das praktische Programm Rsync in Zusammenarbeit mit SSH. Die Werkzeuge lösen für Admins gleich zwei Probleme: Sie sparen erstens Bandbreite, da Rsync auf Wunsch Daten komprimiert, und zweitens gewährleistet SSH, dass Lauscher im Netzwerk nicht an die Backups herankommen.

Um Bandbreite und Plattenaktivität zu sparen, bieten sich zudem inkrementelle Backups an. Leider haben sie den Nachteil, dass eine Rücksicherung ohne entsprechende Software sehr aufwändig ist. Rsync schafft Abhilfe, indem es zwar nur die veränderten Daten überträgt, diese aber in das letzte Komplettbackup auf der Zielmaschine einarbeitet.

Um herauszufinden welche Daten sich seit dem letzten Lauf geändert haben, vergleicht Rsync entweder eine Kombination aus Dateigröße und Zeitstempel oder die MD4-Prüfsumme jeder einzelnen Datei. Als besonderes Bonbon benutzt Rsync bei großen Dateien einen raffinierten Mechanismus, der nicht die ganze Datei kopiert, sondern nur die geänderten Teile.

Den Versand des Backups durchs Netzwerk übernimmt nicht Rsync selbst, sondern der Anwender schaltet einen beliebigen Tunnel zwischen. Früher war das in der Regel die Remote-Shell »rsh«. Mittlerweile ist jedoch SSH[3] für den Job besser geeignet, da es die Daten auf ihrem Weg verschlüsselt. Abbildung 1 illustriert die Funktionsweise eines Backups mit Rsync und SSH.

Um Rsync auch in unsicheren Umgebungen möglichst abzusichern, ist es nötig, den SSH-Dienst entsprechend zu konfigurieren. Denn wer hier Fehler macht, handelt sich unter Umständen unberechtigte Zugriffe auf seine Systeme ein. Als Nachfolger der Remote-Shell dient SSH primär der Fernadministration. Der Aufruf »ssh Benutzer@ Hostname« führt den Benutzer zu einem Shellprompt auf dem Rechner » Hostname«.

Schlüssel sind besser

Ohne spezielle Vorkehrungen zieht SSH zur Authentifizierung das Userpasswort heran. Außerdem muss sich auch der Server, auf dem sich ein User einloggt, ausweisen; dazu nutzt SSH kryptographische Algorithmen. Nachdem sich die Beteiligten erfolgreich authentifiziert haben, wandern alle Daten verschlüsselt durch die Leitung.

Admins wollen aber ihre Backup-Skripte nicht immer von Hand starten, nur weil sie ihr SSH-Passwort eingeben müssen. Normalerweise übernimmt Cron die Aufgabe, Backup-Läufe automatisch zu starten. Ein Passwortprompt ist dabei äußerst hinderlich. Als Abhilfe eignet sich ein Authentifizierungsmodus, bei dem die Anmeldung nicht mehr über das Passwort, sondern über ein asymmetrisches Schlüsselpaar erfolgt. Das Schlüsselpaar aus einem öffentlichen und einem privaten Teil identifiziert einen bestimmten Nutzer.

Abbildung 1: Rsync erstellt Backups und schickt diese per SSH an einen zweiten Rechner. SSH erhält seine Daten dabei über eine einfache Pipe. Auf der Gegenseite leitet der SSH-Daemon das Backup an den Rsync-Prozess weiter. Unveränderte Dateien überträgt Rsync nicht und spart somit viel Bandbreite.

Der Befehl »ssh-keygen -t dsa« erzeugt ein asymmetrisches DSA-Schlüsselpaar. Der private Teil, den das Programm per Voreinstellung in »~/.ssh/id_dsa« abspeichert, verbleibt auf dem lokalen Rechner. Den öffentlichen Teil »~/.ssh/id_dsa.pub« kopieren Benutzer auf alle Rechner, an denen sie sich einloggen wollen (siehe Abbildung 2). Dazu speichern sie den Inhalt des öffentlichen Schlüssels auf dem Zielrechner in der Datei »~/.ssh/authorized_keys«. In diesem File dürfen sich durchaus auch mehrere Schlüssel befinden, je nachdem, ob der Benutzer mehrere Key-Paare benutzt.

Von nun an findet die Authentifizierung über das deutlich sicherere asymmetrische Key-Verfahren statt. Für den Benutzer Root ist ein Login in der Regel aber nicht erlaubt. Der SSH-Daemon ignoriert die Datei »/root/.ssh/authorized_keys«. Wollen Admins es Root dennoch erlauben, sich per SSH einzuloggen, setzen sie die Variable »PermitRootLogin« in der Datei »/etc/ssh/sshd_config« auf »yes«.

Automatische Logins

Das Programm »ssh-keygen« fragt beim Erzeugen von Schlüsselpaaren nach einer Passphrase. Die benutzt es, um den privaten Key selbst zu verschlüsseln. Denn jeder Angreifer, der Zugriff auf das Homeverzeichnis eines Users erlangt, könnte sonst den privaten Schlüssel nutzen, um sich auf weiteren Rechnern einzuloggen (Abbildung 3).

Für ein automatisch ablaufendes Skript ist die Eingabe einer Passphrase natürlich nicht möglich. Deswegen akzeptiert »ssh-keygen« es auch, wenn der Nutzer keine Passphrase eingibt. Der private Schlüssel liegt dann ungesichert auf der Platte. Sicherer ist es, einen SSH-Agent einzusetzen. Er entschlüsselt private Keys nach Eingabe der Passphrase und speichert sie im RAM. Wer Zugriff auf den laufenden »sshagent« hat, darf die privaten Schlüssel verwenden. Angreifer müssten direkt den Hauptspeicher auslesen, um an sie heranzukommen.

Wer den Agent für Cron und andere Skripte nutzen möchte, ruft »ssh-agent« einmalig entweder während oder direkt nach dem Booten auf und leitet die Ausgabe in eine Datei. In dieser stehen dann zwei Umgebungsvariablen, die SSH dazu nutzt, auf den Agent zuzugreifen. Die Datei baut der Admin in seine Umgebung mit dem ».«-Befehl ein, dann folgen »ssh-add« und die Passphrase. Der Agent hat nun den privaten Schlüssel in seinem Speicher:

$ ssh-agent >~mas/tmp/agent.sh
$ . ~mas/tmp/agent.sh
Agent pid 21681
$ ssh-add
Enter passphrase for /Users/mas/.ssh/id_dsa:
$

Jedes Programm, das Zugriff auf den Agent wünscht, übernimmt jetzt nur noch die erstellte kleine Datei.

Rsync tunnelt

Zusätzlich zum einfachen Login an einem entfernten Rechner beherrscht SSH eine für das Backup sehr wichtige Funktion: Es leitet sämtliche Daten, die es per Pipe als Eingabe bekommt, an den entfernten SSH-Daemon weiter, über die verschlüsselte Verbindung.

01 #!/bin/sh
02 
03 . ~mas/tmp/agent.sh
04 /usr/bin/rsync -rlptH --delete /Users/ backupuser@backuphost:/export/backup

01 #!/bin/sh
02 
03 AGENT=/root/agent.sh
04 
05 # $AGENT muss mir (Root) gehören und darf nicht beschreibbar sein.
06 # Sonst: abbrechen!
07 [ -O $AGENT -a ! -w $AGENT ] || exit 255
08 
09 # Wenn alles in Ordnung ist, einlesen und Verbindung zum
10 # SSH-Agent ermöglichen
11 
12 . $AGENT
13 
14 /usr/bin/rsync -rlHpt --delete /Users/ backupuser@backuphost:/export/backup

Abbildung 2: SSH benutzt ein symmetrisches Verschlüsselungsverfahren. Dazu müssen zwei Schlüssel, jeweils einer auf dem Server und einer auf dem Client, zueinander passen. Das Übertragen der Passwörter durchs Netzwerk entfällt.

Ein Verzeichnis lässt sich auf diese Weise mit einer einzigen Befehlszeile auf andere Computer übertragen: »cd Verzeichnis && tar cf – . | ssh Benutzer@ Computer tar xf -«. Die mit »tar« erzeugte Datei erhält SSH per Pipe und leitet sie an den entfernten SSH-Daemon weiter, der das Archiv per Tar-Aufruf wieder auspackt. Auch Rsync nutzt dieses Verfahren. Der Parameter »-e ssh« fordert Rsync dazu auf, alle Dateien an SSH weiterzuleiten. Alternativ setzt man die Umgebungsvariable »RSYNC_RSH«:

$ RSYNC_RSH=ssh
$ export RSYNC_RSH

Um die Variable nicht immer von Hand setzen zu müssen, genügt es, die obigen zwei Zeilen in die Datei ».bashrc« im Homeverzeichnis des Anwenders einzufügen. Für Cronjobs setzt der Admin die Variablen dann in der entsprechenden Crontab. Eine weitere wichtige Option von Rsync ist »-a« für den Archivmodus. Dann überträgt das Programm rekursiv alle angegebenen Verzeichnisse mit Unterverzeichnissen, Dateien, Symlinks, Zugriffsrechten und -zeiten, Eigentümern, Gruppen sowie Gerätedateien. Hilfreich sind auch »-v« für die Anzeige jeder erfolgreich übertragenen Datei sowie »-H« für das (zeitaufwändige) Prüfen und Übertragen harter Links.

Beim Einsatz als Mirror-Kommando, etwa für das hier angestrebte Backup-System, empfiehlt sich zusätzlich die Option »–delete«, die lokal gelöschte Dateien auch vom Sicherungsmedium entfernt und damit eine exakte Kopie des Verzeichnisses ohne Dateileichen garantiert. Weitere Optionen zeigt Tabelle 1.

Abbildung 3: Bei der Key-basierten Authentifizierung ist die Eingabe einer Passphrase sinnvoll, die den privaten Schlüssel schützt. Ein User muss beim Einloggen per SSH stets diese Passphrase eingeben.

#!/bin/sh
cd /backup
for i in *; do
  chown -R $i:users $i
done

Beispiel

In Listing 1 findet sich ein triviales Beispiel, welches das Verzeichnis »/Users« nach »/export/backup« auf dem Computer »backuphost« kopiert. Die vierte Zeile dieses Progrämmchens liest die oben generierte Datei für den Zugriff auf den SSH-Agent ein. Sie entfällt, wenn der Administrator sich für Schlüssel ohne Sicherung durch Passphrasen entschieden hat.

Anschließend ruft das Skript »rsync« auf. Der Login erfolgt als Benutzer »backupuser«, der Zugriff auf das Zielverzeichnis haben muss. Statt der umfassenden Option »-a« kommen diesmal die Optionen »-rlpt« zum Einsatz, sie kopieren ein Verzeichnis rekursiv, mit allen enthaltenen Links, Permissions und Zeitstempeln. Um auch Eigentümer und Gruppe in der Sicherung beizubehalten, müsste sich das Skript als Root auf dem Backup-Host einloggen.

Ergänzend sorgen »-H« und »–delete« dafür, dass Rsync harte Links synchronisiert und gelöschte Dateien auch auf dem Zielrechner entfernt. Für ein vollautomatisches Backup aller Heimatverzeichnisse muss das Skript mit Root-Rechten laufen. Folgender Eintrag in der Datei »/etc/crontab« ruft es jede Nacht um 02:03 Uhr auf:

3 2 * * *       root     /usr/local/bin/rsync-backup.sh

Sicherheit des Skripts

In Listing 1 hat der Benutzer »mas« die Datei »agent.sh« erstellt und in seinem Homeverzeichnis abgelegt. Diese Datei liest Root regelmäßig ein und führt sie aus. Jeder User mit Zugriff auf den Account von Mas (auch Mas selbst) ist also in der Lage, Befehle als Root ausführen zu lassen!

Listing 2 behebt diese Sicherheitslücke. Das File »agent.sh« steht nun nicht mehr in einem Benutzerverzeichnis, sondern im Heimatverzeichnis von Root, das (hoffentlich) vor fremden Schreibzugriffen geschützt ist. Zudem überprüft Listing 2 Benutzer und Permissions von »agent.sh«. Nur wenn sie einwandfrei sind, arbeitet das Skript weiter.

Noch besser wäre es freilich, wenn das Backup-Programm überhaupt keine Root-Rechte benötigte. Leider ist das in der Regel nur möglich, wenn lediglich ein einzelnes Heimatverzeichnis gesichert wird. Dann läuft das Programm einfach mit den Rechten des entsprechenden Benutzers.

Potenzielle Sicherheitsprobleme warten jedoch nicht nur auf den Clientrechnern. Auch den Computer, auf dem das Backup liegt, gilt es zu schützen. Die Skripte aus den Listings 1 und 2 benutzen absichtlich nicht den Root-Account des Zielrechners, sondern melden sich als normaler Nutzer an.

Dieser Account sollte einzig und allein dazu dienen, Backups zu speichern. Denn obgleich der SSH-Schlüssel durch eine Passphrase und den SSH-Agent einigermaßen gut geschützt ist, stellt er doch eine Schwachstelle dar. Über diese könnten Angreifer Zugriff auf den Backup-Server bekommen. Loggt sich ein Backup-Programm nun als Root ein, hat der potenzielle Übeltäter auf dem Server die volle Kontrolle.

Ein eigener Backup-Account schützt die Daten

Zum Schutz des Zielcomputers empfiehlt es sich also, dem Backup-Account keine unnötigen Rechte einzuräumen. Er sollte lediglich Schreibrechte für jenes Verzeichnis besitzen, in das er die Sicherungen schreibt. Allerdings hat genau dieser Account bereits sehr weit reichende Rechte in Bezug auf die gesicherten Computer: Er erhält in den obigen Beispielen die Kopien aller Heimatverzeichnisse.

Je nachdem, wessen Daten darin gespeichert sind, ist das völlig ausreichend, um die zu sichernden Quellcomputer zu knacken. Insofern ist der Zielaccount und damit der Zielrechner durch die Daten auf den Quellrechnern gefährdet. Gleichzeitig kann er einen Angriff auf die Quellrechner erleichtern.

Zwischen Backup-Quelle und -Ziel besteht somit ein besonderes Vertrauensverhältnis, das ein gewissenhafter Administrator keinesfalls unterschätzen sollte. SSH bietet hier die Möglichkeit, bestimmte User nur fest vorgegebene Programme ausführen zu lassen. Mit dieser Art der Autorisierung verringert sich die Gefahr, dass Angreifer einen Rechner übernehmen. (mwe)