Vaultwarden: Absichern und härten

Auf einen Blick

Gilt für	Vaultwarden 1.37.x im Docker-Container hinter einem Reverse Proxy; Fail2ban 1.x auf Debian/Ubuntu
Bereich	IT-Security
Dauer	ca. 1–2 Stunden
Rechte	Root auf dem Docker-Host, Administrator des Admin-Panels
Stand	Oktober 2026

Vaultwarden absichern und härten heißt: unnötige Funktionen schließen, das Admin-Panel abschotten, Anmeldeversuche begrenzen, den Container mit wenigen Rechten laufen lassen und Sicherheitsupdates zügig einspielen. Ein Passwortserver ist ein lohnendes Ziel – auch wenn die Tresore verschlüsselt gespeichert werden, kann ein Angreifer mit Serverzugriff Konten übernehmen, Zwei-Faktor-Schutz entfernen oder Benutzer aussperren. Diese Checkliste fasst die Empfehlungen des Hardening Guide des Projekts zusammen und ergänzt sie für den Unternehmenseinsatz.

Vaultwarden härten: Registrierung schließen (SIGNUPS_ALLOWED=false), Einladungen und Organisationserstellung beschränken, Passwort-Hinweise abschalten; Admin-Panel nur mit Argon2-Token, nur aus dem Admin-Netz oder ganz abgeschaltet; Fail2ban für Anmeldung, Admin-Panel und TOTP; Ratenbegrenzung; Container als Nicht-Root, nur der Datenordner gemountet; Icon-Abruf ohne interne Adressen; Server nur per VPN oder mit Geofilter erreichbar; Sicherheitsupdates innerhalb weniger Tage einspielen.

Bedrohungen realistisch einschätzen

• Server übernommen: Der Angreifer sieht keine Klartext-Passwörter, kann aber den ausgelieferten Web-Tresor manipulieren und so beim nächsten Login das Master-Passwort abgreifen. Deshalb sind Updates und Systemhärtung wichtiger als bei vielen anderen Diensten.
• Master-Passwort erraten: Online durch Ratenbegrenzung, Fail2ban und Zwei-Faktor-Anmeldung erschwert; offline (mit gestohlener Datenbank) nur durch starke Master-Passwörter und die Schlüsselableitung im Client.
• Admin-Panel: Wer es erreicht, kann Benutzer löschen, die Zwei-Faktor-Anmeldung entfernen und Einstellungen ändern – aber keine Tresore entschlüsseln.
• Phishing: Gefälschte Anmeldeseiten erbeuten Master-Passwort und TOTP-Code. Schutz bieten FIDO2-Sicherheitsschlüssel, siehe Vaultwarden: Zwei-Faktor-Anmeldung und SSO mit OpenID Connect und Phishing.

Schritt 1: Vaultwarden-Einstellungen härten

Einstellung	Empfehlung	Grund
SIGNUPS_ALLOWED	false	Standard ist true – jeder, der den Server erreicht, könnte sich registrieren.
SIGNUPS_DOMAINS_WHITELIST	nur, wenn Selbstregistrierung gewünscht: firma.de, zusammen mit SIGNUPS_VERIFY=true	hebt SIGNUPS_ALLOWED auf
INVITATIONS_ALLOWED	true nur, wenn Organisations-Admins einladen sollen	Eingeladene können sich trotz geschlossener Registrierung anmelden.
ORG_CREATION_USERS	Adressen der IT-Administratoren	verhindert Schatten-Organisationen außerhalb der Kontrolle der IT
SHOW_PASSWORD_HINT / PASSWORD_HINTS_ALLOWED	false	Hinweise erleichtern das Erraten des Master-Passworts.
SENDS_ALLOWED, EMERGENCY_ACCESS_ALLOWED	bewusst entscheiden	Send und Notfallzugriff sind nützlich, müssen aber zur Richtlinie passen.
INCOMPLETE_2FA_TIME_LIMIT	Standard 3 Minuten lassen	meldet per E-Mail, wenn jemand das richtige Master-Passwort eingibt, aber den zweiten Faktor nicht – ein Hinweis auf ein kompromittiertes Passwort
REQUIRE_DEVICE_EMAIL	true, wenn SMTP zuverlässig läuft	E-Mail bei jeder Anmeldung eines neuen Geräts; schlägt der Versand fehl, scheitert die Anmeldung.
DISABLE_2FA_REMEMBER	optional true	erzwingt den zweiten Faktor bei jeder Anmeldung

Schritt 2: Admin-Panel schützen

• Nur gehashtes Token: ADMIN_TOKEN als Argon2-PHC-String, siehe Vaultwarden: Installation mit Docker Compose. Meldet das Panel You are using a plain text ADMIN_TOKEN, ist das Token im Klartext gespeichert.
• Nur aus dem Admin-Netz: Im Reverse Proxy /admin auf interne Adressen beschränken, siehe Vaultwarden: HTTPS mit Reverse Proxy (Caddy, nginx, OPNsense).
• Am besten abschalten, wenn es nicht gebraucht wird: ADMIN_TOKEN entfernen, prüfen, dass in data/config.json kein admin_token steht, Container neu erstellen. Für Einladungen und Wartung kurz wieder einschalten.
• DISABLE_ADMIN_TOKEN=true nie verwenden, außer der Proxy schützt das Panel mit eigener Anmeldung.
• Sitzungen: Eine Admin-Sitzung gilt standardmäßig 20 Minuten (ADMIN_SESSION_LIFETIME). Ein Wechsel des Tokens beendet laufende Sitzungen nicht. Alle Sitzungen beendet man, indem man data/rsa_key.pem löscht und Vaultwarden neu startet – dabei werden auch alle Benutzer abgemeldet.

Schritt 3: Anmeldeversuche begrenzen

Vaultwarden begrenzt Anmeldungen bereits selbst:

Einstellung	Standard
LOGIN_RATELIMIT_SECONDS / LOGIN_RATELIMIT_MAX_BURST	im Mittel ein Versuch pro 60 Sekunden, Spitzen bis 10
ADMIN_RATELIMIT_SECONDS / ADMIN_RATELIMIT_MAX_BURST	ein Versuch pro 300 Sekunden, Spitzen bis 3

Zusätzlich sperrt Fail2ban IP-Adressen nach mehreren Fehlversuchen. Voraussetzung: LOG_FILE ist gesetzt und das Log zeigt die echte Client-IP (nicht 127.0.0.1 oder die IP des Proxys).

/etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

/etc/fail2ban/filter.d/vaultwarden-admin.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*Invalid admin token\. IP: <ADDR>.*$
ignoreregex =

/etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled   = true
backend   = auto
port      = 80,443
filter    = vaultwarden
logpath   = /opt/vaultwarden/data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 4h
bantime   = 4h

[vaultwarden-admin]
enabled   = true
backend   = auto
port      = 80,443
filter    = vaultwarden-admin
logpath   = /opt/vaultwarden/data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 3
bantime   = 24h

• Docker: Verbindungen zu veröffentlichten Container-Ports laufen über die Kette FORWARD bzw. DOCKER-USER, nicht INPUT. Neuere Fail2ban-Versionen nutzen unter Debian standardmäßig nftables, Docker aber iptables – deshalb hier ausdrücklich iptables-allports.
• Läuft der Proxy auf einer anderen Maschine (z. B. OPNsense), muss die Sperre dort greifen; Fail2ban auf dem Vaultwarden-Host sperrt dann nur den Proxy.
• Testen: fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local.
• Das Projekt-Wiki enthält einen dritten Filter für falsche TOTP-Codes.

Schritt 4: Container und Host

• Nicht als root: user: "1000:1000" in der compose.yaml und den Datenordner vorher mit chown -R 1000:1000 data übergeben. Docker ab 20.10 erlaubt auch Nicht-Root-Prozessen den Port 80 im Container.
• Nur den Datenordner mounten, nie /var/run/docker.sock oder das Home-Verzeichnis. Zertifikate, falls nötig, schreibgeschützt mit :ro.
• Eigener Host oder eigene VM für den Passwortserver, kein Mischbetrieb mit Testsystemen. Zugang zum Host nur per SSH-Schlüssel für wenige Administratoren.
• Datenordner schützen: chmod 700 data. Er enthält die Datenbank, Schlüssel zum Signieren von Sitzungen (rsa_key.pem) und gegebenenfalls SMTP-Passwort und Admin-Token in config.json.

Schritt 5: Netzwerk

• Erreichbarkeit beschränken: Am sichersten ist ein Server, der nur im LAN und per WireGuard erreichbar ist. Muss er öffentlich erreichbar sein, Geo-Filter und Intrusion Prevention auf der Firewall nutzen.
• Strict SNI: Der Proxy soll Vaultwarden nur unter dem richtigen Namen ausliefern, nicht unter der IP-Adresse – Scanner finden sonst Instanzen über IP-Bereiche.
• Icon-Abruf: Vaultwarden lädt Website-Symbole selbst aus dem Internet. HTTP_REQUEST_BLOCK_NON_GLOBAL_IPS=true (Standard) verhindert Abrufe ins interne Netz. 1.37.0 hat mehrere Lücken über diesen Weg geschlossen (SSRF). Wer den Abruf nicht braucht, setzt DISABLE_ICON_DOWNLOAD=true und ICON_CACHE_TTL=0.
• Ausgehend braucht der Server nur DNS, SMTP, den Icon-Abruf (HTTPS) und optional das Push-Relay.

Schritt 6: Updates und Überwachung

• Sicherheitsupdates innerhalb weniger Tage: Allein 2026 enthielten die Versionen 1.35.3, 1.35.4, 1.35.5, 1.36.0, 1.37.0 und 1.37.4 Sicherheitsfixes, teils mit hohem Schweregrad. Releases auf GitHub abonnieren (Watch › Custom › Releases).
• Auch das Host-Betriebssystem, Docker und den Proxy aktuell halten.
• Überwachen: Erreichbarkeit von /alive, Ablaufdatum des Zertifikats, Fail2ban-Sperren und Fehlermeldungen im Log. Die Logs lassen sich an ein SIEM wie Wazuh weitergeben.
• Nach einem Verdacht auf Kompromittierung: Server isolieren, Image und Host neu aufsetzen, Admin-Token und SMTP-Passwort wechseln, rsa_key* neu erzeugen und Benutzer zum Wechsel der Master-Passwörter und der wichtigsten Zugangsdaten auffordern.

Hinweise

• Restrisiko Client: Ein Schadprogramm auf dem entsperrten Endgerät kann den Tresor auslesen. Endpoint-Schutz und kurze Tresor-Timeouts gehören zur Härtung dazu.
• Bei Härtung, Überwachung und Notfallplanung für sicherheitskritische Dienste unterstützt Sie das Team Cybersecurity von m.a.x. it.

Siehe auch

• Vaultwarden – Überblick und alle Artikel der Reihe
• Brute-Force-Angriff
• Vaultwarden: Backup und Wiederherstellung
• Technische und organisatorische Maßnahmen

Links und Quellen

• Vaultwarden-Wiki: Hardening Guide
• Cybersecurity von m.a.x. it

Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen