Container Network Exposure

What Is Container Network Exposure?

Publishing a container port binds it to every interface by default, so a mapping meant for local development can put a database on the public internet without any firewall rule appearing to change. On the default bridge network, every container can also reach every other one. This exercise covers a database exposed by a port mapping: watch an attacker connect directly with no application involved, then fix it by binding to localhost and putting the services on a user-defined network.

What You'll Learn in Container Network Exposure

• Every interface on the host, including public ones, which is why a development convenience can expose a database to the internet.
• The mapping is created by the container runtime on the host, so nothing in the cloud security-group configuration changes to reflect it.
• Every container on it can reach every other one, so a compromise of any single container gives network access to all of them.
• Rotate the credentials that were reachable, because closing the port does not invalidate anything an attacker already collected.

Container Network Exposure — Training Steps

1. A database on the open internet

   Bob is not inside anything. Weeks ago he bought a dump that included a read-only database credential for Halvexis, but a credential is useless if you cannot reach the database. So he scans the company's data-store hosts to see if any of them answer from outside.

2. Straight in, no application

   There is no login page, no API, no rate limit. A published database port speaks the raw Postgres protocol to anyone who can reach it. Bob points a database client straight at it and authenticates with the credential he already had.

3. Read the residents table

   The credential is read-only, which is all Bob needs. He queries the table that holds the platform's renters and their details, straight out of production.

4. What changed

   Bob has had this exact credential for months and never used it.

5. Monitoring flags the traffic

   Halvexis runs cloud monitoring on its production hosts. It does not know what the database is for; it reports what it saw.

6. Find the open port

   If the security groups did not change, the exposure was created on the host itself, by how a container published its port. Alice lists the database container and reads the one column that says which interfaces the port is bound to.

7. Where the port is published

   The port mapping comes from the Compose file that defines the stack. Alice opens it to see the line that published 5432.

8. The line that did it

   One mapping, written the way a developer writes it on their laptop, is what put the database on the internet when this stack shipped to production.

9. Bind it to localhost

   The API reaches the database over the Compose network by its service name, not through a published host port. So the host mapping does not need to be public at all. Alice pins it to the loopback interface, so only the host itself, and the containers on its network, can reach it.

10. Read the fixed binding

    The change is one interface prefix, but it is the whole fix. Alice steps through the bound mapping before redeploying, to see exactly what is now reachable and from where.