Linux

47923 readers

1171 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

AgreeableLandscape@lemmy.ml

nooter692@lemmy.ml

MarcellusDrum@lemmy.ml

cypherpunks@lemmy.ml

cyclohexane@lemmy.ml

d3Xt3r@lemmy.nz

What am I doing with iptables? (lemmy.pe1uca.dev)

submitted 3 months ago by pe1uca@lemmy.pe1uca.dev to c/linux@lemmy.ml

10 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] lemmyvore@feddit.nl 11 points 3 months ago* (last edited 3 months ago) (1 children)

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.

[–] pe1uca@lemmy.pe1uca.dev 1 points 3 months ago

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.