Don't use ip_forward to expose containers to the public internet

[docwhat]

Setting net.ipv4.ip_forward=1 is troublesome for various reasons, including security.

Would it be possible to stop using that and instead use something like iptables rule below instead?

Example for container started with --port 0.0.0.0:29418:29418

iptables -I PREROUTING 1 -t nat -i eth0 -p tcp --dport 29418 -j REDIRECT --to-port 29418

This should work, though translating 0.0.0.0 to eth0 is a potential problem. I'm not an iptables wizard, so there is certainly a better way to do this.

[phemmer]

The problem with that idea is that it results in the docker proxy being used for this traffic. The docker proxy has a very long and troubling history. But bugs aside, with a proxy, the applications running inside lose a lot of functionality having to go through a proxy (tcp only, client addr hidden, QoS flags stripped, etc). The container would also be unable to reach the public internet.

However there is indeed a concern here. Because docker turns IP forwarding on without adding any apropriate filter rules to the FORWARD chain, anyone on the local network is able to talk directly to a docker container on the host.

Thus I think an appropriate action here would be for docker to change the default policy on the FORWARD chan to DROP if ip_forward was not previously on. Docker already adds rules to the chain allowing container traffic, so no other changes would be required.

[dexterddit]

I`m trying as well to expose a container port to the host ip , is there any other solution t then the iptables one to expose a container port to hosts ip ?

[docwhat]

@dexterddit I'm working on a solution based on @phemmer's suggestion.

@phemmer I'm actually seeing two cases here:

1. A user who may or may not have a firewall tries to use docker and expects it to be secure.
2. Advanced users who have a fire wall and need docker to play nice with it and still be secure.

I think you suggestion for dropping unmatched forward packets is good for case 1.

For case 2 I think some else is needed. Like a hook that is passed the proposed rules so the can be injected in the right place.

[docwhat]

@dexterddit

So these rules seem to work reliably:

-A FORWARD -i docker0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o docker0 -j ACCEPT
-A FORWARD -j DROP

When containers are added and removed, docker inserts rules at the beginning of the FORWARD chain, so the above rules remain at the end; which is good since they would break things otherwise.

They also seem to survive restarting docker.

So @phemmer, can we make these rules automated in docker itself?

[calavera]

Please, feel free to open a PR with the suggested change for discussion. I'm sure this will get more 👀 as soon as it's on code 😄

[sanmai-NL]

When will this issue be addressed, @thaJeztah @jfrazelle?

[salmanbaset]

If the goal is to disable ip forwarding inside container, the container can be started as follows:
docker run --sysctl net.ipv4.ip_forward=0 ...

This makes it some what compliant with CIS rules for disabling ip forwarding, since a container is started without it. The host still has ip forwarding.

[docwhat]

What is CIS?

We wanted IP forwarding off on the host, tho turning it off in containers is interesting.

[bboreham]

I believe this should be closed by #28257, which sets the forward policy to DROP.

[thaJeztah]

Yes you're right, I think this can be closed

[jmarcos-cano]

sorry to ask this on a closed thread, but do we still need to enable ip_forward in a normal linux installation? what are the recommendations ? (I totally get that docker#28257 fixes ip_tables to make docker more secure)

@thaJeztah