Backup zfs via Wireguard-Tunnel

[scooter010]

Hey Forum!

Ich plane, wie viele Andere vor mir, ein Offsite-Backup für mein Heimnetzwerk.
Das Backup benötigt eine TCP-Verbindung, da es via SSH übertragen wird:

zfs send --raw -R -i zvol/dataset@snapshot_old zvol/dataset@snapshot_new | ssh backup-target zfs recv -Fd zvol/dataset

Diesen Backup-Job möchte ich täglich in der Nacht ausführen. Dazu habe ich eine Unix-Kiste mit Wake on Lan an einem entfernten privaten Ort zur Verfügung inkl. einer Portweiterleitung. Mit DynDNS aktualisiert der entfernte Router die IP.

Ich hatte mir gedacht, ich richte einen WireGuard-Tunnel zwischen NAS und Backup-Ziel ein, der scriptgesteuert erstmal mit einem nc -w1 adresse.dyndns.com 12345 das NAS vom router via WoL starten lässt, nach einer angemessenen Wartezeit den WireGuard-Tunnel aufbaut und dann einen snapshot erstellen und syncen und das Backup-Ziel wieder herunterfahren lässt.

Beim Schreiben dieses Beitrages fällt mir auf, dass ich den Wireguard-Tunnel bzgl. der Verschlüsselung gar nicht bräuchte, da SSH die Verbindung bereits hinreichend über das Internet verschlüsselt.
Ich mag aber keine SSH-Ports offen zum Internet haben. Vor allem keine, welche einen root-Login erlauben (wenn auch nur mittels pubkey-Auth). Das hätte aber auch den Vorteil, dass das schwachbrüstige Backup-Ziel (dual-Core Atom-CPU von vor ~15 Jahren) eine Verschlüsselungsschicht weniger in Software zu entschlüsseln hätte, was die Übertragungsgeschwindigkeit signifikant steigern würde. Die Geschwindigkeit sollte aber eigentlich uninteressant sein, solange das Backup nicht regelmäßig über 24h dauert. Da ich eh nur ~6MBit/s im Upload habe, wird die Atom-CPU nicht der Flaschenhals sein (zumindest, solange die Glasfaser hier noch nicht ausgebaut ist).

Meine Fragen:

1. Wireguard-Tunnel, ja/nein und warum?
2. Wie richte ich den Tunnel auf dem NAS so ein, dass es das Backup-Ziel erreicht, aber weiterhin unverändert im LAN erreichbar bleibt und dort seine Dienste bereit stellt? wg-quick up wg0 mit Standard-Conf scheidet dann wohl aus?

Danke für eure Mühe!

 

[Crumar]

Wie funktioniert dein WoL ohne VPN? Wenn ich mich richtig erinner, muss das WoL Paket von einem lokalen Rechner kommen. Übers Internet geht das nicht, ich glaube das war Layer 2.

Mach den Wireguard Tunnel doch woanders? Falls es ne neuere Fritzbox im Ziel Netzwerk ist, z.b. die.

 

[Tornhoof]

Ich würde mir da mal Gedanken machen, ob zfs send raw Checksummen/hash macht. Afaik Nein. Also lieber nach einer entsprechenden Toolkette suchen die das kann.
Also zb
https://github.com/psy0rz/zfs_autobackup

 

[0x8100]

ob du nun wireguard mit key verwendest oder ssh mit key ist dann auch egal. du kannst (und solltest) auch bei ssh nicht mit root arbeiten. nimm einen ansonsten unprivilegierten user und erlaube per sudo, dass dieser ohne passwort "zfs" für das receive aufrufen darf.

 

[scooter010]

Wie funktioniert dein WoL ohne VPN?

In dem die Fritte am Ziel so eingestellt wird, dass sie ein WoL Paket sendet, wenn eine Internetanfrage an eine Portfreigabe geht. 0 Problem.

zfs send raw Checksummen/hash macht

Brauche ich nicht. zfs überprüft selbstständig die Integrität des Dateisystems. Wenn es nach dem send nicht intakt sein sollte (obwohl bereits TCP Integrität hat), dann wird der snapshot gelöscht und neu übertragen, via mein Script.

unprivilegierten user und erlaube per sudo, dass dieser ohne passwort "zfs"

Macht 0 Sinn. Wer Kontrolle über das zfs Kommando hat, kann eh alle Daten ruinieren/löschen. Macht IMHO 0 Sinn, wenn der Zweck des Systems nur ist, Daten dauerhaft unverändert zu speichern. Dann ist die Kontrolle über das zfs Kommando = Kontrolle über die relevanten Bestandteile des Systems.

 

[Bohnenhans]

Doch das macht schon Sinn, wenn man das so macht wie sudo doch auch meist vorgesehen ist - wenn der unprivilegierte user nur sudo Rechte hat für eine scriptausführung (keine schreibrechte für das script) in dem das zfs vorkommt (mit evtl Parametern die man ja im Script checken kann) und nicht für das zfs binary selber hat.

dann läuft zwar das script insgesamt mit root Rechten aber der user kann egal was im script genutzt wird nicht von Hand ausführen.

er hat eben dann nur root rechte für ein eingeschränktes "zfs_sudo.sh" wo Parameter und Co gecheckt werden.

 

[scooter010]

er hat eben dann nur root rechte für ein eingeschränktes "zfs_sudo.sh" wo Parameter und Co gecheckt werden.

Jap, stimmt schon, zumindest grundsätzlich.
Praktisch ist pipen in scripte hinein immer problematisch. Pipen von großen Mengen Binärdaten erst recht.
Auch kann man große Mengen (größer RAM+swap) Binärdaten nicht als Parameter übergeben. Mittels read auf stdin zuzugreifen ist bei binarydaten auch nicht möglich. Damit scheidet sudo scripting aus.

Auch aus Sicherheitstheoretischen Gründen:

mit evtl Parametern die man ja im Script checken kann

Niemals nicht würde ich mich auf eines meiner Scripte verlassen, wenn es um die Prüfung von Parametern zur Verhinderung von exploits bzw. PrivEsc geht. Das ist echt nicht so einfach. Die bash und die core-utils machen manchmal Dinge, wenn man gewisse Schalter kennt, die hätte man in 100 Jahren nicht erwartet und erlauben plötzlich so Späße wie das Ziel einer Dateikopie zu ändern, obwohl vermeintlich "hardcoded" im Script...
Aus dem selben Grund fällt auch ein selbstgeschriebenes python oder c(++) Progrämmchen aus. Ich vertraue SSH nicht genug, was millionenfach mit Pubkey-auth im Internet erreichbar ist, weil es gehackt werden könnte und schreibe deswegen selbst einen Wrapper, der Rechte beschränken soll...?! Ja, ne.

Ich denke, zfs allow wäre an der Stelle eher das, was ich Suche. Zumindest kann ich so verhindern, dass bestehende Backups beschädigt werden, wenn ein Angreifer irgendwie einen User-Login erhält. Der Angreifer könnte dann schlimmstenfalls DOSen, in dem er den restlichen freien Speicherplatz aufbraucht und somit weitere Backups verhindert.

ob du nun wireguard mit key verwendest oder ssh mit key ist dann auch egal

Ne. Es ist quasi ausgeschlossen, dass beide Protokolle gleichzeitig einen auth-bypass-exploit bzw. zero-day haben. Verwende ich nur SSH, reicht bereits ein Exploit (ein SSH-Auth-Bypass würde eh das halbe Internet verrecken lassen, daher eher unwahrscheinlich). Aber ja, ein key-auth sollte, sofern die Implementierung jeweil i.O. grundsätzlich gleich stark sein.

https://github.com/psy0rz/zfs_autobackup

Das ist sowas wie zrep, letztlich auch nur ein spezieller Wrapper für die Filesystemtools zfs snapshot, zfs send, zfs receive usw. Auch autobackup verwendet einen SSH-Tunnel. Auch hier bliebe die Frage: SSH durch einen wireguard-Tunnel? Ja/Nein? Warum?


Ich würde jetzt gerne nochmal auf meine Fragen zurück kommen:

1. Wireguard-Tunnel [zusätzlich zum ssh-Tunnel, Klarstellung], ja/nein und warum?
2. Wie richte ich den Tunnel auf dem NAS so ein, dass es das Backup-Ziel erreicht, aber weiterhin unverändert im LAN erreichbar bleibt und dort seine Dienste bereit stellt? wg-quick up wg0 mit Standard-conf scheidet dann wohl aus?

Frage 2 wird sich wohl mit AllowedIPs = 192.168.178.xx/24 # IP des Backupziels im Ziel-LAN lösen lassen, denk ich. Oder habe ich da etwas übersehen?

Ich denke, wir können das ansonsten an der Stelle beenden. SSH Pubkey-Auth mit zfs allow für einen ansonsten unprivilegierten User wird es tun.