rlogin service classification is more selective than port 513
The BSD rlogin protocol provides a remote terminal session over TCP. It predates modern SSH practice and is usually described as obsolete, but old operating systems, appliances, and lab images can still leave a listener in place. In a count-only ZoomEye probe on 2026-11-13 around 22:45 UTC, service="rlogin" returned 130 matches while port="513" returned 883,270. Both queries used sub_type="all", page 1, and page size 1.
The gap is large enough to make the interpretation the main story. Port 513 is a numbered service, not proof of rlogin. The service query is a stronger protocol clue, but its small count suggests that many assets are not classified as rlogin or are not reachable in a way the probe can recognize.
For a security team, the service result is a priority list and the port result is a reachability map. Neither should be turned into a claim that 883,270 hosts allow login.
The protocol's security model is historical
RFC 1282 describes BSD rlogin and its use of TCP. The protocol was built for a network where hosts trusted one another and terminal semantics mattered more than a modern authentication handshake. It can carry a remote login name and may rely on host trust or legacy configuration. Those properties are not a good fit for an internet-facing service.
An rlogin listener may also be a compatibility service for an embedded device or an old application. The service name can identify the protocol, but the operational risk still depends on the host's account policy, network exposure, and whether the listener is the actual login path.
Port 513 is sometimes used for other traffic or by application-specific agents. That is why a port-only finding needs validation before it is escalated. The reviewer should confirm the listener, the banner, and the owning process. The organization should not assume that an open port means an interactive shell.
Prefer removal over hardening
If rlogin is not required, remove the package or disable the service. If a legacy application requires it, restrict access to the smallest source network and place the host behind a management gateway. Use strong host and user authentication, avoid trust relationships based only on source address, and log login attempts separately from generic network connections.
Review the surrounding host as part of the same change. An obsolete remote-login service often shares a host with old libraries, dormant accounts, and unmanaged startup scripts. Disabling rlogin without reviewing those dependencies may restore the listener later or leave an equivalent path open.
Test from an unauthorized network and verify that the service is unreachable before authentication. Then test the approved client path and confirm the expected account policy. If the host cannot be patched or isolated, treat it as a constrained legacy asset with an expiry date and compensating network controls.
Keep the finding precise
Record the service count, the port count, the query timestamp, and the scope. For each owned port match, record whether the listener was classified as rlogin or only observed on the port. That distinction prevents a reader from treating a broad port observation as a confirmed remote-login population.
The small service result is also a warning about relying on one index alone. Run the same check with the organization's internal inventory and, where authorized, a protocol-aware scanner on a controlled internal segment. The external index cannot see filtered services or assets that do not answer the probe.
The correct conclusion is narrow: a legacy remote-login protocol remains observable, and port 513 is a much broader signal than the service classifier. Owners should confirm the protocol, remove what is unnecessary, and keep the remaining path on a controlled network.
Top comments (0)