DEV Community

facilishz
facilishz

Posted on

Two Observability Back Ends Where the Name and the Signature Disagree by Twenty Times

#observability #logging #measurement #zoomeye

Two Observability Back Ends Where the Name and the Signature Disagree by Twenty Times

Log and trace platforms are the systems an organisation installs to see what everything else is doing. Their own exposure is measured inconsistently, and two products show the inconsistency at different scales.

The measurements

Queries executed against the ZoomEye index on 28 October 2026:

  • app="Dozzle" returns 592 and title="Dozzle" returns 11,918. The title count is twenty times the fingerprint count.
  • app="SigNoz" returns 32 and title="SigNoz" returns 2,640. Here the title count is more than eighty times the fingerprint count. Both products are real, both are actively deployed, and both are substantially under-represented by the application fingerprint. The reason differs, and the difference matters.

Why the two gaps look alike but are not

Dozzle is a lightweight, single-purpose container log viewer. It reads the Docker daemon's log stream and renders it in a browser. Deployments are typically a single container behind whatever reverse proxy the host already runs, and the default page carries the product name prominently, which is why titles are plentiful. The absence of a broad fingerprint is unsurprising for a tool this small and this commonly proxied.
SigNoz is the opposite shape: a full observability platform with a collector, a query service, ClickHouse storage and a React front end, deployed with Docker Compose or Helm. A product that runs across multiple containers and is usually fronted by an ingress is genuinely harder to fingerprint from an HTTP response, because the response a scanner sees is often the ingress default rather than the product.
In both cases the conclusion for a defender is the same and slightly uncomfortable: the exposure that matters is not the count of fingerprint matches. It is the count of endpoints that will answer a request with data.

What each one will answer

A Dozzle instance with the default configuration accepts connections and streams container output. That output routinely contains application logs with tokens in URLs, database connection strings printed at startup, and stack traces with internal paths. Access control in older configurations was effectively "whoever reaches the port", and while newer releases added authentication options, the installed base includes a long tail of older deployments behind a reverse proxy that was never configured.
A SigNoz deployment holds traces and metrics from every instrumented service, plus a user database and an alerting configuration with webhook credentials. Its query interface accepts arbitrary time ranges and service filters, which means an open instance is a search engine over production telemetry rather than a single page of debug output.
Neither requires a vulnerability to be useful to an attacker. Both require only reachability.

The measurement discipline this implies

If you are inventorying your own estate, title-only queries will over-count proxies that serve a branded landing page and under-count anything that changed the page. Fingerprint-only queries will miss most of both products. Running both and taking the union, then verifying by hand on a sample, is the only approach that produces a number you can defend in a report.
The same applies to the reasoning. "592 Dozzle instances" is not a claim that only 592 exist. It is a claim that 592 addresses emitted a signature that a scanner could attribute with confidence, and it is a lower bound on a population that is probably an order of magnitude larger.

Controls worth the five minutes

Put the log viewer behind the same authentication as the systems it observes. A Dozzle port that answers without credentials is a data leak with a friendly interface.
Restrict telemetry back ends to the monitoring network, and treat the presence of a public DNS record for them as a finding rather than a design choice. Verify that the query interface requires authentication even for read operations, because read access to traces is read access to everything the traces contain.
Rotate any webhook or API credential stored in the alerting configuration, on the assumption that the platform's own configuration is a secret store that nobody classified as one.

References

Top comments (0)