Why is a default mongodb docker instance insecure?

Question

I'm running a mongoDB as a docker container on my ubuntu server. Yesterday the db got hacked and I do not understand what is configured wrong. Ok, I'm just using the default configuration - which I guess - is not the best way. But I thought the db is only accessable from my internal container, as I'm using docker. So this is obviously wrong.

I would like to understand why this docker-compose file gives me an insecure mongoDB:

version: '3.5'

networks:
  reverse-proxy:
    name: reverse-proxy
    driver: bridge

volumes:
  html:

services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    container_name: nginx-proxy
    networks:
      - reverse-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /opt/nginx-proxy/vhost.d:/etc/nginx/vhost.d:rw
      - /opt/nginx-proxy/htpasswd:/etc/nginx/htpasswd:ro
      - /opt/nginx/certs:/etc/nginx/certs:ro
      - html:/usr/share/nginx/html
      - /var/run/docker.sock:/tmp/docker.sock:ro

  mongodb:
    container_name: mongodb
    image: mongo:4.0
    networks:
      - reverse-proxy
    restart: unless-stopped
    ports:
      - "27017:27017"
    volumes:
      - /opt/mongo/data:/data/db
      - /restore:/restore

The `ports:` declaration makes it accessible to anyone who can reach port 27017 on the host. — David Maze, May 05 '19 at 19:12
@DavidMaze I don't understand that. What should be the config looks like instead? — user3142695, May 05 '19 at 19:13
One option would be revise your `ports` to `127.0.0.1:PORT:PORT` so that, while you expose the ports on the host, they're only accessible through `localhost` (`127.0.0.1`) on the host. More commonly you don't need to expose (particularly) the database beyond the compose services. To achieve this you need to drop the first port parameter **and** (to avoid an ephemeral replacement) replace `ports` with `expose`, e.g. `expose: - "27017"`. See https://docs.docker.com/compose/compose-file/#ports and https://docs.docker.com/compose/compose-file/compose-file-v2/#expose — DazWilkin, May 05 '19 at 20:05
@DazWilkin How do I check if my db is accessable from anyone? — user3142695, May 05 '19 at 20:07
An important question. I would cautiously recommend you to not consider Docker a security mechanism. While your approach (with these recommendations) could help limit access to the Mongo DB, human error or insecurities in the Nginx or MongoDB containers and, of course, in your OS, still leave you exposed. You may try accessing the Mongo DB on your host from an(y)other Internet connected machine. If you're able to program a firewall (perhaps iptables) to restrict access, this will provide you additional guarantees. — DazWilkin, May 05 '19 at 20:14
@user3142695 a question: why not enable auth on the MongoDB instance to require username/password? Is there a technical reason why this is not feasible? — kevinadi, May 06 '19 at 05:01

score 0 · Answer 1 · answered Dec 17 '21 at 03:07

In my case, I was using ufw to manage my firewall. It turned out that docker inserts an iptables rule (presumably so that things just work in a dev environment), bypassing ufw's firewall. It looked like port 27017 was being protected by ufw, but it was actually open in iptables. I gave more details in the following reply:

Easiest way to avoid the recent Mongo-db scam

It's possible that many of the 28,000 affected by this mongo hack are using ufw + docker and were not aware that their mongo port was actually open when they thought it was closed. Same applies to anything else using ufw + docker.

Why is a default mongodb docker instance insecure?

1 Answers1