DEV Community

kozhevniko
kozhevniko

Posted on

Telling Docker Daemons Apart from Other Docker-Facing Services

#docker #fingerprinting #querydesign #zoomeye

Telling Docker Daemons Apart from Other Docker-Facing Services

Docker is a name for several things that answer on a network. The CARBONATO advisory concerns exactly one of them, and confusing the rest inflates an exposure figure without improving a remediation plan.
The advisory is specific about its target. It concerns Docker hosts with unauthenticated Docker Remote APIs exposed to the Internet, typically over TCP port 2375, where the exposed API lets an attacker run a privileged container and reach the host. That is the Docker daemon and its remote API. It is not a registry, not a web dashboard and not an orchestration control plane.
Those other services are real and worth counting separately, which is why the distinction needs to be deliberate. A registry serves images over HTTP and speaks to clients rather than to the daemon. A dashboard presents a user interface and usually requires a login. An orchestration API manages clusters through its own authentication layer. Each has its own exposure story and response.
ZoomEye's field structure supports the separation because product, service and header signals can be combined. A small set of queries run against the same event shows how different the resulting populations are:

app="Docker" && port="2375"          ->  1,032
app="Docker" && service="http"       ->  9,477
http.header.server="Docker"          -> 59,902
banner="Docker"                      -> 354,334
Enter fullscreen mode Exit fullscreen mode

Read top to bottom, the queries get progressively less specific about the remote API. The first names the product and the exposed port. The second names the product and a service type, which sweeps in Docker-related web surfaces. The third matches a response header that mentions Docker, a signal others can also emit. The fourth matches banner text, the loosest of the four.
The same comparison is worth running against the broadest possible baseline. Querying the port alone returned 1,437,638 assets on 30 September 2026, roughly three orders of magnitude above the 1,032 that carry a Docker fingerprint on the same port.
Two operational conclusions follow. First, an exposure metric should name the service it measures, because "Docker exposure" without a qualifier can mean any of five different populations. Second, an asset inventory built from the broader queries is a starting point for classification rather than a finding, since it will contain registries, proxies and interfaces alongside daemons.
The narrower query has its own honest limit. ZoomEye identifies a Docker fingerprint and observes the port; it does not confirm that the daemon behind it accepts unauthenticated requests, and it does not read container configuration. What it supplies is a filtered list to start from, which is the part that is otherwise unavailable to an organisation that cannot scan itself from outside.
For the CARBONATO scenario, that filtered list matches the advisory's target. The other queries describe adjacent surfaces. Treating them as interchangeable either overstates the campaign's reach or buries the daemons that need attention in a list of everything mentioning Docker.

References

Top comments (0)