Ein paar irrelevante Tutorials

Paperless fremdgehostet

Die Lösung besteht aus einem Server, der bei einem Hoster angemietet wird. Auf diesem läuft zunächst Wireguard, um eine VPN-Verbindung zu Clients im lokalen Netzwerk aufzubauen. Das wird ausschließlich für die Administration des Systems benötigt. Normale Userzugriffe auf Paperless-NGX werden später über die öffentlich zugängliche Domain stattfinden. Dann läuft auf dem Server unter Docker der Nginx Proxy Manager (NPM), Paperless-NGX und die Datensicherungslösung Duplicati. Der NPM und Paperless-NGX laufen im selben Docker-Netzwerk. Das ist ein Sicherheitsdetail, auf das ich später noch eingehen werde. Zum Schutz vor unbefugten Zugriffen und Manipulationen kommen restriktive Firewalleinstellungen zum Einsatz und mit fail2ban wird ein Schutz vor Brute Force Attacken realisiert. Die Datensicherung wird später auf einen Cloud-Speicher durchgeführt; natürlich verschlüsselt.

Ich werde hier keine Empfehlungen für oder gegen das eine oder andere Hosting-Angebot aussprechen. Die Angebote der verschiedenen Hoster unterscheiden sich hinsichtlich der Speichermengen, der Systemressourcen, der Bandbreite, mit der die Server ans Internet angebunden sind und auch hinsichtlich der jeweils angebotenen Services (mit oder ohne Firewall vor dem Server, mit oder ohne Snapshots, Nutzung eigener Bootmedien oder ausschließlich vom Anbieter bereit gestellter Medien...). Hier muss man sich überlegen, was man braucht und möchte. Meine Paperless-NGX-Installationen kommen in der Regel mit 2 Prozessorkernen und 4 GB RAM aus. Beim Massenspeicher muss man überlegen, wie viel man vielleicht braucht. Wenn man davon ausgeht, am Anfang nicht sehr viel zu brauchen, dann mögen vielleicht 32 GB Massenspeicher ausreichen. Wenn der aber irgendwann knapp wird, dann ist ein Umzug auf einen besser ausgestatteten Server zumindest nicht unaufwändig. Für den Anfang sollte aber eine Kapazität von etwa 80 GB reichen.

Für diese recht geringen Anforderungen werden von den meisten Hostern (z.B. Hetzner, Ionos, Netcup oder Strato) Produkte in der Preisklasse um die 4 - 5 € pro Monat angeboten. Für die Datensicherung empfehle ich einen Cloudspeicher bei einem anderen Anbieter, als dem bei dem der Server gemietet wird. Da die Sicherungen verschlüsselt übertragen und gespeichert werden, ist das aus Sicherheits- und Datenschutzgesichtspunkten her unbedenklich. Solche Speicherlösungen werden für 3 - 5 € im Monat angeboten (z.B. die Hetzner Storage-Box für 3,20 € für 1 TB oder das Strato HiDrive Start für 3,5 € für 500 GB). Somit summieren sich die monatlichen laufenden Kosten für die vorgesehene Lösung auf 7 - 10 € im Monat.

Die Basisinstallation des Servers beschreibe ich hier nicht, weil sich das zum Einen von Hoster zu Hoster geringfügig unterscheidet und zum anderen recht selbst erklärend ist. Die folgenden Schritte basieren auf einem Ubuntu Linux Server oder einem Debian, jeweils in aktueller Long Term Service Version. Ich beschreibe hier die Absicherung des Servers. Zur Basisabsicherung des Servers s. hier: https://tutorials.kernke.koeln/sicherheit/server-absichern.html. Wer seinem Provider seine Daten nicht anvertrauen möchte, kann zusätzlich eine verschlüsselte Partition einrichten. Darauf verzichte ich hier, weil ich Angebote von zertifizierten Providern in Deutschland nutze. Wenn man Bootmedien bzw. entsprechende Templates von Providern für das Betriebssystem des Server nutzt dann, wird bei der Basisinstallation oftmals nur ein Root-User angelegt und kein normaler User ohne Administrationsprovilegien. Die folgenden Anweisungen gehen jeweils davon aus, dass ein normaler User genutzt wird. Wenn der noch nicht existiert, muss er zunächst angelegt werden. Das macht man mit dem Befehl:

Wenn der Hoster eine Firewall anbietet, die bereits zwischen dem Server und dem Internet arbeitet, dann sollte diese auf jeden Fall genutzt werden. Alles, was abgefangen wird, bevor es überhaupt den Server erreicht, belastet natürlich nicht die Systemressourcen unseres Servers. Aber auch wenn es eine solche Firewall des Hosters gibt, sollte noch eine Firewall auf dem Server eingesetzt werden. IT-Sicherheit basiert immer auf dem Prinzip der möglichst vielen Schichten. Ich verwende die ufw, die uncomplicated firewall. Soweit sie noch nicht auf dem Server installiert ist, hole ich das mit

Hier nehme ich bereits die Adressen des VPN vorweg. Dieses werde ich für den Adressbereich 10.11.0.1 bis 10.11.0.255 einrichten. Um das VPN überhaupt etablieren zu können, wird ein offener Port 51820 benötigt. Zunächst brauche ich auch einen offenen Port 22. Später soll nur aus dem VPN heraus soll auf die SSH-Shell (Port 22) zugegriffen werden können. Dann schließe ich die allgemeine Freigabe von Port 22 wieder. Ebenso soll auch auf die Weboberfläche des NPM (Port 81) und die Weboberfläche von Duplicati (Port 8200) nur aus dem VPN heraus zugegriffen werden können. Außerdem soll das Consume-Verzeichnis von Paperless NGX später per Samba für das VPN freigegeben werden. Dafür wird Port 445 benötigt. Diese Einstellungen aktiviere ich mit

# Shell-Skript zur Installation von Docker (mit sudo ausführen:

#!/bin/bash

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do

apt-get remove $pkg;

done

apt-get update

apt-get install ca-certificates curl

install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

chmod a+r /etc/apt/keyrings/docker.asc

echo \
 "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
 $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
tee /etc/apt/sources.list.d/docker.list > /dev/null

apt-get update

apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

systemctl start docker

systemctl enable docker

usermod -aG docker "$SUDO_USER"

Das Script deinstalliert zunächst ggf. vorhandene Bibliotheken, die Probleme machen könnten und installiert dann die benötigten Pakete. Außerdem fügt es den aufrufenden Benutzer (was trotz "sudo" nicht root ist) der Gruppe docker hinzu, damit ich nachher ohne sudo auch docker-Befehle ausführen kann. Nun muss man sich einmal kurz ab- und wieder anmelden, damit die neue Dockerberechtigung auch greift. Ob das alles funktioniert hat prüfe ich mit dem Befehl:

services:
  app:
    image: jc21/nginx-proxy-manager:latest
    restart: always
    ports:
      - 80:80
      - 10.11.0.1:81:81
      - 443:443
    volumes:
      - ./config.json:/app/config/production.json
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - web_proxy
    depends_on:
      - db
    environment:
    # if you want pretty colors in your docker logs:
    - FORCE_COLOR=1
  db:
    image: mariadb:latest
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: "npm"
      MYSQL_DATABASE: "npm"
      MYSQL_USER: "npm"
      MYSQL_PASSWORD: "npm"
    volumes:
      - ./data/mysql:/var/lib/mysql
    networks:
      - web_proxy
networks:
  web_proxy:
    external: true

Hier sind folgende Besonderheiten zu beachten: Port 81, der für die Weboberfläche des NPM genutzt wird, wird an die IP-Adresse aus dem VPN gebunden. Außerdem werden die Services des NPM in das Netzwerk web_proxy verlegt. In diesem Netzwerk soll später auch der Paperless-Webserver, also die Weboberfläche von Paperless-NGX laufen. So kann dann der Webserver im NPM mit dem Namen des Containers (also webserver) angesprochen werden. Dieses Docker-Netzwerk muss ich mit dem (naheliegenden) Befehl

# Docker Compose file for running paperless from the docker container registry.
# This file contains everything paperless needs to run.
# For more extensive installation and update instructions, refer to the
# documentation.

services:
  broker:
    image: docker.io/library/redis:8
    restart: unless-stopped
    networks:
      - web_proxy
    volumes:
      - redisdata:/data
  db:
    image: docker.io/library/postgres:17
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - web_proxy
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: paperless
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    depends_on:
      - db
      - broker
      - gotenberg
      - tika
    networks:
      - web_proxy
    volumes:
      - /home/andreas/paperless-ngx/data:/usr/src/paperless/data
      - /home/andreas/paperless-ngx/media:/usr/src/paperless/media
      - /home/andreas/paperless-ngx/export:/usr/src/paperless/export
      - /home/andreas/paperless-ngx/consume:/usr/src/paperless/consume
    env_file: docker-compose.env
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      PAPERLESS_TIKA_ENABLED: 1
      PAPERLESS_TIKA_GOTENBERG_ENDPOINT: http://gotenberg:3000
      PAPERLESS_TIKA_ENDPOINT: http://tika:9998
      TRUSTED_PROXIES: "172.18.0.0/16" # das Docker-Subnetz, aus dem NPM kommt
      USE_X_FORWARDED_FOR: True
      PAPERLESS_ALLOWED_HOSTS: '*'
      PAPERLESS_LOG_IP_ADDRESS_HEADER: X-Real-IP
      PAPERLESS_LOGLEVEL: DEBUG

  gotenberg:
    image: docker.io/gotenberg/gotenberg:8.20
    restart: unless-stopped
    networks:
      - web_proxy
    command:
      - "gotenberg"
      - "--chromium-disable-javascript=true"
      - "--chromium-allow-list=file:///tmp/.*"
  tika:
    image: docker.io/apache/tika:latest
    restart: unless-stopped
    networks:
      - web_proxy
volumes:
  pgdata:
  redisdata:

networks:
  web_proxy:
    external: true

Hier ist jetzt einiges erläuterungsbedürftig. Mit der Angabe networks: - web_proxy sorge ich dafür, dass die Container im selben Docker-Netzwerk laufen, wie der NPM. Die gemounteten Volumes beginnen hier immer mit "/home/andreas/paperless-ngx". Ein symbolischer Pfad auf das Home-Share ("~/) würde im Docker-Container nicht aufgelöst werden können. Wenn der Nutzer, in dessen Kontext das Ganze läuft, nicht "andreas" heißt, dann muss das natürlich angepasst werden. Die Angaben zu Trusted Proxy, der Parameter USE_X_FORWARDED_FOR: True, PAPERLESS_ALLOWED_HOSTS: '*' und PAPERLESS_LOG_IP_ADDRESS_HEADER: X-Real-IP sind erforderlich, damit der Reverseproxy später die IP-Adressen, von denen aus auf das System zuzugreifen versucht wird, übermittelt und Paperless-NGX dem NPM auch vertraut. Das wird benötigt, um fail2ban auf diese Adressen ansetzen zu können. Die restlichen Parameter sind Standard. Diese Konfiguration kann dann ebenfalls mit

Hier gebe ich die Domain ein, unter der der Dienst erreichbar sein wird. Diese Domain muss - anders als die hier dargestellte - vom Internet aus erreichbar sein und es muss ein A-Record eingestellt sein, der auf die IP-Adresse des Reverse-Proxy also des Servers zeigt. Das muss natürlich auch eine im Internet erreichbare IP-Adresse sein. Als Scheme ist http auszuwählen. Der Container kann nicht direkt mit https angesprochen werden. Als Forward Hostname ist der interne Name einzutragen, den der Container in der docker-compose.yml zugewiesen bekommen hat. Das ist nicht der Name, der mit docker ps angezeigt wird (also paperless-ngx-webserver-1) sondern hier schlicht "webserver". Da wir nichts anderes eingetragen haben, lauscht der Webserver auf Port 8000. Dann hake ich nur noch an "Cache Assets".

# Wichtige Header für den Reverse Proxy
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;

# Schutz vor Clickjacking: Verhindert das Einbetten der Seite in Frames add_header X-Frame-Options "DENY" always; 

# Schutz vor MIME-Type Sniffing: Erzwingt die Einhaltung des Content-Type add_header X-Content-Type-Options "nosniff" always; 

# Optional, aber empfohlen: Blockiert bekannte XSS-Angriffe add_header X-XSS-Protection "1; mode=block" always;

# Einstellungen für WebSockets (für Live-Updates in Paperless-NGX)
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Diese Parameter sind erforderlich, damit die Anwendung hinter dem Proxy richtig funktioniert und gängige Angriffsszenarien abgewehrt werden. Wenn ich das nun mit OK bestätige, dann dauert das eine Weile, weil zunächst das SSL Zertitikat bei Let's Encrypt bezogen wird. Wenn hierbei keine Fehler auftreten, dann wird der neue Proxy Host mit dem Status "online" ausgewiesen und Paperless-NGX ist über die entsprechende Domain mittels https erreichbar. Ich kann nun die Weboberfläche von Paperless-NGX über die dafür ausgewählte Domain ansteuern und den ersten, den administrativen User anlegen. Dann kann ich mit der Nutzung von Paperless NGX beginnen. Aber ich bin noch nicht fertig mit meinem Projekt.

Noch ist der Server nicht vor Brute Force Attacken, also dem massenhaften, ggf. automatisierten Versuch, Benutzernamen und Passworte zu erraten, gesichert. Ganz am Anfang hatte ich ja fail2ban installiert, ohne weitere Konfigurationen daran vorzunehmen. Auf diese Weise sichert fail2ban zunächst die SSH-Schnittstelle gegen Brute Force Attacken ab, aber nicht mehr. Nun setze ich es auf die Anmeldung an Paperless-NGX an. Paperless-NGX speichert Logfiles in der Datei .../data/log/paperless.log. Das data-Verzeichnis habe ich in der docker-compose.yml auf den Pfad /home/andreas/paperless-ngx gemounted. Ich erstelle nun eine Filterdatei, die dieses Logfile auswertet und dort verzeichnete fehlerhafte Anmeldeversuche erkennt. Dazu erstelle ich die Datei /etc/fail2ban/filter.d/paperless-block.conf

Diese Filterdefinition erkennt nun das Vorkommen der Zeichenkette "Login failed for user... from private IP..." und ermittelt in der Variable <HOST> die IP-Adresse des "Angreifers". Unter ignoregex könnte man noch IP-Adressen erfassen, die von einer Sperre ausgenommen werden sollen. Darauf habe ich hier verzichtet, damit ich das Ganze auch testen kann. Später könnte ich dort die IP-Adressen aus meinem privaten Netzwerk ausschließen. Noch wird diese Filterdefinition aber nicht angewendet. Dazu muss erst ein Jail angelegt werden. Ich erstelle dazu die Datei /etc/fail2ban/jail.d/paperless.conf

Hier wird zunächst der eben definierte Filter verwendet. Dann wird eine banaction bestimmt. Das ist eine Aktion, die zum Aussperren der erkannten Übeltäter verwendet werden soll. Diese muss ich noch definieren. Geblockt werden sollen Zugriffe auf das Docker-Netzwerk. Das ist nun etwas schwer zu verstehen. Endanwender*innen kommen mit einer normalen, öffentliche IP-Adresse an. Diese ist zu sperren. Innerhalb des Docker-Netzwerks gibt es eigene Adressen aus dem Adressraum 172.17.0.0/24 und nicht zuletzt habe ich ja noch ein VPN definiert, mit dem Adressraum 10.11.0.0/24. Hier sollen aber die öffentlichen IPs der zugreifenden Systeme erkannt und ggf. geblockt werden.

Der Parameter logpath ist selbsterklärend. Wichtig ist danach der Parameter "backend = polling". Der bewirkt, dass tatsächlich dieses Logfile ausgewertet wird und nicht irgendwelche Systemprotokolle. Dann könnte ich auch hier noch einmal IP-Adressen vom Blockieren ausschließen. Der Parameter maxretry definiert natürlich die Anzahl der erlaubten Versuche. Findtime definiert den Suchzeitraum in Millisekunden, also den Zeitraum innerhalb dessen die Fehlerversuche gezählt werden. Hier habe ich mit 600 eine Minute definiert. Wenn ich innerhalb einer Minute dreimal versuche, mich mit falschen Credentials anzumelden, werde ich gesperrt. Bots, die durch das Netz schwirren, unternehmen sehr viele Zugriffsversuche in sehr kurzer Zeit und werden schnell erkannt. Wenn ich mich beim Anmelden zweimal vertippt habe, dann warte ich eine Minute und kann gefahrlos einen dritten Versuch unternehmen. Die bantime, also die Zeitspanne einer Sperrung beträgt hier 3600 Millisekunden, also eine Stunde. Diese Werte kann man nach Belieben ändern.

Wenn der Scanner nicht in der Lage ist, an eine eMail-Adresse zu scannnen, dann muss man in den consume-Ordner scannen, wenn man die Digitalisate nicht zu Fuß übertragen möchte. Wenn der Scanner aber nicht in das VPN integriert werden kann, dann muss man einen Umweg gehen. Hierzu gebe ich den consume-Ordner mittels Samba frei. Dann mounte ich den freigegebenen Ordner an meinem Client und gebe diesen wiederum im Netzwerk frei. Das ist zugegebenermaßen kein besonders eleganter Weg. Aber er funktioniert und ein besserer fällt mir nicht ein.

alles mounten, was in /etc/fstab steht und noch nicht gemountet wurde. Nun habe ich den Ordner consume des Paperless-NGX-Servers als Verzeichnis scans lokal verfügbar. Alle Dateien, die ich dort hineinschiebe und die Paperless-NGX verarbeiten kann, werden automatisch verarbeitet. Damit der Scanner auch das Verzeichnis nutzen kann, muss ich auf dem Client nun ebenfalls Samba installieren. Serverdienste auf einem Client sind natürlich nicht im Sinne des Erfinders. Das ist es, was ich mit nicht elegant gemeint habe. Aber nur so funktioniert es. Ich installiere also wie oben beschrieben auch auf dem Client den Samba-Server, füge ebenfalls den Samba-User andreas hinzu und erstelle in der Datei /etc/samba/smb.conf die Freigabe

Wenn ich dem System Dokumente anvertraue, die ich vielleicht ansonsten nicht mehr aufbewahre, dann muss ich mich natürlich um eine zuverlässige Datensicherung kümmern. Hierfür bietet sich das Open Source Tool Duplicati an. Es lässt sich bequem über Docker installieren und bietet verschlüsselte, inkrementelle Backups auf verschiedenste Sicherungsziele an. Die Sicherungen auf dem selben System abzulegen, auf dem auch schon die Daten liegen, ist natürlich komplett sinnfrei. Daher brauche ich ein externes Sicherungsziel. Hier nutze ich, wie eingangs erklärt, Speicherlösungen bei Hosting-Anbietern. Die Einrichtung der Speichers bei externen Hostern führe ich hier nicht aus, weil es viele verschiedene Anbieter und Konfigurationsoberflächen gibt. Im Ergebnis setze ich im Folgenden voraus, dass es einen Speicher gibt, der per SFTP (SSH) angesprochen werden kann.

aufgerufen bzw. genutzt. Hierbei muss der Pfad angegeben werden, den der Export-Ordner innerhalb des Docker-Containers nutzt. Gemountet ist dieser Ordner auf den Pfad /home/andreas/paperless-ngx/export. Dieser Export soll natürlich einmal am Tag ausgeführt werden, also definiere ich einen Cronjob dafür. Da der Job im normalen User-Kontext also ohne Adminitrationsrechte ausgeführt werden soll, kann ich ihn in der Crontab für den Standarduser einrichten. Ich rufe die crontab-Bearbeitung mit

Am Anfang der Zeile wird definiert, wann der Cronjob ausgeführt werden soll. An erster Stelle werden die Minuten, dann die Stunden, dann der Tag des Monats (1-31), der Monat (1-12), der Wochentag (Sonntag = 0, Samstag = 7) angegeben. Darauf folgt das auszuführende Kommando. In diesem Fall wird jeden Morgen um 7:00 Uhr ein Export ausgeführt. Dabei werden vorhandene Dateien überschrieben, wenn im System eine neuere verfügbar ist. Es werden die Ursprungsdateien, die PDF-Repräsentationen, Web-Vorschauen und in einer Manifest-Datei alle Metadaten und Datenbankinhalte gespeichert. Den Inhalt des Export-Ordner muss ich nun natürlich sichern.

services:
    duplicati:
      image: lscr.io/linuxserver/duplicati:latest
      container_name: duplicati
      environment:
        - PUID=0
        - PGID=0
        - TZ=Europe/Berlin
        - SETTINGS_ENCRYPTION_KEY=strenggeheimerundkomplexerkey
        - DUPLICATI__WEBSERVICE_PASSWORD=strenggeheimesundkomplexespasswort
      volumes:
        - ./config:/config
        - /home/andreas/paperless-ngx/export:/paperless-export
        - /home/andreas/sicherungsverzeichnis1:/source1
      ports:
        - 10.11.0.1:8200:8200
      networks:
        - web_proxy
      restart: unless-stopped
networks:
  web_proxy:
    external: true

Hier habe ich das Exportverzeichnis von Paperless-NGX als Volume gemountet und zusätzlich ein Verzeichnis namens "sicherungsverzeichnis1". Hier kann man beliebige Verzeichnisse angeben, die dann später von der Weboberfläche aus und für den Dockercontainer erreichbar sind. Das zweite Verzeichnis habe ich angegeben, damit ich später aus duplicati heraus einzelne Files an anderer Stelle zurücksichern kann, als dem Ursprungspfad. Mit der Angabe unter "ports" binde ich die Duplicati-Weboberfläche vor allem an die VPN-Adresse. Duplicati hätte nun nicht unbedingt im selben Docker-Netwzerk laufen müssen, wie der NPM und Paperless-NGX, aber so vermeide ich unnötige Netzwerke auf dem Server.

Unter den allgemeinen Sicherungseinstellungen vergebe ich zunächst einen Namen für die Sicherung. Der darf ruhig sprechend sein. Eine Sicherungsbeschreibung kann ich auch noch eingeben. Das bewirkt aber nichts. Interessanter ist da schon die Verschlüsselung. Ich kann hier wählen zwischen AES-256, was bereits integriert ist oder GNU Privacy Guard, was auf den allermeisten Linux-Systemen bereits installiert ist. Ich entscheide mich für die integrierte Variante. Außerdem muss ich mir ein Passwort ausdenken. Hier werden auch schwache Passworte akzeptiert, aber man sollte sich schon etwas Mühe geben.

Bei den Backup-Destinationen wähle ich natürlich SSH aus. Auf der nächsten Seite muss ich dann die Zugangsdaten für den externen Speicher eingeben. Bei einer Storage-Box von Hetzner ist das z.B. accountname.your-storagebox.de, ansonsten könnte das eine IP-Adresse eines entfernten Servers oder auch eine Domain sein. Der Standard-Port für SSH ist 22, bei der Storage-Box von Hetzner ist es 23. Auf der Firewall habe ich ausgehenden Traffik nicht begrenzt. Darum brauche ich mir keine Gedanken zu machen, ob ich einen Port auf der Firewall öffnen muss. Ordnerpfad ist natürlich der Pfad, in den auf dem entfernten System gesichert werden soll. Den hier angegebenen Ordner muss es im Ziel schon geben, sonst läuft die Sicherung auf einen Fehler. Das war in früheren Versionen von Duplicati noch anders. Da wurde man dann gefragt, ob der Ordner angelegt werden soll.. Username ist natürlich der Username in dessen Berechtigungskontext auf dem Zielsystem die Sicherungen abgelegt werden sollen.

Die Autentifizierungsmethode wählt man mit "Erweiterte Option hinzufügen" aus. Hier reicht eine Authentifizierung mit Passwort aus. Duplicati unterstützt auch SSH-Key-Authentifizierung. Allerdings werden nur Schlüssel im PEM-Format erlaubt und die Einbindung ist auch recht kompliziert. Da die Passwortübertragung verschlüsselt erfolgt, mache ich es mir einfach und wähle Passwortauthentifizierung aus. Neben dem Passwort prüft Duplicati den Fingerprint der Gegenseite. Den erwartet es als MD5-Hash. Da es je nach Hosting-Anbieter nicht ganz einfach ist, den Fingerprint der Gegenseite im MD5-Format zu bekommen, wende ich einen kleinen Trick an. Ich füge zunächst unter "Erweiterte Option hinzufügen" "SSH Fingerprint" hinzu und schreibe in das entsprechende Feld irgend etwas hinein. Später, wenn ich mit diesen unsinnigen Daten zu sichern versuche, erhalte ich eine Fehlermeldung, in der mir der korrekte Fingerprint angezeigt wird. Dazu komme ich später noch. Ich klicke also nicht auf "Test destination", sondern erst einmal auf Weiter. Hier wähle ich die zu sichernden Daten aus. In meinem Fall habe ich ja den Export-Ordner von Paperless-NGX in das Verzeichnis "source" gemountet und darum wähle ich das natürlich aus.

Ich könnte auswählen, dass alle Sicherungen gelöscht werden, die älter sind als n Tage, Wochen, Monate oder Jahre. Ich könnte aber auch vorgeben, dass eine bestimmte Anzahl von Sicherungen aufbewahrt werden und alle anderen (älteren) gelöscht werden. Wenn ich "intelligente Sicherungsaufbewahrung" auswähle, dann werden die Sicherungen der letzten 7 Tage, jeweils eine der letzten 4 Wochen und jeweils eine der letzten 12 Monate aufbewahrt. Alternativ kann ich eine individuelle Aufbewahrungsregel definieren. Die Syntax wird hier ganz gut erklärt. Mir reicht hier für's Erste die intelligente Aufbewahrungsregel. Unter "Optionen für Profis" könnte ich noch sehr viele erweiterte Optionen hinzufügen. Das ist aber wirklich etwas für Profis, darum lasse ich einstweilen die Finger davon. Wenn ich auf "Senden" klicke, dann wird der Sicherungsjob gespeichert. Die Sicherung würde dann um 6:00 Uhr starten und zunächst auf einen Fehler laufen, wegen des falschen SSH-Fingerprints. Das warte ich natürlich nicht ab, sondern klicke auf der Startseite auf "Start". Nun läuft der Job auf den erwarteten Fehler. In der Fehlermeldung wird mir auch ein Link auf das Protokoll angezeigt, den ich anklicke. Dort wird ein Fehler ausgewiesen, der auch den erwarteten SSH-Fingerprint beginnend mit "ssh-ed25519 256" enthält. Den kopiere ich einfach aus der Fehlermeldung heraus. Ich gehe erneut in die Bearbeitung des Sicherungsjobs und trage den korrekten Schlüssel auf der Seite mit der Sicherungszieldefinition ein. Wenn ich nun auf "Test destination" klicke, wird mir angezeigt, dass die Verbindung funktioniert. Ich kann die Bearbeitung der Sicherung abschließen und die erste Sicherung anstoßen. Das sollte nun funktionieren.

Nun habe ich also einen Server bei einem Hoster, auf dem Paperless-NGX läuft. Die Weboberfläche von Paperless-NGX ist aus dem Internet über eine (Sub-)Domain erreichbar und mit einem gültigen SSL-Zertifikat von Let's Encrypt abgesichert. Die SSL-Absicherung und die Verbindung mit dem Zertifikat werden durch einen Reverse-Proxy besorgt. Paperless-NGX ist ausschließlich über den Reverse-Proxy ansprechbar. Somit kann die Absicherung mit SSL niemand umgehen. Die Remote-Konsole des Servers sowie die Weboberflächen des Reverse Proxys und von Duplicati sind ausschließlich über das VPN erreichbar. Die Firewall blockiert unerlaubte Zugriffe aus dem Netz und fail2ban sperrt IP-Adressen aus, wenn sie mehr als dreimal versuchen, mit falschen Zugangsdaten auf die Remoteshell oder Paperless-NGX zuzugreifen. Die Datensicherung erfolgt auf ein System bei einem anderen Hoster, also auch in einem anderen Rechenzentrum. Die Sicherungen finden verschlüsselt, komprimiert und inkrementell statt. Auch der Übertragungsweg der Sicherungsdaten ist verschlüsselt.

Paperless fremdgehostet

Einleitung

Lösungsdesign

Zutaten

Hosting

Absicherung des Servers

Installation fail2ban

Konfiguration der Firewall(s)

Installation und Konfiguration der Software

Installation und Konfiguration Wireguard

Installation Docker

Installation Nginx Proxy Manager

Installation und Konfiguration Paperless-NGX

Einrichtung des Proxy-Hosts

Absicherung mit Fail2Ban

Scannen

Datensicherung

Export der Inhalte und Metadaten

Duplicati installieren

Sicherung in Duplicati einrichten

Fazit