I’ve only used ufw and just now I had to run this command to fix an issue with docker.
sudo iptables -I INPUT -i docker0 -j ACCEPT
I don’t know why I had to run this to make curl work.
So, what did I exactly just do?
This is behind my house router which already has reject input from wan, so I’m guessing it’s fine, right?
I’m asking since the image I’m running at home I was previously running it in a VPS which has a public IP and this makes me wonder if I have something open there without knowing :/
ufw is configured to deny all incoming, but I learnt docker by passes this if you configure the ports like 8080:8080 instead of 127.0.0.1:8080:8080. And I confirmed it by accessing the ip and port.
Note: iptables is “deprecated” you should be using nftables. Even Debian is on nftables nowadays.
You should not have to open such a permissive rule. Like you’ve seen, docker will set firewall rules as needed if you have services that actually need to listen on the public interface.
If you’ve run that permissive input command on the VPS it’s most likely not a good idea.
What exactly are you trying to do? If you’re trying to use curl from inside a docker container that is not the correct way to achieve that. In fact you should not need to do anything like that, outside connections should be allowed (OUTPUT), and incoming collections (INPUT) should be allowed only if they’re related to an already ongoing connection (look up the ESTABLISHED flag).
Any extra flag you can offer that would narrow things down would also be welcome. When you write firewall rules you should be as restrictive as possible. For example since this is curl you’re probably going to connect to ports 80 and 443 so you can add --dport to restrict the ports to the OUTPUT rule. And you should specify the interface (in this case docker0) in almost all cases.
I only had to run this in my home server, behind my router which already has firewall to prevent outside traffic, so at least I’m a bit at ease for that.
In the VPS everything worked without having to manually modify iptables.
For some reason I wasn’t being able to make a curl call to the internet inside docker.
I thought it could be DNS, but that was working properly trying nslookup tailscale.com
The call to the same url wasn’t working at all. I don’t remember the exact details of the errors since the iptables modification fixed it.
AFAIK the only difference between the two setups was ufw enabled in the VPS, but not at home.
So I installed UFW at home and removed the rule from iptables and everything keeps working right now.
I didn’t save the output of iptables before uwf, but right now there are almost 100 rules for it.
For example since this is curl you’re probably going to connect to ports 80 and 443 so you can add --dport to restrict the ports to the OUTPUT rule. And you should specify the interface (in this case docker0) in almost all cases.
Oh, that’s a good point!
I’ll later try to replicate the issue and test this, since I don’t understand why OUTPUT should be solved by an INPUT rule.
Having a port open is only a problem if something is listening on it that you didn’t want to be. Which may be your concern - just clarifying in case you weren’t sure.
Keeping a port open if you don’t want it open is bad practice.
Why even bother having a firewall then? I mean, why block any ports if you’re going to open the ports for services anyway, and there’s nothing listening on the others, right?
The point of having a firewall is that you start with DENY on all possible chains and interfaces, and you describe explicitly what is allowed to happen.
A firewall thus becomes a living specification of the networking rules for your server, the same way ansible for example describes the functionality.
If you’re not willing to do it like that then don’t bother having a firewall, there’s no point.
I’m responding to this
I’m asking since the image I’m running at home I was previously running it in a VPS which has a public IP and this makes me wonder if I have something open there without knowing :/
What you’re saying is true - but practically speaking there isn’t a real risk to having a port open that has nothing listening on it. Maybe a port scan can identity your OS a bit better.
The main goal should be having a thorough approach. People hear “firewall” and assume it means blocking things but it’s really about having a comprehensive network specification.
The command modifies the firewall to allow all incoming traffic on the docker0 network interface (which is created by Docker). It’s basically a bypass.
You can configure Docker to not try and manage it’s own rules, here is some discussion on the topic: https://github.com/moby/moby/issues/22054#issuecomment-2241481323
Do not disable that docker feature unless you know what you’re doing!
99% of users want it on. If you have an active firewall you want it to be restrictive, and you want Docker to open ports only as needed, and to keep track of container networks for you and to take down the permissions when you stop a container etc.
What clueless people do is disable this feature and then they make permanent rules that keep the ports open all the time, and/or attempt to keep track of rules by hand. The former is insecure, the latter is a hassle.
