this post was submitted on 28 Jun 2023
19 points (100.0% liked)
cybersecurity
3249 readers
9 users here now
An umbrella community for all things cybersecurity / infosec. News, research, questions, are all welcome!
Community Rules
- Be kind
- Limit promotional activities
- Non-cybersecurity posts should be redirected to other communities within infosec.pub.
Enjoy!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've been working on a locally hosted instance of VaultWarden, deploying it locally is easy with Alpine but I want it accessible remotely. That requires some restructuring and trust. OpenBSD.Amsterdam is a good choice for that, a small instance of theirs works as my front end relaying to a system that connects over WireGuard to my local VW install with PGSQL back-end.
Presently my solution is 1P/BW for low value accounts, but a VaultWarden on a USB Armory Mk II for high value. The Somu works great for storing keys to open the VW vault. Overkill but it was fun to make.
Nice! I have a bunch of services I run locally but have been hesitant to expose to the internet so when I want remote access it's alwys over an openVPN connection. Why did you decide to go this route over just using wireguard directly from your client devices? I presume the openbsd box is just a reverse proxy?
I had some servers sitting around from a previous project and I put them to use.
As soon as I wanted a valid TLS endpoint I was going down the rabbit hole of tunneling the local services; ingress or egress I'd have "trust issues" that I would have to deal with such as where the vaults live and get the database to them, sshfs? zfs smb? nfs? So I decided to extend out for the public services and keep the private services a couple tunnels away from the internet.
The other nice part is that I can make a tmpfs/memfs mount for my vault and cache it at the edge, still working on that one. ;-)