Willkommen!

Willkommen auf der privaten Webseite von Axel Hahn.

Axels Blog

Härten unseres Restic-Backups

21.03.2024 - 1:41

Unser Server Backup mit dem IML Backup [1] am Institut mit 150+ Systemen lief über Jahre mit Restic [2] und via SFTP zu einem Storage. Mit Restic bin ich soweit sehr zufrieden: es verschlüsselt Daten lokal vor der Übertragung und muss nach einem Initialbackup nur noch inkrementelle Backups machen. Auch das Restore von einzelnen Dateien und Ordnern hat uns nie im Stich gelassen. Insbesondere das Mounten mit Fuse ist ein hilfreiches Feature.

Dann sah ich im Januar 2024 das Videos des CCC [3]. Auf der “wichtigsten Folie des ganze Vortrags” waren Anforderungen an Backups gelistet, um sich gut gegen Ransomware-Verschlüsselungen der Infrastruktur zu wappnen. Bei vielen Punkten waren wir demnach bereits gut gewappnet. Aber es gab unschöne Schwachpunkte. Da diese jeweils eine Rechteausweitung als root voraussetzen, war dies mit “kalkulierten Risiko”.

Ein System kann seine eigenen Backup-Daten löschen.
Damit Backups nicht übermässig gross werden, werden alle N Tage im Anschluss des backups alte Daten älter 180 Tage gelöscht. Wenn ein Sysem gekapert plus der root-Account erreicht würde, kann durch böswilliges Setzen eines Delta statt 180 Tage auf 0 Tage setzend ist so ziemlich alles weggeputzt werden.

Ein System kann theoretisch Backups anderer Systeme löschen.
Bei Einbruch und Rechteausweitung auf root könnte wäre Folgendes denkbar: alle Systeme schreiben auf das Backup-Ziel mit demselben SSH-User. Auf der Zielseite gehören die Dateien demselben User und thoretisch könnte ein System Zugriff auf Backup-Daten eines anderen Systems erhalten und diese zwar nicht entschlüsseln, aber wg. Schreibrechten eben auch löschen.

2024-03-20-restic-via-ssh.png

Es geht nun auch besser.

Auf dem Backup-Endpoint wurde nun der Restic-Rest-Server [4] installiert, der als Systemd Service eingerichtet wurde. Die Backup-Clients kommunizieren nun statt via SSH mit HTTPS. Sie teilen nicht mehr den privaten SSH-Schlüssel.

In den Startparametern des Rest-Servers wurden diese Optionen aufgenommen, um folgende Härtungen zu erreichen:

Ein User (Server) darf nur sein eigenes Repository beschreiben.

Option:

--private-repos

Das Unterbindet das Ausbrechen auf Backup-Daten anderer Systeme.
Jeder Backup-Client (unsere Server) bekommt einen eigenen User und ein eigenes Http-Auth Passwort zugewiesen.
Auf dem Restic Rest Server werden Usernamen und das verschlüsselte Passwort in eine .htpasswd eingetragen.

Stolperfalle: Es böte sich an, die Benutzer gleich zu benennen, wie den Server. Eine Limitierung in der der .htpasswd lässt einen Punkt im Benutzernamen jedoch nicht zu. Aber das Ersetzen des Punkts im FQDN durch einen Unterstrich führt zu keinerlei Überschneidungen. Dem schliest sich an, dass das Backup-Verzeichnis nun statt [Backup-Dir]/ nun [Backup-Dir]/ ist. Bei der Umstellung von SSH auf HTTPS muss somit das Backup-Ziel-Verzeichnis beim Backup-Server umbenannt werden.

Ein User (Server) darf Daten nur anhängen.

Option:

--append-only

Kurz: Löschen ist nicht mehr möglich. Das klingt sicher.

Der Pferdefuss: unser auf jedem Einzelsystem befindliche Restic Prune Job zum Löschen älter N Tage funktioniert so nicht mehr. Ich habe es auch probiert: es wird mit einem 40x Statuscode zurückgewiesen.

Unsere Abhilfe sieht wie folgt aus: auf dem Backup-Zielserver läuft nun ein Cronjob, der über alle Backup-Repos das Pruning macht [4]. Wir lassen es erkennen, wie alt das letzte Prubg war und pausieren das Prune auf ein Repository dann für N Tage. Damit Restic auf Inhalte zugreifen kann, muss das Passwort zum Entschlüsseln aller Serverdaten für das Skript greifbar sein. Wir generieren mit Ansible eine Konfigurationsdatei, die alle Benutzernamen und Restic-Verschlüsselungspasswörter am Backup-System niederschreibt. Diese Datei gehört root:root und hat die Rechte 0400.

Zustand NEU:

Das Ergebnis ist derselbe Datenfluss - nur mit einem anderen Protokoll - Https statt ssh. Entscheidend sind die 2 o.g. Optionen für den Restic Server auf dem Backup-Ziel.

2024-03-20-restic-via-https.png

Dies war eine Beschreibung mit hoher Flughöhe mit weniger technischen Details. Bei Fragen nutzt gern die Kommentarfunktion oder fragt mich an.

Weiterführende Links:

  1. Docs: IML Backup (en)
  2. Github: Restic (en)
  3. CCC Dez 2023: Hirne hacken - Hackback Edition
  4. Github: Restic REST Server (en)
  5. os-docs.iml.unibe.ch: rest-pruner.sh (en)

Blog-Kategorieen: Computer Programmierung Lizenzen Linux Shell GPL Opensource


Letzte Blog-Einträge:

Axels Blog


21.03.2024(1:41 Uhr)Härten unseres Restic-Backups
13.12.2023(23:00 Uhr)Daux auf Manjaro installieren
04.12.2023(0:48 Uhr)ahCrawler läuft auf PHP 8.3
25.11.2023(1:17 Uhr)IP im Webauftritt blockieren
25.08.2023(2:23 Uhr)Dokus für 2 Bash-Projekte
25.05.2023(23:59 Uhr)Bash: lsup zur Anzeige der Dateiberechtigungen
23.05.2023(23:09 Uhr)Fontawesome Upgrade von Version 5 auf Version 6
22.05.2023(21:32 Uhr)Pimped Apache Status - PHP 8.2 kompatibel
11.05.2023(1:27 Uhr)Bash-Skript - einfaches Multi-Ping-Monitoring in Fast-Echtzeit
11.05.2023(1:16 Uhr)A Touch Of Glass - Update

Statistisches



Herkunft der Besucher

Übersicht der Herkunftsländer der Besucher meiner Webseite. Bots von Suchmaschinen sind in dieser Liste ausgeschlossen.

Übersicht der Herkunftsländer der Besucher meiner Webseite. Bots von Suchmaschinen sind in dieser Liste ausgeschlossen.


Webbrowser meiner Besucher

Welche Webbrowser werden verwendet? Die Anzeige fasst alle Versionsnummern zusammen.

Welche Webbrowser werden verwendet? Die Anzeige fasst alle Versionsnummern zusammen.