DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Three Ways to Reach a Docker Daemon, and What Each One Looks Like Externally

#docker #remoteapi #tls #zoomeye

Three Ways to Reach a Docker Daemon, and What Each One Looks Like Externally

The CARBONATO advisory does not say that Docker's Remote API is inherently unsafe. It says the risk concentrates where that API is reachable from the Internet or another untrusted network without authentication. That distinction matters, because there are several supported ways to drive a Docker daemon remotely and they carry very different exposure profiles.
The first is an unauthenticated TCP listener, conventionally on port 2375. Anyone who can route to the port can issue API calls. The advisory describes this configuration, and it is the one that produces a remotely reachable privileged-container foothold.
The second is a TCP listener protected by TLS with client certificate authentication, conventionally on port 2376. The daemon still speaks the API over the network, but the client must present a certificate the daemon trusts. An unauthenticated caller is refused.
The third is an SSH tunnel. The daemon is not exposed over TCP at all; a client connects over SSH and Docker's CLI drives the remote daemon through that channel. Access control is whatever SSH enforces.
These three configurations produce visibly different external signatures, and the difference is measurable. A query for the Docker application fingerprint returns assets ZoomEye identifies as Docker, regardless of how they are reached. Adding the conventional unauthenticated port narrows the result to the specific exposure the advisory warns about:

app="Docker"                                     -> 13,246
app="Docker" && port="2375"                      ->  1,032
app="Docker" && service="http"                   ->  9,477
Enter fullscreen mode Exit fullscreen mode

The middle line is the one that matches the advisory's scenario. Executed on 30 September 2026 at 17:17 UTC with sub_type=all, it returned 1,032 assets globally.
The other lines are not substitutes for the middle one. The first is a product inventory with no exposure claim attached. The third covers Docker assets presenting an HTTP service, which includes dashboards, registries and proxies alongside daemons, so it is broader than the remote API question.
These are three separate observations, not three estimates of one quantity.
There is a limits section here that is easy to skip. ZoomEye identifies a service by its fingerprint. It does not authenticate against the daemon, so it cannot report whether a daemon on 2375 would accept an unauthenticated call, and it cannot tell an operator which of the 1,032 assets have already been used. Those questions are answered locally, by reading daemon configuration and host state.
What ZoomEye does supply is the inventory step: an externally observed list of Docker assets on the remote API port, gathered without touching the systems themselves. For an organisation that does not know its own Docker footprint, that is the difference between auditing a known set and searching an unknown one.
The hardening advice in the advisory maps onto the same three configurations. Where remote access is not needed, disable network access to the daemon. Where it is needed, use SSH or TLS with client authentication and restrict it to authorised systems and users. Neither recommendation requires replacing Docker; both require choosing a transport deliberately instead of leaving the default listener open.

References

Top comments (0)