Of the many useful things I could do with my spare time instead I’m setting up a Lemmy instance because why not. The scope of this is definitely greater than any self-hosting I’ve ever attempted, so please feel free to tell me just how much trouble I’m in. I’m just giving the broad strokes to see if I’ve made any crucial errors (other than deciding to do this at all).
And if this is a completely wrong place for a post like this or I’m missing data I’m supposed to include I apologize, I probably need a sanity check, in more ways than one.
First limitation, I’ll be hosting it on an existing Linux Mint box acting as a file share mostly and occasional gaming PC/movie streaming box. Its hardware is overkill for this, I do not anticipate issues when it is in use. It receives regular updates and weekly reboots, instance will be set to automatically restart. NVMe with loads of space for local storage, RAID SSDs for data offload/backup.
Second limitation, I hate Cloudfare and Oracle. I do not want to use either of them.
Third limitation, money. Cheaper is better. I have a URL picked out and a registrar which will give me the cheapest long term option, in case I actually keep this thing going.
Last limitation, I’m already in over my head so I’ll be relying on a lot of googling and probably some chat bots to figure things out as I go through the actual deployment process. What could go wrong?
So, Lemmy hosted on Linux Mint box using Docker containers. ISP is a good one for this I’m told, no CGNAT, largely stable public IP but I’ll have a script running in case it does change. Confirmed ports 80/443 are open. Using Caddy for the HTTPS. Closed registration to start, if by some miracle I make it to actually wanting to allow additional users it will not be fully open, and I’ll use Brevo for the email SMTP. Security wise I know I’m making it harder for myself by exposing my IP, I’m going to have UFW running and Crowdsec to help keep incoming bad traffic out.
Down the line I’ll get Lemmy updates, backups, retention rules in place/automated, and make decisions on federation, etc. Thoughts?
I don’t get this perspective. A reverse proxy pointing at containerized applications gives you plenty of buffer between the scary internet and your personal files. Don’t bind mount your entire host file system to the container, and only open/forward the ports you need.
There are things you have to get right, but there’s no reason to discard the idea altogether.
I’m somewhere in the middle, because comments like yours actually reinforce my concerns. A reverse proxy isn’t really doing anything to make you more secure, unless you’re using it for some sort of access control. It hides which ports you’re using, and allows you to encrypt your traffic with TLS… But it doesn’t add any additional security to the services you are exposing.
Maybe if you use it for access control, to add a secondary username/password to the services. But that breaks most legitimate things (apps, mostly) that try to reach the double-password-protected service. Because a user on a web browser may be able to type in two passwords, (one for the reverse proxy, and then one for the service itself) but an app will try to pass that info automatically using headers.
Any vulnerabilities in the services will still become potential attack vectors. Anyone who remembers the Huntarr debacle will know exactly what I’m talking about, because a single service being vulnerable can do a lot of damage. Yes, containerization does a lot to help mitigate damage by excluding access to everything except what you give it. But it won’t completely stop things from going wrong.
The point of the reverse proxy is that it simplifies your firewall configuration… you open one port (443) to one endpoint (your reverse proxy), and that’s it. The more complex your firewall configuration, the more likely you are to get something wrong and accidentally expose what you might not want to expose.
I do not use my reverse proxy for access control.
If you’re using containerized applications, then the worst-case scenario is somebody gets root permissions inside the container. Under those circumstances, they can destroy that instance of your application and access any data stored within the container. The thing is, they can ALSO do that if you’re on a VPS.
If there happens to be a Docker vulnerability that allows file system access to the host AND AT THE SAME TIME an application vulnerability, then you might be in trouble. The confluence of those two events, especially if you keep things updated, is unlikely enough that I have no reservations about hosting public services on my home network.
But that said… we all have our own level of risk tolerance. If it’s not right for you, then you shouldn’t do it.
edit: just reading up on huntarr and ooooh boy. Vibe coded app that asked you to provide API keys so it could talk to and control other services. No wonder it caused problems. It’s probably worth saying out loud: if the container you want to install is used to talk to and control other containers, you need to be EXTRA SURE that it’s reputable.
Those devices should most certainly be on two separate networks. Internet facing devices should be on a DMZ and not be allowed to talk to your internal network. You can then allow your internal network reach your DMZ devices, but only allow return traffic from the DMZ.