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.
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
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.
Yes - again you’re talking about “theory” and I agree completely. I’m not arguing with you.
I’m saying that “dude you’re probably fine if you’ve opened your firewall for a while to get something working”.