In the same way that the XKCD hand-waved FTP, this article hand-waves the idea that we shouldn’t be concerned about who can access our self-hosted services.
I’m not saying it’s wrong, but I’d like more of an explanation on why we shouldn’t be concerned about allowing anybody on the internet having direct communication with our computers.
Welcome fellow instance owner!
If you’re worried about that possibility, then you should mitigate against it. I’m not saying everybody should do it… all I’m saying is that rejecting the idea out of hand is not necessary.
I don’t feel like I’m risking anything… I feel like I have an understanding of the attack vectors and I’ve mitigated those to a level that’s acceptable to me.
Risk tolerance is something we all have to judge for ourselves.
Yup… HUGE difference between human curated machine learning and generative AI. AI sure is a buzzword these days, which is why it gets used in marketing, but I think doing so is confusing people who don’t know enough to distinguish between the different flavors of “AI”.
I actually started on a VPS… I moved off because I was pegging the RAM and adding more to my plan was quite expensive. Performance is MUCH better on my home server with plenty of RAM.
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.
I don’t know enough about Apache to say one way or the other, but based on what you described, you SHOULD be able to get rid of the internal proxy. Since both the inner and outer are both NGINX, getting the settings right shouldn’t be a problem.
But, on the other hand, if it works it works!
Not sure what your solution was, but I eliminated the reverse proxy from the official compose stack and configured my existing reverse proxy to point directly at the lemmy containers. It works well for me.
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.
As I dug into this, I found that it is in fact trivial to change the Unraid UI ports. There’s a setting for it. I can only assume that since Unraid attracts a LOT of novices, bad advice gets passed around and taken as gospel. So, I changed Unraid’s ports, set my reverse proxy to listen on 80/443, updated the NAT on my router, and added the relevant host overrides to the DNS Resolver. Hairpin eliminated. Thanks again!
Totally fair… I appreciate you engaging with me, your perspective is appreciated! I won’t defend Unraid’s choice when it comes to the UI ports, but I will simply say that there are things that are really nice about Unraid from a usability standpoint.
Thanks again for your thoughts!
The challenge here is that the host is Unraid, which publishes its own interface on 80/443. My reverse proxy is of course handling all requests for my sites, but that is ALSO running on a container, and must be listening on something other than 80/443 when using host or bridge networking.
So, if I’m following along correctly, I would need to put my reverse proxy on a different host (bare metal or VM) in order for it to listen on 80/443.
I super appreciate where you’re coming from on this. Unless I’m mistaken, NAT port forwarding makes this not quite so clean. If my (internally hosted) site is published on ports other than 80/443, is there any way to route them internally without needing to include the port in the request?
If not, then I either have to include the port in my request when I’m inside the LAN, or I need to set up a macvlan in my docker network to facilitate a LAN IP and standard ports.
Do I have that right?
I read “Networking for Dummies” in 2005, and it gave me a GREAT baseline understanding. I don’t recall how much it discussed ipv6 at that time, but I imagine the newer editions cover it.