553
Context: Docker bypasses all UFW firewall rules (lemmy.world)
submitted 1 year ago* by to c/programmer_humor@programming.dev
104 comments fedilink hide all child comments
 

Docker docs:

Docker routes container traffic in the nat table, which means that packets are diverted before it reaches the INPUT and OUTPUT chains that ufw uses. Packets are routed before the firewall rules can be applied, effectively ignoring your firewall configuration.

you are viewing a single comment's thread
view the rest of the comments
[–] 30 points 1 year ago (9 children)

If I had a nickel for every database I've lost because I let docker broadcast its port on 0.0.0.0 I'd have about 35¢

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 9 points 1 year ago (8 children)

    How though? A database in Docker generally doesn't need any exposed ports, which means no ports open in UFW either.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 3 points 1 year ago (7 children)

    I exposed them because I used the container for local development too. I just kept reseeding every time it got hacked before I figured I should actually look into security.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 19 points 1 year ago* (1 child)

    For local access you can use 127.0.0.1:80:80 and it won't put a hole in your firewall.

    Or if your database is access by another docker container, just put them on the same docker network and access via container name, and you don't need any port mapping at all.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    Yeah, I know that now lol, but good idea to spell it out. So what Docker does, which is so confusing when you first discover the behaviour, is it will bind your ports automatically to 0.0.0.0 if all you specify is 27017:27017 as you port (without an IP address prefixing). AKA what the meme is about.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 1 year ago (4 children)

    Where are you working that your local machine is regularly exposed to malicious traffic?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    My use case was run a mongodb container on my local, while I run my FE+BE with fast live-reloading outside of a container. Then package it all up in services for docker compose on the remote.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    Ok… but that doesn’t answer my question. Where are you physically when you’re working on this that people are attacking exposed ports? I’m either at home or in the office, and in either case there’s an external firewall between me and any assholes who want to exploit exposed ports. Are your roommates or coworkers those kinds of assholes? Or are you sitting in a coffee shop or something?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 year ago* (1 child)

    This was on a VPS (remote) where I didn't realise Docker was even capable of punching through UFW. I assumed (incorrectly) that if a port wasn't reversed proxied in my nginx config, then it would remain on localhost only.

    Just run docker run -p 27017:27017 mongo:latest on a VPS and check the default collections after a few hours and you'll likely find they're replaced with a ransom message.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •