Running Vulnerable Apps in Docker

docker-compose closed with docker compose up standing a whole stack on its own network in a single command. That same machinery, a published port, a private network, and a one-line teardown, is what turns an ordinary laptop into a safe place to attack software that was broken on purpose.

A practice target is an application shipped with real, exploitable flaws left in on purpose, so people can learn to find and exploit them without breaking into anything they don't own. OWASP Juice Shop is the standard first one: a working web store seeded with dozens of genuine vulnerabilities. It ships as an image, bkimminich/juice-shop, so a single docker run pulls it from the registry and starts it.

Running software that is broken on purpose creates two separate risks, and they point in opposite directions. Anything that can reach the target can attack it, so the target must not be reachable from the wider network. And the target can reach out: a container gets network access by default, so a target that gets popped, or an image that was malicious to begin with, can turn around and hit everything the host can hit. The rest of this lesson is the three levers that bound both.

Publishing a port so the target can be reached

A container runs in its own network namespace, one of the kernel features from lesson one. Inside that namespace it has its own interface and its own address, typically something like 172.17.0.2 on Docker's private docker0 bridge. That address means nothing to a browser running on the host. It sits on an isolated bridge that host processes have no route to. For a service inside the container to answer anything outside it, the port has to be published.

The ports key in a compose file did this in the last lesson. docker run does it with -p, and underneath the flag is a rewrite rule. When the daemon publishes container port 3000 on host port 3000, it writes a destination-NAT rule into the host's iptables: traffic arriving at host port 3000 gets its destination rewritten to 172.17.0.2:3000 and forwarded into the container's namespace. A small helper process, docker-proxy, backs up the same mapping for local connections. The container never learns any of this happened.

The full form of the flag is [hostIP:]hostPort:containerPort, and the host IP at the front is the part that decides who can reach the mapping. It is also the part people leave off.

Leave it off and the daemon binds 0.0.0.0, meaning every interface at once: loopback, the Wi-Fi address, the ethernet address, all of them. On a shared network that publishes the deliberately vulnerable app to the whole room. Write 127.0.0.1 in front and the rule matches only traffic that arrived on loopback, so a browser on the same host reaches http://127.0.0.1:3000 and a machine one seat over on the same LAN gets nothing.

$docker run --rm -d --name juice-shop -p 127.0.0.1:3000:3000 bkimminich/juice-shop

The mapping is worth confirming rather than trusting, because the cost of getting it wrong is a live vulnerable app on the LAN. docker port prints exactly what the daemon bound.

$docker port juice-shop

The 127.0.0.1 on the right is the proof. If that column read 0.0.0.0, the app would be answering on every interface the host owns.

Here is the failure mode nobody mentions until it burns them. On a Linux host running the ufw firewall, a rule like ufw deny 3000 looks like it closes the port. It does not close a published Docker port. The daemon inserts its forwarding rules into iptables chains that ufw does not manage, and those rules are consulted before ufw's, so a 0.0.0.0 publish stays reachable from the LAN with the deny rule sitting right there doing nothing. Binding to 127.0.0.1 sidesteps the whole problem, because the NAT rule never matches traffic that arrived from another machine in the first place. This behavior is long-standing and documented, and it has exposed more lab targets than any exploit has.

Keeping the target from reaching back

Publishing controls who reaches in. It does nothing about the target reaching out, and by default a container reaches out freely. On the default bridge network the daemon masquerades the container's outbound traffic, rewriting its source so replies find their way back, which means the target can talk to the LAN, the router, and the internet exactly as the host can. For ordinary software that is a convenience. For software built to be exploited it is a liability: code that lands execution inside the target can scan the internal network from it, reach the router's admin page, or ship data out. A malicious image does not even need to be attacked first. It can call home the instant it starts.

Three levers cut the outbound path, tightest first.

--network none gives the container no interface at all except loopback. Nothing in, nothing out. This is the right setting for examining something actively hostile, a suspicious binary pulled off a target, where the plan is to docker exec a shell into the container rather than reach it over a network. The cost is that with no interface there is nothing for a published port to bind to, so a web app run this way cannot be browsed.

An internal network sits in the middle and is the workhorse for a lab. docker network create --internal labnet builds a bridge with no gateway to the outside world. Containers attached to it talk to each other by name, and none of them has a route to the LAN or the internet. This is the compose pattern from the last lesson applied for safety: put the target and a container full of tools on the same internal network, and drive the target from the tools container. The target answers the tools and can call nowhere else.

$docker network create --internal labnet

$docker run --rm -d --name juice-shop --network labnet bkimminich/juice-shop

Loopback publishing on the default bridge, the very first command in this lesson, is the loosest of the three and the most common. -p 127.0.0.1:3000:3000 keeps the target off the LAN and lets a local browser open it, but it leaves the target's outbound path wide open. That is a fair trade for a mainstream target like Juice Shop from a known publisher. It is the wrong trade for an image pulled from a stranger, where the sealed internal network earns its keep.

Resetting and tearing down

The reason a container beats a hand-built virtual machine for drilling the same bug ten times is the reset, and the reset comes straight from how images are built. Lesson two established that an image is a stack of read-only layers. When a container starts, the daemon adds one thin writable layer on top, and every file the running app changes lands in that layer and nowhere else. Remove the container and the writable layer goes with it. The next docker run starts from the untouched image again. No uninstall, no snapshot to roll back to.

--rm automates the removal. The daemon deletes the container the moment it stops, along with any anonymous volumes it created for itself. Leaving --rm off keeps the stopped container around; docker ps -a lists it, and a stop-then-remove clears it by hand.

$docker ps

$docker stop juice-shop && docker rm juice-shop

There is one place the reset quietly fails, and it catches people who trust --rm too far. Not every file a container writes lives in the writable layer. If the image declares a volume, or the run mounted a named volume with -v data:/var/lib/mysql, that data sits in a volume, and removing the container does not touch it. Recreate the container and yesterday's database is still there, which reads exactly like the reset did not work. docker volume ls shows the volumes that survived, and docker volume rm clears them. A DVWA target backed by MySQL is the usual place this bites, because its database is the one thing built to persist.

At the end of a session, the images and stray networks pile up. docker system prune removes stopped containers, unused networks, and dangling build leftovers. Adding -a also removes every image not currently tied to a container, which frees real disk space at the price of re-pulling next time. Adding --volumes takes the volumes too. Each flag deletes more, so the command rewards knowing which one is in play.

$docker system prune -a

Loopback binds, internal networks, and a clean teardown keep the target's blast radius on the network small. None of it says anything about whether the container itself holds. The isolation here assumes the wall between container and host stays up, and that assumption is exactly what the next lesson, container-security, takes apart: why a container is not a security boundary, what privileged mode and the mounted Docker socket hand away, and how root inside a container relates to root outside it.