Hosts and services

A host is a discovered machine. A service is what is running on one of its ports — which is not the same thing as the port being open, and the difference is most of what this page is about.

The host list

Searchable by hostname and FQDN, and by IP address. It shows addresses, device type, operating system and service count.

Every list in Loomscope is sorted, filtered and paged on the server with keyset cursors, so an organisation with a hundred thousand hosts pages through them at the same speed as one with a hundred. The site picker in the header scopes the list; the search box narrows it further.

Press <kbd>⌘K</kbd> (or <kbd>Ctrl</kbd>+<kbd>K</kbd>, or /) anywhere to open the command palette, which searches hosts, services, networks and sites by name or by IP address.

Identity: why a host survives DHCP

A host is identified by a stable fingerprint, not by its IP address. A machine that gets a new lease is the same host with a new address, not a new host — which is the difference between an inventory and a list of things that have ever answered.

The fingerprint is derived from what does not change: MAC addresses, SNMP system identity, certificate subjects and similar. A host with none of those falls back to weaker evidence, and may split or merge when better evidence arrives.

A host page

Everything known about one machine:

Section	What is there
Addresses	Every v4 and v6 address seen, with when it was last observed
Interfaces	Names, MAC addresses, MTU, speed, and LLDP/CDP neighbours where known
Ports	Open, filtered or closed, with banners where one was returned
Services	Signature matches with version, vendor, CPE and confidence
Certificates	Every TLS certificate seen on this host, with expiry and trust status
Vulnerabilities	Findings matched against its services
Changes	This host's history without needing to pick snapshots
Relationships	Its parent (hypervisor, container engine) and its children

How services are identified

A port being open tells you almost nothing. Loomscope matches a signature — a pattern combining port, protocol, an HTTP endpoint and an expected response fragment — and records what it matched on.

Grafana is identified by /api/health returning something containing grafana. Not by port 3000 being open, which is also Ruby on Rails, a dozen Node applications and whatever a developer started that afternoon.

Signatures come from two places and produce the same internal type:

Core signatures, compiled into the daemon binary. Kept small on purpose — performance and safety.
Custom signatures, YAML dropped into /etc/loomscope/signatures.d/ and reloaded on SIGHUP, for the in-house applications no vendor will ever fingerprint. See Service signatures.

The daemon reports how many of each it loaded in its heartbeat, so the UI can confirm a new file took effect.

Confidence, and why it is shown

Every match carries a confidence score between 0 and 100.

Evidence	Confidence
Endpoint response matched	High
Banner matched	Medium
Port number alone	Low
Set by hand	Whatever you set

Confidence propagates. A version taken from a banner produces a lower-confidence vulnerability finding than one taken from a structured CPE, and the finding says so. A number you cannot weigh is a number you cannot act on, so it is shown rather than rounded away.

Versions and CPE

Where a signature can extract one, a service carries a version, a product, a vendor and a CPE — the structured product identifier that vulnerability databases key on.

A CPE match is the difference between reliable vulnerability matching and a heuristic. Services with a CPE match by product and version; services without one fall back to name-and-version matching, which is where false positives concentrate. See Vulnerabilities.

Services as first-class objects

A service has its own page, reachable from any host that runs it. It shows where it runs, what version, what it is exposed on, its certificates and its findings — which is the right shape for the question "where is Redis 6 running", as opposed to "what is on this host".

Workloads: parents and children

A host can have a parent:

A virtual machine under its hypervisor
A container under its Docker engine, when LOOMSCOPE_DOCKER_DISCOVERY is enabled on that daemon
A pod under its node, from Kubernetes discovery

That hierarchy is what the workload topology view draws, and it is why a container-dense host does not read as two hundred unrelated machines.

Docker discovery is opt-in because mounting the Docker socket grants effective root on the host. It is worth it on a container host and worth refusing everywhere else.

Manual edits

Some things discovery cannot know: what a machine is for, who owns it, whether an unidentified service is the thing you think it is. Hosts accept notes and tags, and a service can be set by hand with its own confidence.

Manual data is never overwritten by a scan. A discovered value that contradicts a manual one is recorded as a change rather than applied silently.