Docker does not honor ufw rules.

[gnat]

I believe it is time to change the default behaviour on this. This is a re-occuring footgun for Docker.

Recently exploited in production: https://news.ycombinator.com/item?id=27613217

Previously reported: #4737

[BenjamenMeyer]

reported #22054 too - very long discussion there and several proposals on fixes

[AkihiroSuda]

Rootless mode can avoid conflicting with system-wide configurations such as ufw: https://docs.docker.com/engine/security/rootless/

$ dockerd-rootless-setuptool.sh install
$ docker context use rootless

[akerouanton]

I'm looking into all the Github issues regarding ufw integration and I'll come up with a RFC and/or a fix soon. As this is a duplicate, let me close this one.

[patrakov]

This is a duplicate of a wrongly closed issue, which is why I am not 100% OK with closing it too. Please provide a canonical place, in the form of an open issue, where we can follow your thoughts, RFCs, and/or a fix. Thanks in advance.

[gnat]

This issue was incorrectly closed- it was originally created because there is no open issue tracking this ongoing problem.

Previous issues were prematurely closed- @akerouanton seems to have unintentionally done this again.

Kindly, re-open this or the parent issue until this has a resolution, thank you.

@patrakov is 100% correct.

[BenjamenMeyer]

@gnat @patrakov this probably falls under the still open #22054 which talks about UFW but also points out that this is far more than just UFW as Docker mangles the network stack firewalls rules in such a manner that it completely bypasses them, and how it does it makes it invisible to tools like UFW as well. There's actually a much bigger issue here.

@akerouanton it would be great to consolidate down the various bugs to a single story that truly covers what is broken in Docker; however, please make that story very well known. I would also advise that whomever filed the original issue should be the one to close it when they are satisfied the issue is actually resolved or they agree it is a duplicate (good community relations).

[gnat]

Real talk: If we ignore how this was handled historically, that's fair- but this has been neglected for so long that I'm hesitant to actually close issues for fear of it getting buried again.

I'll come up with a RFC and/or a fix soon

I don't trust this given the history. Our friend is going to get re-assigned or fired or something. 🙄

Just let Docker Inc. close more than one issue when its finally solved.

[akerouanton]

Real talk: If we ignore how this was handled historically, that's fair- but this has been neglected for so long that I'm hesitant to actually close issues for fear of it getting buried again.

I don't trust this given the history.

I totally understand trust has been damaged with such a high-profile issue not being properly investigated. I get you.

I already felt like this issue was not purely technical, but also comes with its community side of things. Your reactions here make me realize it might be more important than I thought at first. I'll see how we can handle that too.

This is a duplicate of a wrongly closed issue, which is why I am not 100% OK with closing it too. Please provide a canonical place, in the form of an open issue, where we can follow your thoughts, RFCs, and/or a fix. Thanks in advance.

@BenjamenMeyer is right: I closed it because I consider it falls under #22054, although that issue is more generic.

@akerouanton it would be great to consolidate down the various bugs to a single story that truly covers what is broken in Docker; however, please make that story very well known. I would also advise that whomever filed the original issue should be the one to close it when they are satisfied the issue is actually resolved or they agree it is a duplicate (good community relations).

Thanks for that feedback, both points seems reasonable. I already noted all the issues (either open or close) about ufw reported in this repo, as well as in other docker repos.

I'll reopen this issue, and let @gnat decide whether they want to close it once the RFC/status update got published.

Our friend is going to get re-assigned or fired or something. 🙄

Except for any network-related regression we might need to find asap, my 1st priority is ufw.

After some investigation, I won't be able to provide a fix as soon as I first hoped. The ufw route rules only match packets after they're NATed, and at this point packets don't have the original dest ip/port. If we provide that, people will surely still be unhappy because they can't match the published ports.

As such, we probably need to meet halfway with ufw, to provide a way for users to either: 1. match packets before they're NATed ; or 2. afterwards, but on the original dest ip/port (which means leveraging conntrack entries). I'm currently testing some ideas within ufw codebase, to find to a good way to tackle this issue. I'll write my RFC/status update once I'm in touch with ufw maintainer(s).

[akerouanton]

I created a discussion about what's going on with custom iptables rules (whether created through ufw or manually) and what we can do to improve that. It's available here:

• Summary of the issues about custom iptables rules #45524

@gnat Feel free to close this issue if you think the discussion (and the proposed improvement) address your concerns.