La semana pasada publiqué la guía básica de Vaultwarden. Ahí contaba por qué me compensa más que seguir pagando un gestor alojado por otro y cómo dejarlo funcionando en poco tiempo. Esa parte está bien para arrancar, pero si te quedas ahí te falta lo importante.
Vaultwarden no es un servicio cualquiera. No es un dashboard más, ni un lector RSS, ni una app para ver métricas del NAS. Aquí vives con tus credenciales, tus notas seguras, tus TOTP y en muchos casos la puerta de entrada al resto del homelab. Si esto lo montas regular, el problema no es que falle una tarde. El problema es que estás haciendo malabares con la pieza más sensible de toda tu casa digital.
Mi opinión es simple: el post de instalación te pone en marcha, pero el trabajo de verdad empieza cuando decides cómo lo vas a proteger, cómo lo vas a actualizar y cómo lo vas a recuperar el día que algo se rompa.
Además, esta semana ha habido una razón extra para ponerlo sobre la mesa. La release 1.35.4 de Vaultwarden salió con varios parches de seguridad importantes. Nada como una tanda de advisories para recordar que el “ya actualizaré luego” es una estrategia bastante cutre cuando hablamos de contraseñas.
lo primero: HTTPS o mejor no sigas#
La documentación oficial del proyecto lo dice bastante claro. El web vault necesita un contexto seguro para que funcione bien con la Web Crypto API. En limpio, eso significa HTTPS, salvo la excepción local de localhost para pruebas.
Yo aquí no negocio. Si un servicio maneja contraseñas y solo vive detrás de HTTP, para mí no está montado. Está medio montado.
Mi forma favorita de hacerlo es sencilla. Publico Vaultwarden solo en loopback o en la red interna de Docker y pongo delante un reverse proxy. Puede ser Caddy, Nginx Proxy Manager, Traefik o el que más rabia te dé. La idea es siempre la misma: TLS fuera, Vaultwarden detrás, y nada de exponer el contenedor alegremente a internet en un puerto cualquiera.
El patrón básico es este:
| |
Ese 127.0.0.1:8000:80 me gusta mucho más que un 0.0.0.0:8000:80. El motivo es obvio. Si el proxy vive en el mismo host, no necesito que el contenedor escuche para todo el mundo. Cuanto menos expongo, menos superficie regalo.
La wiki oficial del proyecto también recomienda terminar TLS en el reverse proxy en vez de complicarte con TLS dentro de Vaultwarden. Coincido. Menos piezas raras, menos probabilidad de meter la pata y más fácil de mantener.
cerrar registros abiertos no es paranoia, es sentido común#
En una instalación personal o familiar, SIGNUPS_ALLOWED=false debería ser casi automático.
No necesito que nadie se registre libremente en mi servidor de contraseñas. No hay ningún premio por dejar esa puerta abierta. Si mañana quiero añadir a un familiar o a alguien de mi equipo, lo hago de forma explícita desde administración o mediante invitación controlada.
Este punto parece menor hasta que recuerdas que un gestor de contraseñas es también una base de usuarios, dispositivos, organizaciones y sesiones. Cuanta más lógica de alta pública dejes activa sin necesidad, más cosas tienes que vigilar.
Si solo haces una cosa después de instalarlo, que sea esta.
el panel de admin es útil y también da bastante miedo#
El panel de administración de Vaultwarden es potentísimo. Te deja ver usuarios, organizaciones, diagnósticos, invitaciones, configuración y bastante más. Por eso mismo conviene tratarlo con respeto.
La wiki del proyecto recomienda varias cosas y aquí no voy a ir de listo porque me parecen correctas.
La primera es usar HTTPS antes de habilitarlo.
La segunda es definir un ADMIN_TOKEN largo y aleatorio.
La tercera, y esta la veo menos aplicada de lo que debería, es no guardar ese token en claro si puedes evitarlo.
Vaultwarden permite usar un hash Argon2id para el ADMIN_TOKEN en formato PHC. Esto me parece muy buena idea porque reduce el daño si alguien acaba viendo tu fichero de configuración o tus variables de entorno. No hace magia, pero mejora bastante la historia.
Un ejemplo de enfoque sería generar el hash y luego ponerlo como variable de entorno:
| |
Después pegas la cadena PHC resultante en ADMIN_TOKEN. No es la opción que veo en la mayoría de tutoriales y precisamente por eso quería mencionarla. Muchas guías se quedan en “pon una cadena larga” y a correr.
Hay otro detalle que conviene saber. La wiki explica que el panel usa un JWT de sesión para autorizar el acceso y que la duración por defecto de la sesión de admin es de 20 minutos. Está bien. No necesito más. Cuanto menos viva una sesión de administración, mejor.
Y si alguna vez sospechas que hay una sesión vieja por ahí dando vueltas, la propia documentación indica un método bastante directo para invalidarlas: eliminar rsa_key.pem del directorio de datos y reiniciar para que se regenere la clave. Es de esos detalles que quieres conocer antes de necesitarlo y no cinco minutos después.
Yo, además, intento que /admin no sea accesible desde cualquier sitio. Si tu proxy te deja limitar por red, mejor. Si además entras por Tailscale o por una VPN, todavía mejor. No me obsesiona esconder rutas, pero sí reducir quién puede siquiera ver la puerta.
actualizaciones: este no es el contenedor que dejas seis meses en paz#
Uno de los problemas del self-hosting cómodo es que te acostumbras a que algo funcione y lo dejas quieto demasiado tiempo. Con Vaultwarden eso me parece una mala costumbre.
La release 1.35.4 ha salido con varias correcciones de seguridad serias. Una de ellas permitía acceso a un cipher de otro usuario si ya conocías su UUID interno. Otras afectaban a permisos de organizaciones y colecciones. No voy a dramatizar, pero tampoco voy a restarle importancia.
Si tienes Vaultwarden publicado hacia internet, o accesible desde fuera de tu red, mi criterio es este: no actualices a ciegas el mismo minuto que sale una imagen nueva, pero tampoco te duermas quince días como si fuera un servicio irrelevante.
Mi rutina preferida es simple.
Primero leo las notas de la release.
Segundo hago copia de seguridad.
Tercero actualizo la imagen.
Cuarto pruebo login, sincronización, adjuntos y panel de admin.
Quinto reviso si la app móvil y la extensión del navegador siguen contentas.
No es glamuroso, pero tarda poco y evita sustos muy tontos.
el backup bueno no es el snapshot bonito#
Aquí también la wiki del proyecto es bastante clara y me parece sano repetirlo. No recomiendan confiar en snapshots de VM o del sistema de archivos como método principal de copia. Sirven como capa adicional, pero no como única estrategia. Estoy de acuerdo.
En el caso más habitual, Vaultwarden corre con SQLite. Eso significa que casi todo lo importante vive en el directorio data. La base db.sqlite3 es crítica, sí, pero no es lo único que importa. También están los adjuntos, los ficheros rsa_key.*, posibles sends, config.json si has usado el panel de admin, y la caché de iconos.
Si solo copias db.sqlite3 y te olvidas del resto, luego vienen las sorpresas.
La propia wiki sugiere que, para SQLite, la forma correcta de hacer una copia consistente del archivo es usar la API de backup de SQLite a través del comando .backup, no simplemente copiar el fichero al vuelo mientras está en uso. Me parece un consejo excelente y demasiado poco seguido.
Un ejemplo básico:
| |
Después de eso, copio también los adjuntos y los ficheros de claves a un backup cifrado fuera del host. Para mí, un backup que vive en el mismo servidor no es backup. Es optimismo.
Mi esquema mínimo para Vaultwarden es este:
- copia consistente de la base SQLite
- copia de
attachments,sendsyrsa_key.* - al menos una copia remota
- cifrado extra si el backup incluye configuración sensible
- prueba de restauración cada cierto tiempo
Lo último es el que más gente se salta. Entiendo por qué. Restaurar da pereza. Pero entre una copia que no has probado y una foto bonita del directorio en otro disco, la diferencia práctica puede ser cero.
no mezcles comodidad con seguridad en el mismo cubo#
Hay varias decisiones que parecen cómodas el día uno y me parecen malas el día treinta.
La primera es dejar el admin token en claro en un compose que termina en un repo privado, en un backup sin cifrar y en el historial de la shell. Todo junto. Esa combinación da bastante asco.
La segunda es usar el mismo host para Vaultwarden y para veinte servicios expuestos con reglas improvisadas, puertos heredados y certificados que no revisas. No digo que tengas que dedicarle una máquina solo a esto, pero sí que merece más mimo que el enésimo panel de estadísticas.
La tercera es depender de un único método de acceso. Si rompes el proxy, si caduca un certificado, si tocas DNS sin pensar o si haces una actualización floja, quieres tener un camino claro para volver a entrar sin improvisar una cirugía a ciegas.
La cuarta es olvidarte del correo saliente. El SMTP no es obligatorio para que Vaultwarden arranque, pero es muy útil para avisos, invitaciones y ciertas comprobaciones de cuenta. Yo no lo dejaría para “ya luego”.
qué guardo y qué no guardo#
No todo merece la misma protección.
El contenedor se puede recrear. La configuración del proxy se puede rehacer. La imagen se puede volver a descargar.
Lo que de verdad cuido es esto:
- datos del directorio persistente
- token de administración o su hash
- credenciales SMTP si las uso
- copia de la configuración del proxy
- procedimiento de restauración escrito en algún sitio que no dependa del propio Vaultwarden
Eso último parece una tontería hasta que imaginas un fallo serio. Si todas tus notas seguras, contraseñas y pasos de recuperación dependen del servicio que está caído, te has montado una trampa bastante elegante.
passkeys, 2FA y otras funciones que sí merecen la pena#
Una de las razones por las que Vaultwarden compensa es que no te obliga a renunciar a clientes buenos. Sigue siendo compatible con los clientes oficiales de Bitwarden y eso te da apps móviles, extensiones y escritorio sin inventos raros.
A nivel de funciones, el proyecto cubre bastante más de lo que mucha gente cree. En el repo oficial se listan soporte para organizaciones, adjuntos, Send, claves API personales, acceso de emergencia y varios métodos de segundo factor como TOTP, email, FIDO2 WebAuthn, YubiKey o Duo.
Mi consejo aquí es poco original, pero firme: activa 2FA para tu cuenta principal en el mismo momento en que el servidor sea estable. No esperes a tenerlo bonito. No esperes a cambiar de dominio. No esperes a terminar de importar todo. Actívalo y listo.
Y si compartes una organización con familia o con equipo, revisa permisos con calma. Los fallos más feos no siempre vienen de un atacante externo. A veces vienen de dar acceso de más por comodidad y olvidarte de que eso también cuenta como riesgo.
lo que yo haría hoy si tuviera que montarlo otra vez#
Si mañana tuviera que volver a desplegar Vaultwarden desde cero, mi secuencia sería esta.
Primero, contenedor atado a loopback o a red interna, nunca abierto alegremente.
Segundo, reverse proxy con HTTPS válido.
Tercero, SIGNUPS_ALLOWED=false desde el minuto uno.
Cuarto, admin token hasheado con Argon2id.
Quinto, 2FA activado en cuanto el login funcione.
Sexto, backup automatizado del directorio persistente y de la base con copia remota.
Séptimo, un calendario razonable de revisión de releases y avisos de seguridad.
Octavo, acceso al panel de admin restringido por red o por VPN.
No es una configuración exótica. De hecho, esa es la gracia. Son medidas bastante básicas. Solo que, cuando se habla de self-hosting, demasiadas veces se celebra el “ya funciona” y se aparca el “ya aguanta”.
conclusión#
Montar Vaultwarden en casa sigue pareciéndome una de las mejores decisiones de self-hosting que puedes tomar. Ahorra dinero, te da control real sobre algo muy sensible y encima corre en hardware modesto sin despeinarse.
Pero no lo trataría nunca como un contenedor más de la colección.
Si quieres hacerlo bien, piensa en capas. HTTPS delante. Registros cerrados. Admin panel bajo control. Actualizaciones con un mínimo de disciplina. Copias que puedas restaurar. Segundo factor activo. Y menos confianza ciega en que todo seguirá bien porque lleva tres meses funcionando.
El gestor de contraseñas es el sitio donde menos me apetece improvisar. En todo lo demás puedo permitirme un poco de caos. Aquí no.