DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

A self-hosted remote control relay is reachable by design, which is exactly why it needs a check

#zoomeye #exposure #rustdesk #remoteaccess

A self-hosted remote control relay is reachable by design, which is exactly why it needs a check

A title query for RustDesk returns 4,664 matches in ZoomEye. Remote access tooling is the clearest case where a public address is intentional, so the count by itself says little. What matters is what each reachable endpoint permits a client that is not yours.

Context and method

The query ran on 2026-10-01 and matched the title field for the literal string. ZoomEye title matching is inclusive rather than exact, so a record returns when the string appears anywhere in the parsed title. One match equals one indexed record, collected whenever the scanner last connected.
That treatment fits enumeration. A remote support product will appear on public addresses by design, and the interesting variation sits in configuration more than in reachability.

Why the category is different

RustDesk is an open source remote desktop application. Its self-hosted deployment splits into an identity server, which tracks clients and brokers connections, and a relay server, which forwards traffic when a direct path between two endpoints is unavailable. Self-hosting is popular because it keeps connection metadata inside the operator's own infrastructure instead of a third-party service.
The two components are meant to accept connections from the internet. Clients reach the identity server to register and to look each other up, and they reach the relay when they cannot reach each other directly. An endpoint that refuses every connection is a broken deployment rather than a hardened one.

What the reachability actually exposes

Three questions separate a working deployment from a dangerous one.
Who can register. The identity server issues identifiers and holds the public key material that clients use to decide whether they are talking to the right server. A server whose key material is shared, or whose registration is open to anyone, becomes usable infrastructure for somebody else's sessions.
What a client can reach through it. Relaying is the function. A relay that forwards connections without regard to who requested them moves traffic that the operator cannot see and cannot attribute.
What the endpoint leaks. The identity and relay roles use distinct ports and distinct protocol expectations. A deployment that exposes the administrative surface of the host alongside them, or that runs an unpatched version, presents a second and unrelated problem.
The practical risk in this category rarely involves a direct attacker breaking in through the relay. It is collateral: infrastructure that others can consume, sessions that transit an operator's bandwidth and attribution that points at the operator's address.

Reading the count sensibly

A title match cannot tell you whether an instance is a personal server used by one administrator, a managed deployment serving a company, or a test installation left running after a trial. It also cannot tell you whether the identity server requires client authorisation or accepts any client that knows the address exists.
The defensible claim is smaller. Thousands of self-hosted remote support endpoints are indexed, which means the category is large enough that an operator cannot assume their own deployment is unremarkable.

Running the check honestly

Confirm which instances your organisation runs and whether each one is the identity role, the relay role or both. Confirm how the key material was generated and who holds it. Confirm whether clients must be pre-authorised before they can register. Confirm which ports are exposed and whether the host's administrative interface is among them. Confirm the version and the patch state of both components.
Where a relay is open to arbitrary clients, restrict it to known client identifiers and log session establishment, so that the operator can answer later who used it. Where the deployment exists for a single administrator, consider whether it needs to be internet-facing at all.

Implications for defenders

Reachability is not the finding in this category. Uncontrolled reachability is the finding, and authorisation plus the ability to attribute sessions after the fact is the answer. Track these endpoints in the same inventory as every other remote access path and keep the entry current, because a forgotten relay keeps accepting clients long after the project that needed it ended.

References

Top comments (0)