Affidare tutte le password a un servizio cloud di terze parti significa fidarsi della loro infrastruttura, delle loro policy e della loro sicurezza. Vaultwarden ribalta questo schema: è un server gestore password compatibile con Bitwarden che gira sul tuo hardware, sotto il tuo controllo, con cifratura end-to-end e architettura a conoscenza zero. Scritto in Rust, consuma poche decine di megabyte di RAM e funziona su un Raspberry Pi, un NAS o un piccolo VPS da pochi euro al mese.

Questa guida pratica ti porta dall’installazione a un’istanza Vaultwarden in produzione, con HTTPS, pannello di amministrazione blindato, autenticazione a due fattori, backup automatici e hardening con fail2ban. Dodici step concreti, comandi copia-incolla testati su Ubuntu 24.04 LTS, oltre a errori comuni e risoluzione dei problemi. Tempo stimato: circa 45 minuti per la configurazione completa.

Aggiornato al 15 giugno 2026. La versione di riferimento è Vaultwarden 1.36.0, rilasciata a maggio 2026, il progetto open source dani-garcia/vaultwarden che su GitHub supera le 62.000 stelle.

Cosa è Vaultwarden e perché self-hostarlo

Vaultwarden è un’implementazione alternativa e non ufficiale del server Bitwarden, scritta in Rust. Nasce nel 2018 con il nome bitwarden_rs e viene rinominato in Vaultwarden nel 2023 per evitare confusione con il marchio ufficiale Bitwarden. Il progetto re-implementa l’API di Bitwarden, quindi funziona con tutti i client ufficiali: applicazioni desktop per Windows, macOS e Linux, app mobile per Android e iOS, estensioni per browser e interfaccia web.

La differenza chiave rispetto allo stack ufficiale è il peso. Il server Bitwarden self-hosted ufficiale richiede una dozzina di container Docker e circa 2 GB di RAM per funzionare in modo fluido. Vaultwarden gira in un singolo container e a riposo consuma poche decine di megabyte. Questo lo rende ideale per un Raspberry Pi 4 o 5, un NAS Synology o QNAP, o un VPS economico da 1 GB di RAM. Il database predefinito è SQLite, ma sono supportati anche MySQL/MariaDB e PostgreSQL per scenari multi-utente più impegnativi.

Il modello di sicurezza è identico a quello di Bitwarden. La cifratura è end-to-end: la chiave di cifratura del vault deriva dalla master password tramite PBKDF2 o, sui client moderni, Argon2id, e il server non vede mai le password in chiaro. È un’architettura a conoscenza zero (zero-knowledge): anche con accesso fisico al database, un attaccante trova solo blob cifrati con AES-256. Vaultwarden supporta organizzazioni, condivisione tramite la funzione Send, allegati cifrati, notifiche in tempo reale via WebSocket e autenticazione a due fattori (TOTP, WebAuthn/FIDO2, Duo ed email).

Perché self-hostarlo? Tre motivi concreti. Primo, sovranità sui dati: i tuoi segreti restano in Italia o in Europa, sotto il GDPR, su hardware che controlli. Secondo, costo: niente abbonamenti per famiglia o team, paghi solo il server. Terzo, funzionalità premium gratuite: con Vaultwarden ottieni 2FA hardware, vault organizzativi e reportistica sulla salute delle password senza alcun piano a pagamento. Il rovescio della medaglia è la responsabilità: backup, aggiornamenti e sicurezza dell’infrastruttura ricadono interamente su di te. Questa guida copre tutti e tre i fronti.

Vale la pena chiarire a chi conviene questo approccio. Se sei un utente alle prime armi che vuole solo un gestore password senza pensieri, un servizio cloud gestito resta la scelta più pratica. Vaultwarden brilla invece per chi ha già un minimo di dimestichezza con Linux e Docker, per le famiglie tecniche, per i professionisti che gestiscono dati sensibili dei clienti e per le piccole organizzazioni che vogliono evitare costi ricorrenti per utente. Il progetto è maturo, attivamente mantenuto e adottato da decine di migliaia di amministratori in tutto il mondo: le oltre 62.000 stelle su GitHub raccontano una community solida e una documentazione collaudata. Non è un esperimento di nicchia, è infrastruttura di produzione su cui molti si appoggiano da anni.

Vaultwarden vs Bitwarden ufficiale: le differenze

Prima di mettere mano al terminale, è utile capire cosa scegli e a cosa rinunci. Vaultwarden non è un fork di Bitwarden, ma una re-implementazione indipendente dell’API. Per l’uso quotidiano di una famiglia o di un piccolo team le differenze sono minime, ma ci sono distinzioni importanti su licenza, supporto e funzionalità enterprise.

CaratteristicaVaultwarden 1.36.0Bitwarden ufficiale self-hosted
LinguaggioRustC# / .NET
Container Docker1~11
RAM a riposoPoche decine di MB~2 GB consigliati
DatabaseSQLite, MySQL, PostgreSQLMSSQL (o PostgreSQL su Unified)
LicenzaAGPLv3 (open source)Bitwarden License (source-available)
Funzioni premiumTutte gratuiteRichiedono licenza
2FA hardware (FIDO2)InclusoRichiede licenza premium
Supporto ufficialeCommunitySupporto commerciale
Compatibilità clientClient ufficiali BitwardenClient ufficiali Bitwarden

La distinzione di licenza conta. Vaultwarden è rilasciato sotto AGPLv3, una licenza copyleft che impone la pubblicazione del codice sorgente per i servizi esposti in rete. Bitwarden usa una licenza source-available più restrittiva. Per un uso personale o domestico la differenza è irrilevante; per chi rivende il servizio cambia tutto.

Cosa manca a Vaultwarden? Non implementa alcune funzioni enterprise dell’ufficiale, come SSO con SAML, criteri di accesso aziendali avanzati e l’integrazione completa con directory esterne. Per una PMI, una famiglia o un professionista, queste assenze raramente pesano. Per un’azienda con requisiti di compliance stringenti, il prodotto ufficiale con supporto commerciale resta la scelta sensata. Se stai valutando le alternative cloud, abbiamo confrontato altri gestori in Proton Pass vs 1Password.

Un punto fondamentale: la sicurezza crittografica di Vaultwarden non è inferiore. La cifratura avviene sul client, non sul server, quindi usa le stesse primitive di Bitwarden. La superficie di rischio si sposta sulla tua capacità di gestire correttamente server, HTTPS e backup, non sull’algoritmo. Questo è il vero impegno che ti assumi.

Prerequisiti e requisiti di sistema

Vaultwarden è leggero, ma per esporlo in modo sicuro su Internet servono alcuni elementi. Ecco il setup minimo testato per questa guida. Il punto non negoziabile è il dominio con HTTPS: i client Bitwarden rifiutano di connettersi a un server senza TLS valido, perché la cifratura del vault avviene solo su connessioni sicure.

ComponenteRequisito minimoNote
Sistema operativoUbuntu 24.04 LTS / Debian 12Qualsiasi Linux con Docker
RAM1 GB512 MB sufficienti per pochi utenti
Spazio disco2 GB liberiPiù spazio per gli allegati
Docker Engine27.x o superioreCon plugin Compose v2
Dominiovault.tuodominio.itRecord DNS A/AAAA verso il server
Porte80 e 443 apertePer HTTPS e validazione ACME
AccessoSSH con chiaveNo password, vedi hardening

Hai bisogno di un nome di dominio e della possibilità di puntare un sottodominio (per esempio vault.tuodominio.it) all’indirizzo IP pubblico del server. Se ospiti su una rete domestica dietro NAT, dovrai aprire le porte 80 e 443 sul router e, idealmente, avere un IP statico o un servizio DNS dinamico. Per il primo accesso al server raccomandiamo SSH con chiave Ed25519: trovi la procedura completa nella nostra guida sulle chiavi SSH Ed25519 e l’hardening del server.

Per il reverse proxy useremo Caddy, che ottiene e rinnova automaticamente i certificati TLS da Let’s Encrypt senza configurazione manuale. In alternativa puoi usare Nginx con Certbot: in quel caso la nostra guida su Let’s Encrypt e Certbot copre il rilascio dei certificati. Caddy semplifica enormemente il lavoro ed è la scelta consigliata per chi parte da zero.

Step 1: Installare Docker Engine e Compose

Vaultwarden viene distribuito come immagine Docker ufficiale (vaultwarden/server), quindi il primo passo è installare Docker Engine con il plugin Compose v2. Sul tuo server Ubuntu 24.04, aggiorna i pacchetti e installa Docker dal repository ufficiale, non dalla versione spesso obsoleta nei repository di sistema.

# Aggiorna il sistema e installa le dipendenze
sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg

# Aggiungi la chiave GPG ufficiale di Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

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

# Installa Docker Engine e Compose
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

# Verifica l'installazione
sudo docker --version
sudo docker compose version

Se i comandi finali stampano i numeri di versione, Docker è pronto. Per evitare di digitare sudo a ogni comando, aggiungi il tuo utente al gruppo docker con sudo usermod -aG docker $USER e poi riconnettiti via SSH. Attenzione: appartenere al gruppo docker equivale a privilegi di root, quindi limita questo accesso agli amministratori fidati. La guida ufficiale per l’installazione su Ubuntu è disponibile nella documentazione Docker.

Step 2: Preparare le cartelle e le variabili

Organizza i file in una struttura ordinata. Vaultwarden salva il database, gli allegati e le chiavi in una cartella dati che dovrai includere nei backup. Creiamo una directory dedicata e un file .env per le variabili sensibili, così da tenerle fuori dal file Compose.

# Crea la struttura delle cartelle
mkdir -p ~/vaultwarden/vw-data
cd ~/vaultwarden

# Crea il file delle variabili d'ambiente
cat > .env << 'EOF'
DOMAIN=https://vault.tuodominio.it
SIGNUPS_ALLOWED=true
INVITATIONS_ALLOWED=true
WEBSOCKET_ENABLED=true
SIGNUPS_VERIFY=true
EOF

# Proteggi il file dalle letture non autorizzate
chmod 600 .env

Una nota sulle variabili. DOMAIN deve corrispondere esattamente all’URL pubblico con cui accederai, incluso https://: è usato per WebAuthn e per i link nelle email. SIGNUPS_ALLOWED=true lo lasciamo attivo solo temporaneamente, per creare il primo account; lo disattiveremo nello Step 8 per impedire registrazioni indesiderate. WEBSOCKET_ENABLED=true abilita le notifiche in tempo reale sui client. Dalla versione 1.30 in poi Vaultwarden gestisce i WebSocket internamente sulla stessa porta, quindi non serve più esporre la porta 3012 separata come nelle vecchie guide.

Step 3: Scrivere il file docker-compose.yml

Il cuore della configurazione è il file Compose. Qui definiamo due servizi: Vaultwarden e Caddy come reverse proxy. Caddy si occupa di TLS automatico, inoltrando il traffico interno verso Vaultwarden sulla porta 80 del container. Crea il file docker-compose.yml nella cartella ~/vaultwarden.

services:
  vaultwarden:
    image: vaultwarden/server:1.36.0
    container_name: vaultwarden
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./vw-data:/data
    networks:
      - vw-net

  caddy:
    image: caddy:2
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config
    networks:
      - vw-net
    depends_on:
      - vaultwarden

networks:
  vw-net:

Abbiamo fissato l’immagine alla versione 1.36.0 invece di usare il tag latest. È una scelta deliberata: bloccare la versione rende gli aggiornamenti prevedibili e controllabili, evitando che un docker compose pull tiri una release non testata. Quando vorrai aggiornare, modificherai il numero a mano dopo aver letto le note di rilascio. Nota anche che Vaultwarden non espone porte direttamente all’esterno: solo Caddy pubblica le porte 80 e 443. Tutto il resto avviene sulla rete interna vw-net, riducendo la superficie di attacco.

Step 4: Configurare Caddy per l’HTTPS automatico

Caddy ottiene e rinnova i certificati Let’s Encrypt senza intervento manuale, applica TLS 1.3 e imposta header di sicurezza moderni. Crea il file Caddyfile nella stessa cartella. È volutamente minimale: poche righe fanno il lavoro che con Nginx richiederebbe decine di direttive.

vault.tuodominio.it {
    # Inoltra il traffico a Vaultwarden sulla rete interna
    reverse_proxy vaultwarden:80

    # Header di sicurezza
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "same-origin"
        -Server
    }

    # Log degli accessi (utile per fail2ban)
    log {
        output file /data/access.log
        format json
    }
}

Sostituisci vault.tuodominio.it con il tuo sottodominio reale. Alla prima esecuzione, Caddy contatta Let’s Encrypt, supera la sfida HTTP-01 e installa un certificato valido. Da quel momento, l’header HSTS impone ai browser di usare solo HTTPS per un anno, mentre X-Frame-Options: DENY blocca i tentativi di clickjacking. Il log in formato JSON ci servirà più avanti per fail2ban. Se preferisci affinare la configurazione TLS, il generatore di configurazioni SSL di Mozilla resta il riferimento per cipher suite e profili moderni.

Step 5: Avviare lo stack e verificare

Con i tre file pronti (.env, docker-compose.yml, Caddyfile), assicurati che il record DNS del tuo sottodominio punti già all’IP del server, altrimenti Caddy non potrà ottenere il certificato. Poi avvia tutto in background.

# Avvia i container in modalità detached
docker compose up -d

# Controlla che entrambi i servizi siano "running"
docker compose ps

# Segui i log per verificare il rilascio del certificato
docker compose logs -f caddy

Nei log di Caddy cerca una riga come certificate obtained successfully. Se compare, apri il browser su https://vault.tuodominio.it: dovresti vedere la schermata di login di Bitwarden con il lucchetto verde. Premi Ctrl+C per uscire dai log senza fermare i container. Se invece vedi errori ACME, consulta la sezione di risoluzione dei problemi: quasi sempre è un problema di DNS o di porte chiuse.

Una volta che la pagina di login risponde in HTTPS, hai un server Vaultwarden funzionante ed esposto in sicurezza. Ma non è ancora pronto per la produzione: mancano il pannello admin protetto, la chiusura delle registrazioni e i backup. Procediamo.

Step 6: Generare l’ADMIN_TOKEN con Argon2

Vaultwarden offre un pannello di amministrazione web all’indirizzo /admin per gestire utenti, organizzazioni e diagnostica. L’accesso è protetto da un token. Le versioni recenti raccomandano di non salvare il token in chiaro, ma di memorizzarne l’hash Argon2 in formato PHC, così che anche chi legge il file .env non possa usarlo direttamente. Vaultwarden include un comando integrato per generarlo.

# Genera un hash Argon2 PHC del token admin in modo interattivo
docker run --rm -it vaultwarden/server:1.36.0 \
  /vaultwarden hash --preset owasp

# Ti verrà chiesto di inserire e confermare una password robusta.
# L'output sarà una stringa come:
# $argon2id$v=19$m=19456,t=2,p=1$base64salt$base64hash

Copia l’intera stringa $argon2id$... generata. La master password che inserisci qui è la chiave del pannello admin: scegline una lunga e unica, conservala in modo sicuro. Argon2id con il preset OWASP usa parametri di memoria e iterazioni resistenti agli attacchi con GPU e ASIC, lo stesso principio che approfondiamo nella nostra guida sull’hashing sicuro delle password. Se preferisci, esiste anche il preset bitwarden, ma owasp è il default consigliato.

Step 7: Inserire il token e ricaricare lo stack

Ora aggiungiamo l’hash al file .env. C’è un dettaglio cruciale che fa inciampare molti: in un file .env letto da Docker Compose, il simbolo $ viene interpretato come variabile. Devi quindi raddoppiare ogni $ in $$, oppure racchiudere il valore tra apici singoli a seconda di come Compose gestisce il file.

# Apri il file .env con l'editor
nano ~/vaultwarden/.env

# Aggiungi la riga ADMIN_TOKEN raddoppiando ogni simbolo $
# Esempio (sostituisci con il TUO hash):
ADMIN_TOKEN='$$argon2id$$v=19$$m=19456,t=2,p=1$$c2FsdA$$aGFzaA'

# Salva (Ctrl+O, Invio) ed esci (Ctrl+X), poi ricarica
cd ~/vaultwarden
docker compose up -d

Dopo il riavvio, visita https://vault.tuodominio.it/admin. Inserisci la master password che hai scelto nello Step 6 (non l’hash) e dovresti entrare nel pannello. Se ricevi un errore di accesso, quasi sempre è colpa dei simboli $ non raddoppiati: torna al file, controlla l’escape e ricarica. In alternativa, puoi disabilitare del tutto il pannello admin lasciando ADMIN_TOKEN vuoto, scelta valida se preferisci gestire tutto da riga di comando.

Step 8: Creare il primo account e chiudere le registrazioni

Questo è l’ordine corretto: prima crei il tuo account, poi blocchi le registrazioni pubbliche. Apri https://vault.tuodominio.it, clicca su “Crea account” e registra la tua utenza principale con una master password forte e univoca. Questa password non è recuperabile: se la perdi, perdi l’accesso al vault, quindi annotala in un luogo sicuro offline.

Subito dopo, disattiva le registrazioni per impedire che estranei creino account sul tuo server. Modifica il file .env impostando SIGNUPS_ALLOWED=false e ricarica lo stack. D’ora in poi i nuovi utenti potranno entrare solo tramite invito dal pannello admin o da un’organizzazione.

# Modifica .env: disattiva le registrazioni aperte
sed -i 's/SIGNUPS_ALLOWED=true/SIGNUPS_ALLOWED=false/' ~/vaultwarden/.env

# Per accettare inviti solo su domini fidati, puoi aggiungere:
echo "SIGNUPS_DOMAINS_WHITELIST=tuodominio.it" >> ~/vaultwarden/.env

# Applica le modifiche
cd ~/vaultwarden && docker compose up -d

Per aggiungere familiari o colleghi, vai nel pannello /admin, sezione utenti, e usa “Invite User”: riceveranno un’email per impostare la propria master password. In alternativa, crea un’organizzazione e invita i membri da lì, così potrai condividere collezioni di credenziali in modo strutturato. Ricorda: ogni utente ha una propria master password e un proprio vault cifrato; nemmeno tu, come amministratore, puoi leggere le loro password.

Step 9: Installare e configurare i client Bitwarden

Il bello di Vaultwarden è che usi le app ufficiali Bitwarden, senza software speciale. L’unico passaggio differente è indicare al client l’URL del tuo server invece di quello cloud di Bitwarden. Funziona con l’estensione per Chrome, Firefox, Edge e Safari, con le app desktop e mobile.

  • Estensione browser: installa Bitwarden dallo store ufficiale del browser, poi nella schermata di login clicca sull’icona dell’ingranaggio in alto a sinistra e nel campo “URL server” inserisci https://vault.tuodominio.it.
  • App desktop: stessa procedura, impostazioni regione/server prima del login.
  • App mobile (Android/iOS): nella schermata iniziale tocca l’ingranaggio, scegli “Self-hosted” e inserisci l’URL del server.

Dopo aver impostato l’URL, accedi con email e master password. Il client scarica il vault cifrato e lo decifra localmente con la chiave derivata dalla tua master password. Da questo momento hai il riempimento automatico dei moduli, il generatore di password e la sincronizzazione tra dispositivi. Verifica che la sincronizzazione funzioni creando una voce di prova sul browser e controllando che compaia sul telefono entro pochi secondi: è il segnale che i WebSocket lavorano correttamente.

Un dettaglio operativo importante riguarda l’iterazione di derivazione della chiave (KDF). Nelle impostazioni di sicurezza del vault web puoi scegliere tra PBKDF2 e Argon2id e regolarne i parametri. Per i nuovi vault, Argon2id è la scelta consigliata: rende molto più costoso un eventuale attacco a forza bruta sulla master password, anche se un attaccante dovesse impossessarsi del database. Se migri da un vecchio account con PBKDF2 e un numero di iterazioni basso, aumentalo: i client moderni gestiscono la transizione in modo trasparente al primo login. Questo è uno di quei dettagli che distingue un’installazione superficiale da una blindata, e non costa nulla configurarlo bene fin da subito.

Step 10: Attivare l’autenticazione a due fattori

La master password protegge la cifratura del vault, ma il login al server merita un secondo fattore. Vaultwarden supporta TOTP (app come Aegis o gli autenticatori che abbiamo confrontato in la nostra guida sul TOTP), chiavi hardware WebAuthn/FIDO2, Duo ed email. Configurarlo richiede meno di due minuti dal vault web.

  • Accedi al vault web e vai su Impostazioni → Sicurezza → Login a due fattori.
  • Per TOTP: scansiona il QR code con la tua app autenticatore, inserisci il codice a 6 cifre per confermare e salva i codici di recupero.
  • Per FIDO2/WebAuthn: collega una chiave hardware (YubiKey, Nitrokey o un’altra chiave compatibile) e registrala. È il metodo più resistente al phishing.
  • Conserva sempre il codice di recupero 2FA offline: senza, un secondo fattore perso può bloccarti fuori dall’account.

Un’attenzione importante: il 2FA su Vaultwarden protegge l’autenticazione, ma se perdi sia il dispositivo 2FA sia i codici di recupero, dovrai disabilitare il secondo fattore di quell’utente dal pannello /admin. Per questo il pannello admin va a sua volta blindato con un token Argon2 robusto, come fatto nello Step 6. La difesa è a strati: ogni livello copre i punti deboli dell’altro.

Step 11: Configurare i backup automatici del database

Questo è lo step che separa un esperimento da un servizio affidabile. Vaultwarden non ha uno strumento di backup integrato, quindi devi predisporlo tu. Il database SQLite è in uso mentre il server gira, perciò non basta copiare il file: va usato il comando .backup di SQLite, che produce una copia coerente anche con il database aperto. Includi anche le cartelle attachments, sends e i file chiave.

#!/bin/bash
# ~/vaultwarden/backup-vw.sh
set -euo pipefail
DATA_DIR="$HOME/vaultwarden/vw-data"
DEST="$HOME/vaultwarden/backups"
STAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p "$DEST"

# Backup coerente del database SQLite tramite il container
docker exec vaultwarden \
  sqlite3 /data/db.sqlite3 ".backup '/data/db-backup.sqlite3'"

# Crea un archivio con db, allegati, sends e chiavi
tar -czf "$DEST/vw-$STAMP.tar.gz" -C "$DATA_DIR" \
  db-backup.sqlite3 attachments sends \
  rsa_key.pem rsa_key.pub.pem config.json 2>/dev/null || true

# Mantieni solo gli ultimi 14 backup
ls -1t "$DEST"/vw-*.tar.gz | tail -n +15 | xargs -r rm --
echo "Backup completato: vw-$STAMP.tar.gz"

Rendi lo script eseguibile con chmod +x ~/vaultwarden/backup-vw.sh e poi pianificalo. Il modo più pulito su un sistema systemd è un timer; in alternativa va benissimo una voce cron. Ecco la riga cron per un backup giornaliero alle 3 del mattino:

# Apri il crontab dell'utente
crontab -e

# Aggiungi questa riga per un backup giornaliero alle 03:00
0 3 * * * /home/$USER/vaultwarden/backup-vw.sh >> /home/$USER/vaultwarden/backup.log 2>&1

Un backup che resta sullo stesso server non è un backup: se il disco muore, perdi tutto. Copia gli archivi .tar.gz su una destinazione esterna (un altro server, uno storage cifrato, un cloud) usando strumenti come rsync o rclone con cifratura. E soprattutto, prova periodicamente a ripristinare un backup su un server di test: un backup mai testato è solo una speranza.

Step 12: Hardening con fail2ban e aggiornamenti

Esporre un servizio su Internet attira tentativi di accesso automatici. fail2ban legge i log e banna gli indirizzi IP che falliscono ripetutamente il login. Vaultwarden scrive eventi di login falliti nei propri log, che possiamo intercettare. Installa fail2ban e crea un filtro dedicato.

# Installa fail2ban
sudo apt install -y fail2ban

# Filtro: /etc/fail2ban/filter.d/vaultwarden.conf
sudo tee /etc/fail2ban/filter.d/vaultwarden.conf << 'EOF'
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>.*$
ignoreregex =
EOF

# Jail: /etc/fail2ban/jail.d/vaultwarden.local
sudo tee /etc/fail2ban/jail.d/vaultwarden.local << 'EOF'
[vaultwarden]
enabled = true
filter = vaultwarden
logpath = /home/USER/vaultwarden/vw-data/vaultwarden.log
maxretry = 5
bantime = 3600
findtime = 600
action = iptables-allports
EOF

# Riavvia fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Per far funzionare il filtro, abilita il logging su file di Vaultwarden aggiungendo LOG_FILE=/data/vaultwarden.log al file .env e ricaricando lo stack. Sostituisci USER con il tuo nome utente reale. Dopo 5 tentativi falliti in 10 minuti, l’IP viene bannato per un’ora. Configura anche un firewall di base con UFW, aprendo solo le porte 22 (SSH), 80 e 443, e abilita gli aggiornamenti automatici di sicurezza del sistema con unattended-upgrades.

Per aggiornare Vaultwarden quando esce una nuova versione, leggi prima le note di rilascio su GitHub, poi modifica il tag immagine nel docker-compose.yml (per esempio da 1.36.0 alla nuova versione), esegui un backup e infine docker compose pull && docker compose up -d. Lo stesso vale per Caddy. Mantenere aggiornati container e sistema operativo è la singola abitudine che più riduce il rischio nel tempo.

Errori comuni da evitare

Cinque trappole in cui cadono quasi tutti i nuovi amministratori Vaultwarden. Conoscerle in anticipo ti risparmia ore di debug.

  • Simboli $ non raddoppiati nell’ADMIN_TOKEN. In un file .env con Docker Compose ogni $ dell’hash Argon2 va scritto $$, altrimenti l’autenticazione admin fallisce in modo silenzioso. È l’errore numero uno.
  • Esporre Vaultwarden senza HTTPS. I client Bitwarden rifiutano connessioni non cifrate. Niente reverse proxy con TLS valido significa niente login. Mai esporre la porta del container direttamente su Internet.
  • Lasciare SIGNUPS_ALLOWED=true in produzione. Con le registrazioni aperte, chiunque trovi l’URL può creare un account sul tuo server. Disattivale subito dopo aver creato la tua utenza.
  • Backup del file SQLite a caldo. Copiare db.sqlite3 mentre il server è attivo produce file corrotti. Usa sempre il comando .backup di SQLite, come nello script dello Step 11.
  • DOMAIN configurato male. Se la variabile DOMAIN non corrisponde all’URL reale (incluso https://), WebAuthn e gli inviti via email smettono di funzionare. Deve essere identica al carattere.

Risoluzione dei problemi più frequenti

Quando qualcosa non va, il primo comando da eseguire è sempre docker compose logs vaultwarden e docker compose logs caddy. Quasi ogni problema lascia una traccia chiara nei log. Ecco i casi più comuni e come risolverli.

SintomoCausa probabileSoluzione
Caddy non ottiene il certificatoDNS non propagato o porte 80/443 chiuseVerifica record A/AAAA e firewall; testa con dig
Login admin fallisceSimboli $ non raddoppiatiRiscrivi ADMIN_TOKEN con $$ ed esegui up -d
Client dice “server non raggiungibile”URL server errato nel clientInserisci https:// e il dominio esatto
Sincronizzazione lenta o assenteWebSocket non abilitatiImposta WEBSOCKET_ENABLED=true e ricarica
Errore 502 Bad GatewayContainer vaultwarden non avviatoControlla docker compose ps e i log
Email di invito non arrivanoSMTP non configuratoAggiungi le variabili SMTP_* nel file .env
“An error has occurred” al loginDOMAIN diverso dall’URL realeAllinea DOMAIN all’indirizzo pubblico
fail2ban non banna nullaLOG_FILE non impostatoAggiungi LOG_FILE=/data/vaultwarden.log
WebAuthn/FIDO2 non si registraHTTPS o DOMAIN non validiWebAuthn richiede TLS e dominio corretto

Per i problemi di certificato, il test più rapido è dig vault.tuodominio.it da una macchina esterna: se non restituisce l’IP corretto, il DNS è il colpevole. Per gli errori 502, ricorda che Caddy inoltra a vaultwarden:80 sulla rete interna: se il container Vaultwarden è in crash loop, Caddy risponde 502. Risolvi prima il container, poi il proxy.

Consigli avanzati per amministratori

Una volta che il setup di base funziona, alcuni accorgimenti portano Vaultwarden a livello professionale. Sono opzionali, ma fanno la differenza per un’istanza che ospita dati critici di una famiglia o di un team.

Configurare l’invio email SMTP

Senza SMTP, inviti, verifiche email e avvisi di nuovo dispositivo non funzionano. Aggiungi al file .env le variabili SMTP_HOST, SMTP_PORT, SMTP_SECURITY (di solito starttls), SMTP_FROM, SMTP_USERNAME e SMTP_PASSWORD. Usa un provider transazionale o un mailserver dedicato. Una volta attivo, potrai imporre la verifica email e usare il 2FA via email come ulteriore opzione.

Passare a PostgreSQL per più utenti

SQLite regge bene fino a qualche decina di utenti attivi. Oltre, o se vuoi backup e replica più robusti, conviene migrare a PostgreSQL impostando DATABASE_URL=postgresql://utente:password@db/vaultwarden e aggiungendo un container Postgres allo stack Compose. Esegui la migrazione dei dati con attenzione e dopo un backup completo. Per la maggior parte degli utenti domestici, comunque, SQLite resta la scelta più semplice e affidabile.

Monitoraggio e accesso remoto sicuro

Considera di mettere il pannello /admin dietro una VPN invece di esporlo pubblicamente: la nostra guida su come configurare un server WireGuard mostra come creare un tunnel cifrato verso il server. Aggiungi un endpoint di health check monitorato da un servizio di uptime esterno, così sai immediatamente se il server cade. Infine, imposta SHOW_PASSWORD_HINT=false per non rivelare suggerimenti che potrebbero aiutare un attaccante.

Un’ultima raccomandazione operativa: documenta la tua configurazione. Tieni una copia cifrata del file docker-compose.yml, del Caddyfile e di un .env di esempio (senza segreti reali) in un posto separato dal server. Annota la versione installata, la data dell’ultimo aggiornamento e dove finiscono i backup. Quando, tra sei mesi, dovrai migrare a un nuovo server o ripristinare dopo un guasto, questa documentazione trasforma un’emergenza stressante in una procedura di routine. La differenza tra un hobbista e un amministratore affidabile non è il software, è il metodo.

Domande frequenti su Vaultwarden

Vaultwarden è sicuro quanto Bitwarden ufficiale?

Dal punto di vista crittografico sì: la cifratura del vault avviene sul client con le stesse primitive (AES-256, derivazione della chiave con PBKDF2 o Argon2id), e il server non vede mai i dati in chiaro. La differenza sta nella responsabilità: con Vaultwarden la sicurezza dell’infrastruttura (HTTPS, backup, aggiornamenti, hardening) dipende da te. Configurato bene, come in questa guida, offre un livello di protezione paragonabile.

Posso usare le app ufficiali Bitwarden con Vaultwarden?

Sì. Vaultwarden implementa l’API di Bitwarden, quindi tutte le app ufficiali (estensioni browser, desktop, mobile e vault web) funzionano. Devi solo indicare l’URL del tuo server self-hosted nelle impostazioni del client prima del login, come spiegato nello Step 9.

Quanto costa ospitare Vaultwarden?

Pochissimo. Vaultwarden gira su un VPS da 1 GB di RAM, che parte da circa 3-5 euro al mese presso provider europei, oppure gratis su un Raspberry Pi o un NAS che già possiedi. L’unico altro costo è il nome di dominio, intorno ai 10-15 euro l’anno. Niente abbonamenti per utente.

Cosa succede se perdo la master password?

La master password non è recuperabile per design: è la base della cifratura zero-knowledge. Se la perdi, perdi l’accesso al vault e i dati restano cifrati in modo irreversibile. Per questo è essenziale conservarla in modo sicuro offline e impostare un metodo di emergenza prima che serva.

Vaultwarden supporta le passkey?

Sì, tramite i client Bitwarden recenti puoi salvare e usare passkey nel vault, e accedere a Vaultwarden con chiavi FIDO2/WebAuthn come secondo fattore. È necessario che il server sia raggiungibile via HTTPS con un dominio valido, perché WebAuthn richiede un’origine sicura.

Devo aggiornare Vaultwarden manualmente?

Sì, e ti consigliamo di farlo in modo controllato. Avendo fissato il tag versione nel file Compose, gli aggiornamenti non avvengono da soli: leggi le note di rilascio, esegui un backup, cambia il numero di versione e lancia docker compose pull && docker compose up -d. È più sicuro che inseguire automaticamente il tag latest.

Posso ospitare Vaultwarden dietro Cloudflare?

Sì. Cloudflare può fare da proxy davanti a Caddy, aggiungendo protezione DDoS e nascondendo l’IP del server. Attenzione però alla cifratura: imposta la modalità SSL su “Full (strict)” affinché il traffico resti cifrato fino al tuo server, e ricorda che i WebSocket vanno abilitati anche lato Cloudflare.

Vaultwarden è legale e conforme al GDPR?

Vaultwarden è software open source AGPLv3, perfettamente legale da usare. Self-hostarlo su server europei ti aiuta anzi con la conformità GDPR, perché mantieni i dati sotto la tua giurisdizione e il tuo controllo. Resti tu il titolare del trattamento, quindi le responsabilità su sicurezza e accessi sono a tuo carico.

Conclusione: il controllo vale lo sforzo

In dodici step hai costruito un gestore password self-hosted completo: container Docker isolato, HTTPS automatico con Caddy, pannello admin protetto da Argon2, registrazioni chiuse, 2FA hardware, backup giornalieri e fail2ban a guardia dei login. Vaultwarden 1.36.0 ti dà, gratis e sul tuo hardware, funzionalità che altrove richiedono abbonamenti, con la stessa cifratura zero-knowledge di Bitwarden ufficiale.

Il prezzo è la responsabilità. Un server self-hosted è sicuro quanto la sua manutenzione: aggiorna i container, verifica i backup ripristinandoli, tieni d’occhio i log. Fatto questo, hai un vault che nessun cambio di policy aziendale, nessuna acquisizione e nessun datacenter lontano può toccare. I tuoi segreti restano tuoi.

Approfondimenti correlati

Fonti e risorse esterne