DEV Community

facilishz
facilishz

Posted on

The query returned zero, and that is the finding

#security #attacksurfacemanagement

The query returned zero, and that is the finding

Two queries run through the ZoomEye API on 23 October 2026 produced numbers that belong together: app="Apache Doris" returned 0, and port=8030 && title="Doris" returned 3,882.
The first number is not an error message. It is a measurement, and reading it correctly is the difference between a useful inventory and a false assurance.

What the zero means

Apache Doris is a real-time analytical database, deployed by organisations that need sub-second aggregation over large data volumes. Its front-end nodes serve an HTTP interface on 8030 by default, and that interface renders a web console.
A fingerprint returning zero while a port-and-title query returns several thousand means ZoomEye's application fingerprint for this product either does not exist or does not match what the deployments present. The hosts are there. The recogniser did not fire.
For an operator, the consequence is direct. An inventory that relies on application fingerprints to find Doris deployments will report nothing and be wrong. The only query that finds them on this evidence set combines a default port with a title string, which is a far less robust identification method and produces false positives.

Why this happens more often than it should

Fingerprints are expensive to maintain. Each one requires identifying a response pattern that is stable across versions, distinct enough not to match another product, and present in the traffic a scanner collects. Products that change their default page frequently, or that sit behind authentication screens that differ per deployment, are hard to fingerprint and are often absent from the recogniser set.
Doris is a distributed system with multiple front-end nodes and a load balancer in front in most production designs. The page that answers 8030 may be the front end's console, a proxy's error page, or a health endpoint, depending on how the deployment was wired. A recogniser needs to handle all three or it will match none.
The practical implication is that absence from a fingerprint query is not absence from the internet. It is absence from the set of hosts the fingerprint builder identified.

What the 3,882 actually contains

A title match is a weaker signal than an application fingerprint. It matches the HTML title element, and the string "Doris" appears in plenty of pages that are not Apache Doris: personal names, product landing pages, internal tools.
The conjunction with port 8030 improves specificity substantially, because 8030 is the default and few unrelated services bind it. It does not eliminate the problem, and the query should be treated as a lead generator rather than a census.
The right next step for any host in the result set is a request to the console root and an inspection of what came back. A Doris front-end returns a page with version information; a proxy error page does not. Doing that check on a sample changes a count into an assessment.

Why a Doris console is worth the effort

An analytical database console is not a passive display. The front end's web interface exposes query capability, cluster state, and in many deployments an SQL editor. Reaching it unauthenticated grants query access to the data the platform team built the cluster to analyse.
The data in these systems is typically not raw source data. It is aggregated, joined, and prepared: revenue by region, user retention by cohort, fraud signals by merchant. It is the answer layer that business decisions are made from.
The access control question is the familiar one. Doris supports authentication and role-based access control, and it supports TLS. The failure mode is the deployment that inherited default settings to get an internal proof of concept running and reached production without the console being reviewed.

A reconciliation sequence that survives the zero

Start with the queries that return data. A port-and-title query restricted to your own netblocks produces the address list. Query 8030, 9030 and 8040 separately, because the MySQL protocol port and the HTTP redirect port are as revealing as the console.
Then ask the deployment side. Container images, Helm charts and the FE configuration files name the version and the authentication settings. Where those records and the external list disagree, investigate the external host first: an unexpected answer on a default port is more likely to be a forgotten deployment than a scanner artefact.
For version currency, compare the console's reported build against the release notes. Apollo and StarRocks forks share the same port and a similar console, and the distinction matters when deciding which patch applies.

The detection question a console raises

Queries are the event that matters in an analytical database. Doris retains query history, and the audit plugin records user, statement and timestamp when it is enabled. Where that record is shipped off the cluster, the question "who ran this query" has an answer.
The comparison worth making is whether a suspicious result set could be traced to a person. Where audit is disabled and the only record is the web server's access log with an authenticated session identifier, tracing a query to a user depends on a join against a session store that may not exist.

References

Top comments (0)