Selfhost Bitwarden || One key for all doors

Puf, no sé... a mí no me llaman nada los gestores de contraseñas y si los usara (más allá del que tengo que usar obligatoriamente por trabajo) nunca lo selfhostearía. ¿Qué ganas realmente? ¿Por qué quieres responsabilizarte de la seguridad de algo tan crítico?

Me parece algo muy serio como para "jugar" con ello y andar selfhosteando y homelabeando.

Terraform no creo que te ayude en nada btw, yo lo que tengo montado es un script en bash que cada minuto llama a AWS (donde tengo mis records dns) y compara la IP a la que apuntan los subdominios que uso con la IP de la máquina en ese momento. Si internet se cae, esas IPs no coinciden y el script se encarga de actualizar los records DNS en AWS. Si te interesa te lo paso. Luego tengo traefik para enviar cada subdominio a su correspondiente servicio.

Pero el mayor problema no me parece que se reinicie el router, sino que se vaya la luz por completo. Una solución para eso puede ser tener una raspberry pi conectada a la misma red, que se inicia automáticamente al estar alimentada por USB, y que desde la Pi mandes un paquete WOL al equipo que quieres encender.

#2Aziwar:

sinceramente, veo completamente innecesario tener que hostearte tu propio password manager, más aún cuando la tendencia es a que el primer factor de verificación sea hardware y no una password.

(...)

Cuál es tu threat model? Tener privacidad? Privacidad de qué? De una password? A día de hoy aún no tienes todos tus servicios protegidos con MFA?

Es interesante tu opinión, también discutible. Pero creo que hay algo que no estás teniendo en cuenta: la diversión de hacerlo. En lo personal, configurar este tipo de cosas (sea más o menos justificable su uso, sea sobreingeniería o no), es entretenido.

Ahora, entrando en contenido: tener tu gestor de contraseñas en local (como el keepass2) u "on premise" (NAS, VPS, etc.) es una buena práctica. Tienes el control de tus datos; no existe problema de exfiltración por parte de la compañía de la que dependas, cloud. Creo que hasta aquí es fácil convenir.

Ahora bien, acerca del objetivo de este hilo: un killswitch para lanzar automáticamente un backup de tu solución on premise es, de hecho, una buena práctica. Un sistema de seguridad por si fallase algo sobre tu sistema.

Por añadir algo de valor a mi comentario, he estado buscando y he encontrado que si tu solución on-premise deja de funcionar, el vault de bitwarden está guardado en caché en local (app o plugin), así que, en principio, de caer la solución seguiríamos teniendo acceso a nuestras contraseñas durante el tiempo que tardásemos en volver a levantarlo.

Mi situación actual es con mi vault en la nube, directo en Bitwarden. Si este hilo prospera y veo una manera entretenida y fácil de montarme mi vaultwarden con un killswitch por si se cae muy posiblemente intentase adoptar la solución.

Gracias a #1 por crear este interesante hilo. A ver a dónde nos lleva.

#10 ohhh, genial me viene. Lo debería adaptar para traefik. No me preocupa mucho el lenvantar el contenedor y asignar un subdominio. Genial que confirmes lo de la caché. La verdad es que al final conseguí que mi chica adoptase también un gestor de contraseñas, también bitwarden. Estaría genial poder compartir contraseñas mediante vaultwarden. Cada vez me llama más este proyecto. En concreto solo me falta el tener claro cómo hacer el killswitch. Copypasteo el pseudocódigo que dejé planteado en el otro hilo:

El pseudocódigo burdo del script entiendo que sería algo como:

while check
   wait 15 minutos
   ping check a tu subdominio
   if loss: check = False
end

aws-cli copiar a S3 el último backup de BW (si es que no está ya)
aws-cli lenvantar docker BW con los volumes de la línea anterior
aws-cli levantar docker cloudflareddns para que cambie la dirección del subdominio