docker and ufw serious problems #4737
Comments
Ufw is only setting things in the |
@Soulou would you recommend adding to mangle or nat? edited previous comment after some research |
In my case I wanted to only allow a specific IP to connect to the exposed port. I've managed to do this with this rule. It drops all connections to port
|
@honi In Docker 1.5 (maybe 1.4?) there were several iptables changes. Can you verify if this is still a problem with 1.5? |
@cpuguy83 I can confirm that this is still a problem with Docker 1.6 Adding |
+1, still a problem with Docker 1.6 |
So what is the story here? With Docker version 1.7.0, build 0baf609 on Ubuntu 14 this is still completely broken. Also the installaton instructions on https://docs.docker.com/installation/ubuntulinux/ have a section "Enable UFW forwarding" which appears to be unnecessary. Anyone installing docker on an Ubuntu box exposes any forwarded ports from their containers to the outside world, and even worse looking at the ufw rules gives no hints that this is occurring which is needless to stay pretty bad. |
Also with Docker 1.7 here. My experience is that Docker+UFW can facilitate two scenarios. The first scenario and default behavior indeed exposes all mapped ports to the outside world; UFW cannot filter access to the containers. Alternatively when setting the In my opinion a sensible default behavior for docker would be how it behaves currently with |
I don't have a problem getting out. Did you try: ufw allow in on docker0 |
@newhook |
I have been experimenting with this a few hours now. I think I got it figured out.
The FORWARD chain does need policy set to ACCEPT if you have What you need for a setup that allows filtering with UFW, inter container networking and outbound connectivity is
|
You are indeed correct! After a reboot communication is gone. Those rules seem to sort everything out. Thanks very much! |
with this setup its not possible anymore to access exposed ports from within a container:
|
@dakky I can't reproduce your issue. I have no issues with inter container communication. I suggest making sure you expose the port in your Dockerfile. Also try flushing your iptables rules and delete all user-defined chains before configuring and enabling UFW. In any case it would be good if someone from the Docker team can verify that the configuration I propose makes sense. |
Hi, any update on this? I can't find any official source how to fix this.
.1 I can reach Internet from container Am I missing something here? 10x |
I had managed to fix this through iptables
|
This is still a problem. Is there a clear fix available? I don't expect a built-in solution. But maybe some |
Guys, this is a serious security issue. Why is there no hint in the documentation for it? Only by accident I found out, that my MySQL Port is wide open to the world. I absolutely didn't expect that as I've used |
For the record, the solution from @VascoVisser worked for me with docker V1.10. Here are the files I had to change:
UPDATE: On Ubuntu 16.04 things are different, because docker is started by systemd, so
and issue |
@mikehaertl I want to mention that this is not really an issue just with UFW, as it is just another layer over iptables. This is a general problem in my opinion. |
@lenovouser Thing is, that the documentation has some recommendation which sounds like "do this and everything is fine with ufw". But that's definitely not the case, so there should be big warning signs there. |
Let me re-explain it in a simple way ^_^ If there is a Linux server:
Create an httpd container, mapping the host's port
If using if using |
@chaifeng Thanks for your detailled explanations. One question to your last example: So if you now connect from outside to your host on port 8080 you'll reach your httpd container, even though you never issued |
Correct,
|
To prevent ufw startup problems, we use the before.init. All in all targeting
https://gist.github.com/rubot/418ecbcef49425339528233b24654a7d |
@rubot @tsuna As @chaifeng showed your solution is not bullet proof. I try to sum it up in my own words:
|
this should end up in an nat rule setup by docker, as docker is using masquerading.
|
can´t confirm that:
|
ah, had an error
thanks, will check that |
Hi @rubot At the beginning of this thread, @Soulou has a comment #4737 (comment)
|
Hi @rubot I found your typo, the port of
should be
Thanks! |
As we don´t have a rule in ufw-user-input that is allowing port 8000, this prevents as expected. |
One more thing I noticed, you modified the file As UFW use For example, add the following lines to the end of
|
This crashed a lot of times, as |
Quickfix: https://gist.github.com/rubot/418ecbcef49425339528233b24654a7d#file-docker_ufw_setup-sh-L152 |
This fix works in the first place as expected, so far. I tried to workaround with a static ip for the stream instance, but static ips for ingress are not supported, yet: |
Because I have to finish it and can´t switch to something different, or even fiddle with custom docker iptables, a cronjob will help for retrieving the origin ip again https://gist.github.com/rubot/418ecbcef49425339528233b24654a7d#file-docker_ufw_setup-sh-L55 Edit: |
…ent http ip address - implementing ufw-docker solution from moby/moby#4737 (comment)
@mikehaertl, I could not replicate it, your scenario works fine for me, i.e. host port 456 is not publicly opened. |
Make sure that Run the command to start an httpd container and publish the container port
We can access port Even |
@chaifeng, I tried what you suggested, and I can confirm that it opened the port 28080 from the outside. It does that also for nginx container. But, for some reason, jekyll container, which publishes a port too, is not opened from the outside. Here is my docker-compose.yml:
28080 is open from the outside, but 28081 is not. That's why it gave me an impression that it's a working solution. Any idea why jekyll's published port is not opened from the outside? |
@xhafan Did you see this? You probably have 80 open, that's why 28080 is also open for your httpd container. In your jekyll case port 4000 must be open on the host. Then 28081 would get opened implicitely, too. |
I think the port Allow port
|
@mikehaertl, @chaifeng thanks for the explanation. That it quite weird behaviour, however the whole solution works for me. One needs to be aware of it though. |
@tsuna I like your solution. But if I apply it the first time I disable and enable the ufw to apply the changes everything works as expected. But if I then reload the ufw or execute ufw disable/enable again I get the following error from ufw and ufw is then inactive.:
The problem goes away if I comment out the rule Edit: I know think I understand what's happening. The default setting for MANAGE_BUILTINS is no. Which means that ufw will not touch any chains except its own. But by adjusting the after.rules like @tsuna suggests we are changing other chains. Now ufw can't clean up the rules correctly. |
I don't know maybe it's not relevant already but when I create {"iptables": false} And restart docker So the question do I miss something or this is just fine? |
Having installed ufw and blocking all incoming traffic by default (
sudo ufw default deny
) by running docker images that map the ports to my host machine, these mapped docker ports are accessible from outside, even though they are never allowed to be accessed.Please note that on this machine
DEFAULT_FORWARD_POLICY="ACCEPT"
as described on this page http://docs.docker.io/en/latest/installation/ubuntulinux/#ufw has not been enabled and the propertyDEFAULT_FORWARD_POLICY="DROP"
is still set.Any ideas what might causing this?
Output of ufw status:
Here is the output of my rabbitmq via
docker ps
:Nmap test:
General infos:
The text was updated successfully, but these errors were encountered: