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 Reverse Proxy traefik, Paperless-NGX und die Datensicherungslösung Duplicati. 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 Administrationsprivilegien. 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 Reverse Proxy (Port 8080) 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

[ufw-block]
enabled = true
#backend = systemd
# Wir suchen direkt im systemd Journal
#journalmatch = _COMM=kernel
# Jetzt verwenden wir die Datei anstelle des Journals
logpath = /var/log/ufw.log
# Der Filter sucht nach dem UFW-Block-Muster in den Log-Zeilen
# Der Ausdruck *<ip>* extrahiert die Quell-IP (SRC=...).
# Die RegEx sollte das korrekte UFW-Muster erfassen.
filter = ufw-block

# Aktionsdefinition: UFW (iptables) zum Blockieren verwenden
banaction = ufw
#logpath = /var/log/ufw.log  ; (Platzhalter, da journalmatch verwendet wird)
maxretry = 3               ; Maximale Versuche (UFW-Blocks) in der Findtime
findtime = 600             ; Zeitraum in Sekunden (10 Minuten)
bantime = 3600             ; Dauer der Sperre in Sekunden (1 Stunde)

# Fail2Ban action configuration file for ufw
#
# You are required to run "ufw enable" before this will have any effect.
#
# The insert position should be appropriate to block the required traffic.
# A number after an allow rule to the application won't be of much use.

[Definition]

actionstart = 

actionstop = 

actioncheck = 

# ufw does "quickly process packets for which we already have a connection" in before.rules,
# therefore all related sockets should be closed
# actionban is using `ss` to do so, this only handles IPv4 and IPv6.

actionban = if [ -n "<application>" ] && ufw app info "<application>"
            then
              ufw <add> <blocktype> from <ip> to <destination> app "<application>" comment "<comment>"
            else
              ufw <add> <blocktype> from <ip> to <destination> comment "<comment>"
            fi
            <kill>

actionunban = if [ -n "<application>" ] && ufw app info "<application>"
              then
                ufw delete <blocktype> from <ip> to <destination> app "<application>"
              else
                ufw delete <blocktype> from <ip> to <destination>
              fi

# Option: kill-mode
# Notes.: can be set to ss or conntrack (may be extended later with other modes) to immediately drop all connections from banned IP, default empty (no kill)
# Example: banaction = ufw[kill-mode=ss]
kill-mode =

# intern conditional parameter used to provide killing mode after ban:
_kill_ =
_kill_ss = ss -K dst "[<ip>]"
_kill_conntrack = conntrack -D -s "<ip>"

# Option: kill
# Notes.: can be used to specify custom killing feature, by default depending on option kill-mode
# Examples: banaction = ufw[kill='ss -K "( sport = :http || sport = :https )" dst "[<ip>]"']
#           banaction = ufw[kill='cutter "<ip>"']
kill = <_kill_<kill-mode>>

[Init]
# Option: add
# Notes.: can be set to "insert 1" to insert a rule at certain position (here 1):
add = prepend

# Option: blocktype
# Notes.: reject or deny
blocktype = reject

# Option: destination
# Notes.: The destination address to block in the ufw rule
destination = any

# Option: application
# Notes.: application from sudo ufw app list
application = 

# Option: comment
# Notes.: comment for rule added by fail2ban
comment = by Fail2Ban after <failures> attempts against <name>

# DEV NOTES:
# 
# Author: Guilhem Lettron
# Enhancements: Daniel Black


Status for the jail: ufw-block
|- Filter
|  |- Currently failed:    34
|  |- Total failed:    5551
|  `- Journal matches:    
`- Actions
   |- Currently banned:    20
   |- Total banned:    157
   `- Banned IP list:    78.128.114.86 106.55.180.162 167.94.138.38 79.124.62.126 79.124.62.134 167.94.138.187 79.124.58.18 167.94.146.49 185.242.226.76 193.163.125.181 206.168.34.199 162.142.125.212 82.156.52.230 167.94.138.196 78.128.114.126 199.45.155.93 206.168.34.198 162.142.125.217 213.209.143.88 167.94.138.43

Es wurden also 5551 Zugriffe innerhalb der letzten 24 Stunden von ufw abgewehrt, davon 34 innerhalb der letzten 10 Minuten und 20 Adressen sind aktuell gesperrt, weil sie mehr als drei Fehlversuche unternommen haben. Man kann erkennen, dass es durchaus sinnvoll ist, das System zu schützen. Hätte ich vielleicht die gesperrten IP-Adressen unkenntlich machen sollen? Nö. Es handelt sich um echte Adressen von Systemen, die versucht haben, meinen Server zu hacken.

# 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:
  traefik:
    image: traefik:latest
    container_name: traefik
    network_mode: host
    restart: unless-stopped
    command:
      # Entrypoints definieren (Ports, auf denen Traefik lauscht)
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - --entrypoints.web.forwardedheaders.trustedIPs=0.0.0.0/0
      - --entrypoints.websecure.forwardedheaders.trustedIPs=0.0.0.0/0
      - --api.dashboard=true
      - --entrypoints.traefik.address=10.11.0.1:8080
      - --providers.providersThrottleDuration=0

      # Provider: Traefik soll Docker-Labels überwachen
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false # Nur Container mit 'traefik.enable=true' beachten
      - --api.insecure=true

      # HTTPS-Zertifikate automatisch von Let's Encrypt holen
      - --certificatesresolvers.letsencrypt.acme.email=mail@sechzig-veedel.de
      - --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json
      - --certificatesresolvers.letsencrypt.acme.tlschallenge=true

    ports:
       - "8080"

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro # Lesezugriff auf Docker-Events
      - /home/andreas/traefik/traefik-data:/letsencrypt

volumes:
  traefik-data:

Hier sind folgende Besonderheiten zu beachten: Aus dem Internet hört traefik auf die Ports 80 und 443. Zwar soll Paperless-NGX später nur verschlüsselt, also über Port 443 erreichbar sein, Port 80 (http) wird aber benötigt, um ein Let's Encrypt-Zertifikat beziehen zu können. Mit dem Parameter "forwardedheaders.trustedIPs=0.0.0.0/0" wird traefik angewiesen, die Header der aufrufenden Systeme zu prüfen und ihnen genug zu vertrauen, um ihre Adressen aufzunehmen. Das ist wichtig, damit später fail2ban auf die Adressen der Systeme angesetzt werden kann, die versuchen, die Seite aufzurufen.

services:
  broker:
    image: docker.io/library/redis:8
    restart: unless-stopped
    volumes:
      - redisdata:/data
  db:
    image: docker.io/library/postgres:17
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    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
    labels:
         # 1. Traefik aktivieren
      - "traefik.enable=true"

      # 2. Router definieren (Definiert die Domain und das Protokoll)
      - "traefik.http.routers.paperless.entrypoints=websecure" # Nur über 443
      - "traefik.http.routers.paperless.rule=Host(`paperlesstest02.kernke.koeln`)" # Ihre Subdomain
      - "traefik.http.routers.paperless.tls=true"
      - "traefik.http.routers.paperless.tls.certresolver=letsencrypt" # Nutze den oben definierten Resolver

      # 3. HTTP-zu-HTTPS-Umleitung (optional, aber empfohlen)
      - "traefik.http.routers.paperless-insecure.entrypoints=web" # Lausche auf Port 80
      - "traefik.http.routers.paperless-insecure.rule=Host(`paperlesstest02.kernke.koeln`)"
      - "traefik.http.routers.paperless-insecure.middlewares=redirect-to-https"

      # 4. Middleware (Die Weiterleitung selbst)
      - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"
      - "traefik.http.middlewares.paperless-realip.headers.customrequestheaders.X-Forwarded-For={client.ip}"
      - "traefik.http.routers.paperless.middlewares=paperless-realip@docker"

      # 5. Service definieren (Wo Traefik die Anfrage hinschicken soll)
      - "traefik.http.services.paperless.loadbalancer.server.port=8000"

    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
      USE_X_FORWARDED_FOR: True
      PAPERLESS_ALLOWED_HOSTS: '*'
      PAPERLESS_LOG_IP_ADDRESS_HEADER: X-Forwarded-For
      PAPERLESS_LOGLEVEL: DEBUG

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

Hier ist jetzt einiges erläuterungsbedürftig. Mit den Labels werden die Parameter für die Auslieferung der Seiten durch den Reverse Proxy definiert. Dabei ist "traefik.enable=true" natürlich die Aktivierung von Trafik. Im Router-Teil werden die Domain und Protokolle definiert. Auch das ist weitestgehend selbsterklärend. Dann wird eine Umleitung von http zu https definiert und vor allem die eigentliche Weiterleitung von der ungeschützten auf die verschlüsselte Seite. Schließlich wird der Service selbst definiert.

Noch ist der Server nicht vor Brute Force Attacken, also dem massenhaften, ggf. automatisierten Versuch, Benutzernamen und Passworte zu erraten, gesichert. Einen wirksamen Schutz vor Brute Force Attacken bieten eine Multifaktor-Authentifizierung, also die Anmeldung an dem System mit mindestens zwei Authentifizierungsfaktoren, nach dem Prinzip "Kennen und Haben". Allerdings muss das im jeweiligen Anwender*innen-Kontext eingerichtet werden und man kann die Anwender*innen nicht zwingen, das zu tun. Darum ist meines Erachtens zusätzlich eine serverseitige Absicherung erforderlich. Das bietet fail2ban. 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. Nach der Firewall-Konfiguration habe ich fail2ban auf die ufw-Protokolle angesetzt und 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.

Der Consume-Ordner der Paperless-Installation ist nur über SFTP und nur innerhalb des VPN erreichbar. Mit gängigen Scannern wird man wohl nicht einrichten können, dass in dieser Weise in den Consume-Ordner gescannt wird. Der beste Weg, direkt in das System zu scannen, ist daher Scan2Email am Scanner einzurichten und in Paperless-NGX entsprechende eMailkontoeinstellungen und eMailregeln zu definieren. Wenn der Scanner aber nicht in der Lage ist, an eine eMail-Adresse zu scannen, dann muss man über einen Umweg in den consume-Ordner scannen, wenn man die Digitalisate nicht zu Fuß übertragen möchte. 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 = 6) 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
      restart: unless-stopped

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.

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)

Konfiguration Fail2Ban für ufw

Installation und Konfiguration der Software

Installation und Konfiguration Wireguard

Installation Docker

Installation traefik Reverse Proxy

Installation und Konfiguration Paperless-NGX

Absicherung Paperless-NGX mit Fail2Ban

Scannen

Datensicherung

Export der Inhalte und Metadaten

Duplicati installieren

Sicherung in Duplicati einrichten

Fazit