I'm in the process of creating an SFTP only Docker container, one that will be used by multiple people for the sole purpose of uploading and managing files in their own chrooted Environment.
On paper, it's pretty secure: I'll disable every form of bash login, and I won't run any other process in it. However I would like to harden it just a little bit more:
I want to prevent this container from accessing the Internet from the inside, except for it's purpose of being an SFTP server.
To make things clear: I know how to prevent the outside world from accessing my container – I can setup incoming iptables rules, and I can expose only the SFTP port in my docker run command.
However I would like to make the following command (as an example) fail, when ran inside the container:
curl google.com
My intention is to diminish the amount of damage that a hacked container can do (not being able to be used to send spam email, etc).
Best Answer
It still makes sense to put some ingress rules inside your docker instance to help ward off attacks, but you will have to limit outbound (Internet) access from whatever upstream router the docker image connects with. The reason for this is, if you try to block outbound access with the firewall rules inside your instance, then if the instance is compromised those rules could be removed by the attacker. By blocking egress via the instance's router, you block outbound access even in the event of a compromise - the attacker would have to compromise the router as well.
Ok, so after receiving some commentary that explains that the filtering was intended for the container's host, it's a little clearer what is trying to be accomplished. In which case, on the host, you would add some rules similar to this:
The first two rules are for access between the host and the container. The third rule says (roughly) that anything that isn't the host's subnet headed for SFTP is just OK by us; the fourth is the outbound rule that is basically a twin to the third; the fifth rule is a catch-all (in case there are other related ports that are used), although it shouldn't be needed, you could probably remove it; the last rule is the magic on that prevents access to anything other than the host subnet. Because access is given in the first few rules, it will never trigger unless none of the preceding rules apply, in which case we are saying "we don't care what you want, you didn't match anything you're approved for, so you can't get there from here". Inbound traffic from the outside will be satisfied by the 3rd and 4th rules.