I set up an *arr stack and made it work, and now I’m trying to make it safe - the objectivly correct order.
I installed uncomplicated firewall on the system to pretend to protect myself, and opened ports as and when I needed them.
So I’m in mind to fix my firewall rules and my question is this: Given there’s a more sensible ufw rule set what is it, I have looked online I couldn’t find any answers? Either “limit 8080”, “limit 9696”, “limit …” etc. or “open”. Or " allow 192.168.0.0/16" would I have to allow my docker’s subnet as well?
To head off any “why didn’t you <brilliant idea>?” it’s because I’m dumb. Cheers in advance.
Oh, just saw this:
TL:dr;
No, the host has no idea what happens inside a docker network.
The exception is if the containers are on the same host and joined to the SAME docker network (docker compose does this automatically)
It seems like your home network is on 192.168.something. Youve omitted any details to describe what subnet it is within an entire 182.168.0.0/16 block that is dedicated to local network addresses (rfc1918) but that doesnt matter. And docker uses a different dedicated block of 172.16.0.0/12.
Regardless!
Your host has an ip of 192.168.1.4. A client on 192.168.1.5 knows exactly how to communicate to 192.168.1.4 (provided they are in the same subnet… Which is likely on a standard home DHCP served network. Im glossing over this).
Googles DNS server is 8.8.8.8. Which is outside of your home networks subnet (192.168.1.0/24 in CIDR notation). So client 192.168.1.5 has no idea how to contact 8.8.8.8. So it sends the connection to its default gateway (likely 192.168.1.1) as it is an unknown route. Your router then sends it to the internet appropriately (doing NAT as described elsewhere).
What Im saying is that clients within the 192.168.1.0/24 network know how to talk to eachother. If they dont know how to talk to an IP, they send to the gateway.
Now, docker uses its own internal network: 172.16.0.0/12. To a client on 192.168.1.5/24, an ip inside 172.16.0.0/12 is as strange as 8.8.8.8/32. It has no idea where to send it, so it goes to the default gateway. Which isnt helpful if that network is actually INSIDE the host at 192.168.1.4/24.
What am i getting at? Docker runs its own NAT.
It takes the host’s ip address. When you expose a containers port, you are telling docker to bind a host port and forward it to the specific port of the specific container.
So outside of the host, the network has no idea what 172.16.0.0/12 means, but it does know what 192.168.1.4/24 means.
Inside the docker network, a container has no idea what 192.168.0.0/16 means, but does know 172.16.0.0/12 means. Equally, a docker container will send packets to its default gateway inside that 172.16.0.0/12… Which will then respond aporopriately to the 192.168.1.0/24 client.
Which means a dcoker containers host firewall is going to have no idea whats happening inside a docker network. All it knows is that docker wants to recieve information on port 443, and that the local network is 192.168.1.0/24. … Ish, there are other configurations