Container Network Exposure

What Is Container Network Exposure?

Publishing a container port binds it to every interface on the host by default, so a mapping added for local convenience can put a database on the public internet without any change to the cloud firewall. You'll take the attacker's side first: scan the host, connect straight to the database with an old stolen password, and read customer records with no application in the path. Then you'll bind the mapping to 127.0.0.1, verify from outside, and rotate the exposed credential.

What You'll Learn in Container Network Exposure

• Recognize that publishing a container port with -p binds it to every interface on the host, including public ones
• Trace an exposed database back to its Compose port mapping by reading the PORTS column of the running container
• Explain why a cloud firewall or security-group review never reflects a port the container runtime published on the host
• Apply a 127.0.0.1 binding to the port mapping and verify from outside that the database is no longer reachable
• Rotate any credential that was reachable while the port was open, because closing it does not invalidate what was stolen

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.