4 ms·

If we accept that this is the default state of the Internet (insecure) then I think it is a correct assumption and forces everyone to think twice before exposin

If we accept that this is the default state of the Internet (insecure) then I think it is a correct assumption and forces everyone to think twice before exposing anything to the Internet by default. Here the default Docker behaviour was very much at fault but also the assumption that a Linux level firewall is good for Docker. We have docker deployments that are completely hidden behind NAT in AWS and such things are a non issue.

wkdneidbwf 4y ago
exactly. ideally, accidentally exposing your db to the internet should be all but impossible
Tijdreiziger 4y ago
I have run into this firewall problem too (not in any sort of production environment, thankfully). The problem is that your mental model of a firewall tends to be that it sits 'in front of' all applications on your machine. Docker breaks this assumption by implicitly inserting rules into iptables. Worse still, if you then inspect the state of the firewall (using UFW), it does not show you any of the rules that Docker inserted, because those rules are on a separate iptables chain. The problem, then, is the interaction between Docker and UFW. UFW is designed as a 'simple' frontend for iptables, for situations where the advanced configurability of iptables is unneccessary. If you manage the firewall using UFW, you are not really supposed to also inject 'raw' iptables rules, especially not on non-standard chains. However, this is exactly what Docker does. Therefore, we end up in the hairy situation where Docker adjusts your firewall, but UFW does not provide any indication that anything has changed. Neither project considers this a bug, and they just point to each other for a solution. Personally, I think it should be on Docker to, at the very least, throw up some warnings when it is about to change firewall rules, as this is clearly unexpected behavior for many users (despite Dockers claims to the contrary).
- cpuguy83 4y ago
  Docker is not implicitly doing anything. The user requested for the port to get published and so docker published it. As nice as it would be for Docker to be more configurable in terms of where rules get inserted, that would not have helped here because the user already misconfigured things (should be using docker networks for db access). Technically docker even has a chain that you can throw rules into that will get hit before docker's rules... so it's there just very manual (instead of, say, having a ufw mode).
  - Tijdreiziger 4y ago
    > The user requested for the port to get published and so docker published it. Yes, which runs counter to how every other application works. If you ask, say, sshd to listen on port 22, your firewall will still sit in front of it, unless you explicitly poke a hole in it.
    - cpuguy83 4y ago
      Listening on a port and opening a port are different things. `-p` is for opening ports. Docker is not listening on behalf of the application. It is routing traffic to the application.
  - ilyt 4y ago
    Docker is implicitly overriding existing rules by putting their own ones in front. The least it should do is to put a warning "hey, there are other rules here,I'm adding my own, please verify. It should also have option (I only found "complete on/complete off" one) to "just" create its DOCKER* chains and leave the jumping to them to the user
    - cpuguy83 4y ago
      > I only found "complete on/complete off" one Docker has a `DOCKER-USER` chain where the user can inject their own rules before docker's rules are run. But even then, the user flat out should not be using `-p` unless they want to expose the service outside of the machine. That is the well documented networking model of docker. Docker also includes a network abstraction that should have been used here to give access to other services that need it and isolate it from the things that don't.
      - ilyt 4y ago
        Which is a terrible solution no firewall manager would support
cm2187 4y ago
I am also puzzled that a firewall rule would be the only thing protecting user data. If any machine behind your NAT gets compromised then it is open buffet to the attackers (in addition to a misconfigured NAT like in this example). It is a bit shocking that it is 2023 and people are still doing that.

wkdneidbwf 4y ago

exactly. ideally, accidentally exposing your db to the internet should be all but impossible

Tijdreiziger 4y ago

I have run into this firewall problem too (not in any sort of production environment, thankfully). The problem is that your mental model of a firewall tends to be that it sits 'in front of' all applications on your machine. Docker breaks this assumption by implicitly inserting rules into iptables. Worse still, if you then inspect the state of the firewall (using UFW), it does not show you any of the rules that Docker inserted, because those rules are on a separate iptables chain. The problem, then, is the interaction between Docker and UFW. UFW is designed as a 'simple' frontend for iptables, for situations where the advanced configurability of iptables is unneccessary. If you manage the firewall using UFW, you are not really supposed to also inject 'raw' iptables rules, especially not on non-standard chains. However, this is exactly what Docker does. Therefore, we end up in the hairy situation where Docker adjusts your firewall, but UFW does not provide any indication that anything has changed. Neither project considers this a bug, and they just point to each other for a solution. Personally, I think it should be on Docker to, at the very least, throw up some warnings when it is about to change firewall rules, as this is clearly unexpected behavior for many users (despite Dockers claims to the contrary).

cpuguy83 4y ago
Docker is not implicitly doing anything. The user requested for the port to get published and so docker published it. As nice as it would be for Docker to be more configurable in terms of where rules get inserted, that would not have helped here because the user already misconfigured things (should be using docker networks for db access). Technically docker even has a chain that you can throw rules into that will get hit before docker's rules... so it's there just very manual (instead of, say, having a ufw mode).
- Tijdreiziger 4y ago
  > The user requested for the port to get published and so docker published it. Yes, which runs counter to how every other application works. If you ask, say, sshd to listen on port 22, your firewall will still sit in front of it, unless you explicitly poke a hole in it.
  - cpuguy83 4y ago
    Listening on a port and opening a port are different things. `-p` is for opening ports. Docker is not listening on behalf of the application. It is routing traffic to the application.
- ilyt 4y ago
  Docker is implicitly overriding existing rules by putting their own ones in front. The least it should do is to put a warning "hey, there are other rules here,I'm adding my own, please verify. It should also have option (I only found "complete on/complete off" one) to "just" create its DOCKER* chains and leave the jumping to them to the user
  - cpuguy83 4y ago
    > I only found "complete on/complete off" one Docker has a `DOCKER-USER` chain where the user can inject their own rules before docker's rules are run. But even then, the user flat out should not be using `-p` unless they want to expose the service outside of the machine. That is the well documented networking model of docker. Docker also includes a network abstraction that should have been used here to give access to other services that need it and isolate it from the things that don't.
    - ilyt 4y ago
      Which is a terrible solution no firewall manager would support

cm2187 4y ago

I am also puzzled that a firewall rule would be the only thing protecting user data. If any machine behind your NAT gets compromised then it is open buffet to the attackers (in addition to a misconfigured NAT like in this example). It is a bit shocking that it is 2023 and people are still doing that.