Passive Clients

Ein häufiges Problem bei der Einrichtung der Backup-Umgebung sind Firewalls. Bei einem normalen Verbindungsaufbau in einer Bareos-/Bacula-Umgebung würde der Backup Director eine Verbindung zum Client aufbauen und ihm mitteilen, was und wohin er sichern soll. Außerdem verbindet er sich mit dem Backup Storage Daemon und teilt diesem mit, dass er die Daten vom Client in Empfang nehmen und speichern soll. Schließlich baut der Client die eigentliche Datenverbindung zum Storage Daemon auf und überträgt seine Daten dorthin.

Wenn der Client sich hinter einer Firewall befindet, dann erschweren Paketfilter und Network Address Translation (NAT) in der Firewall eine Verbindung vom Client zum Storage Daemon oder machen diese gar unmöglich. Die problematische Verbindung ist also die eigentliche Datenverbindung zwischen Client und Storage Daemon ( Abbildung 4 ).

Abbildung 4: Bisher: Die Datenverbindung wird vom Client zum Storage Daemon initiiert.

Ab Bareos 13.2 ist dieses Verhalten nun konfigurierbar. Mithilfe der Option »Passive Client« lassen sich alle Verbindungen von den Server-Komponenten her aufbauen. Der Client nimmt dann nur noch Verbindungen entgegen. Der Aufbau der Verbindungen zwischen Director und Client und zwischen Director und Storage Daemon bleiben wie gehabt, aber die eigentliche Datenverbindung wird nun nicht vom Client, sondern vom Storage Daemon initiiert. Nachdem die Verbindung aufgebaut wurde, werden die Daten natürlich doch vom Client zum Storage Daemon übertragen ( Abbildung 5 ).

Abbildung 5: Passive Client: Die Datenverbindung wird vom Storage Daemon zum Client initiiert.

Neben der Firewall-Freundlichkeit hat dieser Ablauf noch einen weiteren Vorteil: Da der Passive Client keinerlei Datenverbindung aufbaut, benötigt er auch keine funktionierende Namensauflösung. In der Praxis hat sich gerade die Namens-auflösung beim herkömmlichen Verfahren häufig als Problem herausgestellt.

Sicherheit

Bareos bietet im Hinblick auf Sicherheit weiterhin die bereits aus Bacula bekannten Sicherheits-Features wie:

• Prüfsummenberechnung auf jeder gesicherten Datei und Überprüfung bei der Rücksicherung,
• die Möglichkeit, die Verbindungen zwischen den Daemons über TLS zu verschlüsseln.

Zusätzlich wurden zu Bareos aber weitere, interessante Sicherheitsfunktionen hinzugefügt:

So kann man nun bei Software-Verschlüsselung das Verschlüsselungsverfahrens wählen. Bisher konnte dabei immer nur AES128 verwendet werden. Nun kommen zusätzlich die folgenden Verfahren in Frage: AES128, AES192, AES256, CAMELIA128, CAMELIA192, CAMELIA256, AES128HNACSHA1, AES256HNACSHA1 und Blowfish.

Neben den Verschlüsselungsoptionen der Software gibt es jetzt die Möglichkeit, direkt die Hardware-Verschlüsselung der LTO-Bandlaufwerke zu nutzen. Seit LTO4 ist die Verschlüsselung Teil des LTO-Standards, sodass alle Laufwerke diese Option anbieten. Die Verschlüsselung im Bandlaufwerk hat dank Hardware-Unterstützung praktisch keine Auswirkung auf die Sicherungsgeschwindigkeit.

Ob man das nutzen möchte, hängt natürlich von den Anforderungen ab. Die LTO-Hardware-Verschlüsselung ist vor allem für diejenigen eine effiziente Option, die ihre Bänder auslagern und dabei vermeiden möchten, dass Unbefugte sie lesen können.

Die bereits erwähnte Option Passive Client stellt ebenfalls einen Sicherheitsgewinn dar: Weil keine Verbindung zum Storage Daemon mehr notwendig ist, können die Firewalls sämtliche Verbindungen zum Sicherungsnetzwerk verhindern.

Bisher war es möglich, dem Client vom Director aus beliebige Kommandos zu senden. Das waren »backup« (Ausführen einer Sicherung), »restore« (Ausführen einer Rücksicherung), »verify« (Ausführen eines Prüfjobs zum Abgleich zwischen Systemdaten und gesicherten Daten), »estimate« (Abschätzen der zu erwartenden Sicherungsdatenmenge) und »runscript« (Ausführen eines Skritpts auf dem Client-System).

Nun ist es möglich, mithilfe der Direktive »Allowed JobCommand« diese Befehle auf dem Client zu filtern. Nicht erlaubte Befehle werden dann vom Client nicht akzeptiert und nicht ausgeführt.

Das Ausführen von Skripten auf dem zu sichernden System stellt eine besondere Sicherheitsgefährdung dar. Falls es sich nicht über »Allowed JobCommand« komplett verbieten lässt, kann über die Option »Allowed ScriptDir« das Verzeichnis gesetzt werden, in dem sich Skripte und Befehle befinden müssen. Befehle, die sich nicht innerhalb dieses Verzeichnisses befinden, werden nicht ausgeführt.