https://techcorner.max-it.de/index.php?action=history&feed=atom&title=Vaultwarden%3A_Absichern_und_h%C3%A4rtenVaultwarden: Absichern und härten - Versionsgeschichte2026-10-19T03:18:33ZVersionsgeschichte dieser Seite in maxTechCornerMediaWiki 1.43.9https://techcorner.max-it.de/index.php?title=Vaultwarden:_Absichern_und_h%C3%A4rten&diff=4939&oldid=previmported>TechCorner-Redaktion: Neuer Artikel: Registrierung, Admin-Panel, Ratenbegrenzung, Fail2ban, Container, Netzwerk, Updates2026-10-17T00:00:00Z<p>Neuer Artikel: Registrierung, Admin-Panel, Ratenbegrenzung, Fail2ban, Container, Netzwerk, Updates</p>
<p><b>Neue Seite</b></p><div>{{Steckbrief<br />
| gilt_fuer = Vaultwarden 1.37.x im Docker-Container hinter einem Reverse Proxy; Fail2ban 1.x auf Debian/Ubuntu<br />
| bereich = IT-Security<br />
| dauer = ca. 1–2 Stunden<br />
| rechte = Root auf dem Docker-Host, Administrator des Admin-Panels<br />
| stand = Oktober 2026<br />
}}<br />
'''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.<br />
<br />
[[Datei:Vaultwarden-Haertung.png|thumb|center|750px|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.]]<br />
<br />
== Bedrohungen realistisch einschätzen ==<br />
* '''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.<br />
* '''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.<br />
* '''Admin-Panel''': Wer es erreicht, kann Benutzer löschen, die Zwei-Faktor-Anmeldung entfernen und Einstellungen ändern – aber keine Tresore entschlüsseln.<br />
* '''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]].<br />
<br />
== Schritt 1: Vaultwarden-Einstellungen härten ==<br />
{| class="wikitable"<br />
! Einstellung !! Empfehlung !! Grund<br />
|-<br />
| <code>SIGNUPS_ALLOWED</code> || <code>false</code> || Standard ist <code>true</code> – jeder, der den Server erreicht, könnte sich registrieren.<br />
|-<br />
| <code>SIGNUPS_DOMAINS_WHITELIST</code> || nur, wenn Selbstregistrierung gewünscht: <code>firma.de</code>, zusammen mit <code>SIGNUPS_VERIFY=true</code> || hebt <code>SIGNUPS_ALLOWED</code> auf<br />
|-<br />
| <code>INVITATIONS_ALLOWED</code> || <code>true</code> nur, wenn Organisations-Admins einladen sollen || Eingeladene können sich trotz geschlossener Registrierung anmelden.<br />
|-<br />
| <code>ORG_CREATION_USERS</code> || Adressen der IT-Administratoren || verhindert Schatten-Organisationen außerhalb der Kontrolle der IT<br />
|-<br />
| <code>SHOW_PASSWORD_HINT</code> / <code>PASSWORD_HINTS_ALLOWED</code> || <code>false</code> || Hinweise erleichtern das Erraten des Master-Passworts.<br />
|-<br />
| <code>SENDS_ALLOWED</code>, <code>EMERGENCY_ACCESS_ALLOWED</code> || bewusst entscheiden || Send und Notfallzugriff sind nützlich, müssen aber zur Richtlinie passen.<br />
|-<br />
| <code>INCOMPLETE_2FA_TIME_LIMIT</code> || 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<br />
|-<br />
| <code>REQUIRE_DEVICE_EMAIL</code> || <code>true</code>, wenn SMTP zuverlässig läuft || E-Mail bei jeder Anmeldung eines neuen Geräts; schlägt der Versand fehl, scheitert die Anmeldung.<br />
|-<br />
| <code>DISABLE_2FA_REMEMBER</code> || optional <code>true</code> || erzwingt den zweiten Faktor bei jeder Anmeldung<br />
|}<br />
<br />
== Schritt 2: Admin-Panel schützen ==<br />
* '''Nur gehashtes Token''': <code>ADMIN_TOKEN</code> 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.<br />
* '''Nur aus dem Admin-Netz''': Im Reverse Proxy <code>/admin</code> auf interne Adressen beschränken, siehe [[Vaultwarden: HTTPS mit Reverse Proxy (Caddy, nginx, OPNsense)]].<br />
* '''Am besten abschalten''', wenn es nicht gebraucht wird: <code>ADMIN_TOKEN</code> entfernen, prüfen, dass in <code>data/config.json</code> kein <code>admin_token</code> steht, Container neu erstellen. Für Einladungen und Wartung kurz wieder einschalten.<br />
* <code>DISABLE_ADMIN_TOKEN=true</code> nie verwenden, außer der Proxy schützt das Panel mit eigener Anmeldung.<br />
* '''Sitzungen''': Eine Admin-Sitzung gilt standardmäßig 20 Minuten (<code>ADMIN_SESSION_LIFETIME</code>). Ein Wechsel des Tokens beendet laufende Sitzungen nicht. Alle Sitzungen beendet man, indem man <code>data/rsa_key.pem</code> löscht und Vaultwarden neu startet – dabei werden auch alle Benutzer abgemeldet.<br />
<br />
== Schritt 3: Anmeldeversuche begrenzen ==<br />
Vaultwarden begrenzt Anmeldungen bereits selbst:<br />
{| class="wikitable"<br />
! Einstellung !! Standard<br />
|-<br />
| <code>LOGIN_RATELIMIT_SECONDS</code> / <code>LOGIN_RATELIMIT_MAX_BURST</code> || im Mittel ein Versuch pro 60 Sekunden, Spitzen bis 10<br />
|-<br />
| <code>ADMIN_RATELIMIT_SECONDS</code> / <code>ADMIN_RATELIMIT_MAX_BURST</code> || ein Versuch pro 300 Sekunden, Spitzen bis 3<br />
|}<br />
Zusätzlich sperrt '''Fail2ban''' IP-Adressen nach mehreren Fehlversuchen. Voraussetzung: <code>LOG_FILE</code> ist gesetzt und das Log zeigt die echte Client-IP (nicht 127.0.0.1 oder die IP des Proxys).<br />
<br />
<code>/etc/fail2ban/filter.d/vaultwarden.local</code>:<br />
<syntaxhighlight lang="ini"><br />
[INCLUDES]<br />
before = common.conf<br />
<br />
[Definition]<br />
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$<br />
ignoreregex =<br />
</syntaxhighlight><br />
<code>/etc/fail2ban/filter.d/vaultwarden-admin.local</code>:<br />
<syntaxhighlight lang="ini"><br />
[INCLUDES]<br />
before = common.conf<br />
<br />
[Definition]<br />
failregex = ^.*Invalid admin token\. IP: <ADDR>.*$<br />
ignoreregex =<br />
</syntaxhighlight><br />
<code>/etc/fail2ban/jail.d/vaultwarden.local</code>:<br />
<syntaxhighlight lang="ini"><br />
[vaultwarden]<br />
enabled = true<br />
backend = auto<br />
port = 80,443<br />
filter = vaultwarden<br />
logpath = /opt/vaultwarden/data/vaultwarden.log<br />
banaction = iptables-allports<br />
chain = DOCKER-USER<br />
maxretry = 5<br />
findtime = 4h<br />
bantime = 4h<br />
<br />
[vaultwarden-admin]<br />
enabled = true<br />
backend = auto<br />
port = 80,443<br />
filter = vaultwarden-admin<br />
logpath = /opt/vaultwarden/data/vaultwarden.log<br />
banaction = iptables-allports<br />
chain = DOCKER-USER<br />
maxretry = 3<br />
bantime = 24h<br />
</syntaxhighlight><br />
* '''Docker''': Verbindungen zu veröffentlichten Container-Ports laufen über die Kette <code>FORWARD</code> bzw. <code>DOCKER-USER</code>, nicht <code>INPUT</code>. Neuere Fail2ban-Versionen nutzen unter Debian standardmäßig nftables, Docker aber iptables – deshalb hier ausdrücklich <code>iptables-allports</code>.<br />
* 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.<br />
* Testen: <code>fail2ban-regex /opt/vaultwarden/data/vaultwarden.log /etc/fail2ban/filter.d/vaultwarden.local</code>.<br />
* Das Projekt-Wiki enthält einen dritten Filter für falsche TOTP-Codes.<br />
<br />
== Schritt 4: Container und Host ==<br />
* '''Nicht als root''': <code>user: "1000:1000"</code> in der compose.yaml und den Datenordner vorher mit <code>chown -R 1000:1000 data</code> übergeben. Docker ab 20.10 erlaubt auch Nicht-Root-Prozessen den Port 80 im Container.<br />
* '''Nur den Datenordner mounten''', nie <code>/var/run/docker.sock</code> oder das Home-Verzeichnis. Zertifikate, falls nötig, schreibgeschützt mit <code>:ro</code>.<br />
* '''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.<br />
* '''Datenordner schützen''': <code>chmod 700 data</code>. Er enthält die Datenbank, Schlüssel zum Signieren von Sitzungen (<code>rsa_key.pem</code>) und gegebenenfalls SMTP-Passwort und Admin-Token in <code>config.json</code>.<br />
<br />
== Schritt 5: Netzwerk ==<br />
* '''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.<br />
* '''Strict SNI''': Der Proxy soll Vaultwarden nur unter dem richtigen Namen ausliefern, nicht unter der IP-Adresse – Scanner finden sonst Instanzen über IP-Bereiche.<br />
* '''Icon-Abruf''': Vaultwarden lädt Website-Symbole selbst aus dem Internet. <code>HTTP_REQUEST_BLOCK_NON_GLOBAL_IPS=true</code> (Standard) verhindert Abrufe ins interne Netz. 1.37.0 hat mehrere Lücken über diesen Weg geschlossen (SSRF). Wer den Abruf nicht braucht, setzt <code>DISABLE_ICON_DOWNLOAD=true</code> und <code>ICON_CACHE_TTL=0</code>.<br />
* Ausgehend braucht der Server nur DNS, SMTP, den Icon-Abruf (HTTPS) und optional das Push-Relay.<br />
<br />
== Schritt 6: Updates und Überwachung ==<br />
* '''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'').<br />
* Auch das Host-Betriebssystem, Docker und den Proxy aktuell halten.<br />
* '''Überwachen''': Erreichbarkeit von <code>/alive</code>, Ablaufdatum des Zertifikats, Fail2ban-Sperren und Fehlermeldungen im Log. Die Logs lassen sich an ein SIEM wie Wazuh weitergeben.<br />
* Nach einem Verdacht auf Kompromittierung: Server isolieren, Image und Host neu aufsetzen, Admin-Token und SMTP-Passwort wechseln, <code>rsa_key*</code> neu erzeugen und Benutzer zum Wechsel der Master-Passwörter und der wichtigsten Zugangsdaten auffordern.<br />
<br />
== Hinweise ==<br />
* '''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.<br />
* Bei Härtung, Überwachung und Notfallplanung für sicherheitskritische Dienste unterstützt Sie das Team [https://www.max-it.de/it-services/cybersecurity/ Cybersecurity von m.a.x. it].<br />
<br />
== Siehe auch ==<br />
* [[Vaultwarden]] – Überblick und alle Artikel der Reihe<br />
* [[Brute-Force-Angriff]]<br />
* [[Vaultwarden: Backup und Wiederherstellung]]<br />
* [[Technische und organisatorische Maßnahmen]]<br />
<br />
== Links und Quellen ==<br />
* [https://github.com/dani-garcia/vaultwarden/wiki/Hardening-Guide Vaultwarden-Wiki: Hardening Guide]<br />
* [https://www.max-it.de/it-services/cybersecurity/ Cybersecurity von m.a.x. it]<br />
<br />
{{Uebermax}}<br />
[[Kategorie:IT-Security]]<br />
</div>imported>TechCorner-Redaktion