Note: iptables is "deprecated" you should be using nftables. Even Debian is on nftables nowadays.
this post was submitted on 24 Jul 2024
43 points (100.0% liked)
Linux
47151 readers
1406 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
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.
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".
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.