BorgBackup: Härtung der Sicherheit von BorgBackup und Borgmatic mittels Docker (Teil 3/3)

Dieser Beitrag ist eine Fortsetzung von Teil 1 (Einführung) und Teil 2 (Automatisierung und WSL) unserer Reihe, in welchem bereits die Grundlagen von BorgBackup und Borgmatic sowie die Unterstützung von Windows mittels Windows Subsystem for Linux (WSL) vorgestellt wurden.

Soll die Sicherung auf dem Quellsystem nicht nur im Kontext eines aktuell angemeldeten Benutzers, sondern systemweit erfolgen, werden hierfür entsprechend hohe Berechtigungen (bspw. root) benötigt. Erfolgt die Sicherung zudem auf einem Remote-Zielsystem, ist die Nutzung von SSH und borg serve empfehlenswert. Um die Sicherheit von sowohl des Quell- als auch des Zielsystems zu erhöhen bzw. den etwaigen Schaden im Falle einer erfolgreichen Kompromittierung zu minimieren, können für BorgBackup, Borgmatic und SSH Container eingesetzt werden.

Nachfolgend ist eine mögliche Umsetzung mittels Docker beschrieben.

Hinweis: Bei der Nutzung von Docker sind weitere Härtungsmaßnahmen empfehlenswert, wie bspw. die Nutzung von vertrauenswürdigen Images oder Container-Registries. Diese werden im nachfolgenden jedoch nicht im Detail behandelt.

Borgmatic mit Read-Only Zugriff auf Quellsystem

Auf dem Quellsystem kann BorgBackup bzw. Borgmatic in einem Container ausgeführt und dabei nur eingeschränkter Zugriff auf das Host-Dateisystem gegeben werden. Hierbei ist sowohl nur lesender Zugriff (read-only) möglich als auch die Freigabe von nur einzelnen Ordnern, welche in der Sicherung enthalten sein sollen. Dabei ist darauf zu achten, dass sensitive Dateien, die ein Ausbrechen aus dem Container-Kontext ermöglichen könnten (wie bspw. /run/docker.sock), nicht miteingebunden werden.

Das nachfolgende Szenario beschreibt die Nutzung von borgmatic mittels Docker Compose. Die Erstellung des Container-Images erfolgte in Anlehnung an https://github.com/qLb/docker-borgmatic-container, wurde jedoch stellenweise angepasst.

Zunächst werden die für den Build-Vorgang benötigten Schritte definiert und Quelldateien angelegt.

Inhalt Datei ./src/Dockerfile:

Inhalt Datei ./src/entrypoint.sh:

Der Container wird nun mit Hilfe von Docker Compose definiert.

Inhalt Datei ./docker-compose.yml:

Erläuterungen der Volumes:

• Im obigen Beispiel wird das gesamte Host-Dateisystem (/) eingebunden und einzelne kritische Verzeichnisse (und damit Dateien wie /run/docker.sock) vor dem Container verborgen. Dies erleichtert zwar die Konfiguration, für eine höhere Sicherheit empfiehlt sich jedoch, nur die Ordner einzubinden, die tatsächlich gesichert werden sollen – also statt einer Block-Liste eine Allow-Liste einzusetzen.
• Das Vorhalten der Dateien unter ./tmp/ ist nicht zwingend erforderlich, da diese bei Bedarf wiederhergestellt werden können. Jedoch können Datensicherungen durch Vorhalten des Caches beschleunigt werden, insbesondere wenn es sich um Remote-Sicherungen handelt, weshalb sich der Einsatz von diesem Volume empfiehlt.
• Im Ordner ./config/ssh wird bspw. die Datei known_hosts abgelegt. Dies dient der persistenten Bestätigung bzw. Freigabe von SSH-Host-Fingerabdrücken.

Im Ordner ./config/borgmatic werden die Borgmatic-Sicherungsdefinitionen (also die .yaml-Dateien) abgelegt. Diese werden wie im vorherigen Kapitel erläutert konfiguriert.
Ein Beispiel kann wie folgt aussehen (Datei ./config/borgmatic/my-backup.yaml):

Eine Datensicherung kann nun mit folgendem Befehl veranlasst werden:

Soll die Sicherung regelmäßig erfolgen, kann dies bspw. mittels einem Cronjob (crontab -e) definiert werden (hier: täglich um 03:00 Uhr):

 

BorgBackup Server mit SSH

Soll die Datensicherung auf einem Remote-System mit borg über SSH erfolgen, bspw. um eine Sicherung im „Append-Only“-Modus zu ermöglichen, kann auch diese Serverinstanz mittels eines Containers erzeugt werden. Das nachfolgende Beispiel verwendet zur Vereinfachung ein vorgefertigtes Image aus Docker Hub. Der zugrunde liegende Quelltext ist auf GitHub allerdings ebenfalls zugänglich, dass Image kann daher auch mittels Dockerfile selbst erstellt werden (vergleiche obige Beschreibung). Das Image beinhaltet zum einen BorgBackup als auch einen SSH-Server. Letzterer ist dabei so konfiguriert, dass passwortbasierte Authentifizierung sowie root-Login deaktiviert sind.

In diesem Beispiel erfolgt die Definition des Containers erneut mit Hilfe von Docker Compose.

Inhalt Datei ./docker-compose.yml:

In der Datei ./config/user-ssh/authorized_keys können dann die Clients definiert werden, welchen Zugriff auf Borg (bzw. auf borg serve) gestattet ist:

 

Erläuterung:

• command=“…“: Gibt an, welches Kommando ausgeführt wird, wenn sich ein SSH Client verbindet. Somit wird verhindert, dass der Client weitere und potenziell bösartige Befehle auf dem System ausführen kann.
• ,restrict: Das Schlüsselwort gibt an, dass potenziell gefährliche SSH-Funktionen deaktiviert werden, auch welche, die womöglich in Zukunft erscheinen.
  (Anmerkungen: Dieses Schlüsselwort wird von OpenSSH ab Version 7.2 unterstützt, bei älteren Versionen müssen alle potenziell gefährliche Funktionen explizit aufgeführt werden, bspw. no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding,no-user-rc)
• /usr/bin/borg serve –append-only: Bei einer SSH-Verbindung wird /usr/bin/borg im „Append-Only“-Modus gestartet.
• –restrict-to-path /mnt/BACKUP_DATA: Zugriff auf und Erstellen von Repositories ist nur im angegebenen Ordner gestattet. Somit wird sichergestellt, dass Sicherungen ausschließlich im korrekten Ordner erfolgen.
• ssh-rsa <YOUR_PUBLIC_KEY_HERE>: Am Ende der Zeile wird der öffentliche Schlüssel des Clients angegeben.

Anschließend kann die Instanz mit dem Befehl docker-compose up gestartet werden und die Borg-Server-Instanz ist über den Port 2222 über SSH erreichbar.

Fazit

Daten vor Verlust aufgrund Hardware-, Software- oder Anwenderfehlern mittels Datensicherung zu schützen, stellt für sich alleine betrachtet bereits eine große Herausforderung dar. Diese Komplexität wird dabei weiter verschärft, wenn ein weiteres Ziel darin besteht, die Vertraulichkeit der gesicherten Daten auf dem Zielsystem zu schützen. Wie uns die Vergangenheit gelehrt hat, können selbst Maßnahmen für diese Schutzziele noch nicht ausreichend sein, wenn man mit einem versierten Angreifer oder einer versierten Schadsoftware konfrontiert ist, und es werden in Folge trotz erfolgter Datensicherung sowohl diese als auch die Ausgangsdaten beschädigt oder manipuliert.

Daher empfiehlt sich bei der Umsetzung von Datensicherungslösungen, diese nicht nur gegen technische oder unbeabsichtigte „Unfälle“ zu schützen, sondern auch das Szenario eines versierten Angreifers in Betracht zu ziehen und etwaiges Ausweiten der Zugriffsrechte in beide Richtungen weitestgehend zu verhindern.

Beachten Sie aber bitte auch, dass der Wiederherstellungsprozess ebenfalls getestet sowie die dafür benötigten Informationen sicher abgelegt werden sollten – denn selbst die beste Backupstrategie nützt im Ernstfall nichts, wenn das für die Entschlüsselung benötigte Passwort verloren ist.