zlacker

>>todsac+(OP)
Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737

I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set to `127.0.0.1`. All other solutions that are better seem to be much more involved.

>>smarx0+P4
This is only an issue if you run Docker on your firewall, which you absolutely should not.

>>globul+V5
Ideally, yes. But in reality, this means that if you just want to have 1 little EC2 VM on AWS running Docker, you now need to create a VM, a VPC, an NLB/ALB in front of the VPC ($20/mo+, right?) and assign a public IP address to that LB instead. For a VM like t4g.nano, it could mean going from a $3/mo bill to $23/mo ($35 in case of a NAT gateway instead of an LB?) bill, not to mention the hassle of all that setup. Hetzner, on the other hand, has a free firewall included.

>>smarx0+K6
There's no good reason a VM or container on Hetzner cannot use a firewall like IPTables. If that makes the service too expensive you increase cost or otherwise lower resources. A firewall is a very simple, essential part of network security. Every simple IoT device running Linux can run IPTables, too.

>>Fnoord+B7
Docker by default modifies iptables rules to allow traffic when you use the options to launch a container with port options.

If you have your own firewall rules, docker just writes its own around them.

>>akerl_+x8
I always have to define 'external: true' at the network. Which I don't do with databases. I link it to an internal network, shared with application. You can do the same with your web application, thereby only needing auth on reverse proxy. Then you use whitelisting on that port, or you use a VPN. But I also always use a firewall where OCI daemon does not have root access on.

>>Fnoord+D9
I thought "external" referred to whether the network was managed by compose or not

>>01HNNW+xj
Yeah, true, but I have set it up in such a way that such network is an exposed bridge whereas the other networks created by docker-compose are not. It isn't even possible to reach these from outside. They're not routed, each of these backends uses standard Postgres port so with 1:1 NAT it'd give errors. Even on 127.0.0.1 it does not work:

$ nc 127.0.0.1 5432 && echo success || echo no success no success

Example snippet from docker-compose:

DB/cache (e.g. Postgres & Redis, in this example Postgres):

    [..]
    ports:
      - "5432:5432"
    networks:
      - backend
    [..]

App:

    [..]
    networks:
      - backend
      - frontend
    [..]

networks: frontend: external: true backend: internal: true

>>Fnoord+5x
Nobody is disputing that it is possible to set up a secure container network. But this post is about the fact that the default docker behavior is an insecure footgun for users who don’t realize what it’s doing.