Selfhost Bitwarden || One key for all doors

B

Introducción

A raíz de un viejo hilo de seguridad informática en el que se acabó recomendando el uso de la aplicación Bitwarden como gesdtor de contraseñas, muchos usuarios decidimos dar el paso y cambiar a dicha aplicación en lugar de utilizar la misma contraseña para todos los sitios web y/o utilizar el gestor de contraseña de los navegadores.

Como buena persona amante de la privacidad que soy, decidí dar el paso de mantener mis aplicaciones en mi propio servidor para así prescindir de servidores externos. Para ello instalé una imagen no oficial de docker a través de docker-compose que lleva funcionando más de año y medio sin problemas.

La razón de este hilo

El haber prescindido de la nube propia de bitwarden para almacenar mis claves puede llevar a un gran problema: La pérdida de todos los datos. Si bien, en mi caso, tengo montado un raid5 y hago backups semanales a onedrive (de forma encriptada) esto no quita que, por negligencia o inseguridad, me transmita más tranquilidad el tener cierta información sensible en nubes externas que, por lo general, suelen ser menos propensas a fallar.

Y esto nos lleva al propósito general del hilo: ¿Qué ocurre si pierdo la conexión de internet de mi casa y el servidor se desconecta de la red?. El usuario @hda propuso en el hilo original una solución, utiizar un servidor externo para levantar el servicio inmediatamente.

Opción 1

En mi caso dispongo de un vps de oracle (free tier) en el que tengo montada una herramienta que monitorea mi red y, en caso de que haya una caída, se manda automáticamente una notificación vía telegram. Entiendo que, creando un pequeño script (¿En python? ¿Bash?) se podría levantar automáticamente el contenedor y cambiar las DNS del subdominio para que apunte a este nuevo servidor. Para ello haría falta duplicar contenedores del servidor local al servidor de origen:

Opción 2

En el caso de querer usar AWS (como hda) y no querer depende de argo tunnel (y abrir puertos), se ha propuesto utilizar la siguiente imagen para montar un DDNS en el propio servidor.

Dicho contenedor podría solventar el problema de cómo cambiar las rutas CNAME en caso de que uptime kuma indique que se ha perdido la conexión con el servidor local.

Elegir lo más versátil

Ahora llega el momento de decidir cómo y con que tecnología implementarlo. Sinceramente, desconozco si herramientas como terraform nos podrían ayudar en algo, entiendo que para el manejo de contenedores en todo caso nos podría valer kubernetes pero nunca he utilizado ninguna de las dos.

Me gustaría que nos diérais vuestra opinión y conocimiento con respecto a este tema del que, seguro, podemos (y yo el primero) aprender mucho más.

Muchas gracias a todos.

5
Aziwar

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.

Al final, pierdes en seguridad y no ganas realmente en privacidad.

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?
Tener seguridad? Te puedo asegurar que cualquier solución hosteada va a ser mejor que la tuya por una simple razón: recursos. Para ti es un hobby, para otros es su trabajo.

Hoy en día necesitas saber una password, la de tu email, fin. Que cerrastes una sesión y el servicio aún no usa el móvil como primer factor (que como digo, es la tendencia), pues recuperar contraseña, y adelante.

Y si la respuesta es que eso es un coñazo porque borras cookies cada día... Volvemos al threat model, cuál es en este caso? Qué consigues con borrar las cookies? No tener tracking? Qué tracking evitas en verdad con eso? Las cookies cross-site están más que deprecadas ya, y sin embargo, el tracking te viene a nivel del servicio en verdad. Si los servicios que usas tienen opción de descargar tu información, has mirado como de categorizado estás? Eso es lo que realmente importa.

1 2 respuestas
Kandelario

Doble factor de autenticación y el correo con una password realmente fuerte, esa es toda la seguridad que empleo y al menos debería emplear toda la gente.

B

#2 Yo uso bastante vaultwarden... uno montado en una raspberry y envío desde archivos a secretos de toda clase. Si sabes lo que haces no debería de ser problema. Además de que te ofrece alguna que otra herramienta interesante para la administración de las contraseñas.

Lo de la seguridad es discutible, ten en cuenta que tus datos en concreto no le importan a nadie.... lo que interesa es explotar grandes bases de datos que es de donde se puede sacar dinerito.
En cuanto a privacidad, claro que es más privado. De hecho, si quieres puedes aislarlo para que solo funcione en tu red local.

Lo de que solo necesitas saber la contraseña de tu correo, depende. Yo necesito saber contraseñas que son combinaciones de botones, accesos de bases de datos, de servidores, etc.. etc... Internet es más grande que facebook, google, etc.. :P
Además, pulsar CTRL+SHIFT+L y que se autorrellene es salud.

Lo que comentas de ver cuantos datos tienen las plataformas sobre ti me parece un buen consejo. Todo el mundo debería de darse un paseo por las opciones de configuración de sus servicios de internet de confianza... además de los programas e incluso del sistema operativo.

A mi me gusta el mundo del self-hosting y para mi el futuro de internet es descentralizado o no es... :B

squ4r3

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.

1 respuesta
B

#5 Los cortes de luz no deberían de ser un problema... no solo por la frecuencia y duración sino porque al momento de volver la energía simplemente se iniciará todo de nuevo. Otra cosa es que salte la luz... pero ya debes tener mala suerte. Lo que más preocuparía es que la raspberry se quede colgada. Algo que puedes evitar bastante si no la overclockeas.

Muchas empresas usan soluciones como HashiCorp montados en sus servidores dedicados. No distan mucho de soluciones como vaultwarden, solo que unas están enfocadas al ámbito de la empresa (se requiere manejar usuarios, permisos, dominios, conectores, etc...) y otras a particulares (más simples y directas).

hda
#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.

1 2 respuestas
werty

#7 si está muy chulo, pero totalmente innecesario si realmente el objetivo es la de tener tus contraseñas en un lugar seguro. Pues se antoja menos seguro que las soluciones disponibles.

1 respuesta
hda

#8 ¿Qué es lo innecesario? ¿Tener tu vault en propiedad en vez de depender de un servicio cloud?

willy_chaos

Bitwarden para compartir contraseñas es de pago, Vaultwarden trae todas las funcionalidades desbloqueadas.

Yo lo uso para compartir con la parienta passwords tipo Netflix, Disney+, la de la app de la Romba....

#1 Yo lo tengo en docker con proxypass de nginx, siguiendo este tuto

https://www.flopy.es/bitwarden-vs-vaultwarden-instalacion-y-uso-de-un-gestor-de-contrasenas-en-tu-propia-nube/

En el curro lo usamos para las password de los servidores, servicios, compartir passwords con los tecnicos de campo... es sencillo y funcional.

#7 confirmo lo de la cache, hice pruebas de conectar la app del telf y luego tumbe el servicio, continuaba teniendo acceso a las passwords

2 1 respuesta
hda

#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
1 respuesta
willy_chaos

#11 en esa web, el ultimo comentario (el de nginx) es el mio, ahi esta mi codigo del nginx proxy pass por si te sirve

#11 y porque le haces un bucle, no seria mejor un cron cada 15 min? si quieres algo mas fiable a la hora de hacer checks, también puedes tirar de zabbix (aunque ya es montarte un tinglado de monitoring), tiene web monitoring, que le puedes decir cada X min haga el check

1

Usuarios habituales