What are the disadvantages of a Docker container using the host network?

3.5k views Asked by At

I understand that by default a docker container will be created in its own network stack.

I would like to use the --net host flag when running docker containers to allow the use of all host ports.

The disadvantages I am aware of:

  1. Services running inside the container could potentially conflict with other services in other containers which run on the same port.
  2. Containers can access the full network stack.

My question is, what is the security impact when allowing a container to use the full network stack?

1

There are 1 answers

0
ListsOfArrays On

Threat Model

It's a bit overkill but usually it's a good idea to model out the threats that occur rather than saying "Don't do that it's insecure."

Use Case

I have created a web control panel which manages game servers in Docker containers. Basically each container runs a FTP server and game server. I run about 50 containers per host. Client's install mods which requires ports to be open.

This sounds like you host multiple instances of the same game, eg Minecraft.

However, mods may introduce new software like MySQL or MongoDB, meaning new attack surfaces open up.

I will assume process control groups (cgroups) are enabled to prevent one container from using full CPU or GPU on the host.

Malicious actors

  1. Host provider.
    • Irrelevant, has total access to the containers. If the host is malicious we're screwed.
  2. Game server.
    • Currently only has access to say three ports: FTP, game port, one mod port.
    • Cheater wants access to SQL on other game hosted to cheat in other game. Makes game to host.
    • Probably not a realistic threat vector as you're probably hosting the same game, so at this point all users are screwed by the developer.
  3. Mod
    • Updated to include crypto miner, wants more of the host resources.
    • Hacker hears about zero day in MongoDB in game XYZ, adds port scan for Mongo databases
    • Most realistic scenario, mods are sometimes turned into pump and dump schemes.
    • Scenario 1
  4. Fake mod.
    • Similar to #2, somebody knows that game xyz is hosted and has --net host enabled. The cheater knows that they can just access the database to change the number of coins stored in the local MySQL database or to set themselves as a moderator on the other instance.
    • They pay for an instance of the game, and install the mod to effectively backdoor the other container instance.
    • Scenario 2

Using --net host

Scenario 1: Crypto miner

Before, with just certain ports exposed, the other instances of the game using a mod with Mongo were safe. You probably have the Mongo port disabled in the public firewall.

However, now all containers can chat with each other, using --net host, and have no firewall enabled to prevent each other from maliciously sending traffic to each other.

So when the mod is updated to include not just a crypto miner but also a port scanner, the mod scans localhost and finds the open MongoDB. It then takes over the other containers and uses much more CPU/GPU of the host assuming the containers had cgroups applied to them.

If there were no cgroups (process utilization control groups) applied, then the only threat is the additional access.

Scenario 2: Cheater mod backdoor

Before, with just certain ports exposed, the other instances of the game using a mod with MySQL were safe. You probably have the SQL port disabled in the public firewall.

However, now all containers can chat with each other, using --net host, and have no firewall enabled to prevent each other from maliciously sending traffic to each other.

So when the cheater installs their mod on their instance, they directly access the MySQL server and increase the stored coin count making them rich. Server moderators are confused as there are no game logs showing this access, and they wonder if their server has been hacked.

Summary

In sum, --net host doesn't add additional exterior access assuming you have an active firewall, but it does reduce separation between containers that are running on the host, meaning if you're hosting malicious containers you're creating increased potential for non malicious containers to be taken advantage of.

See also