Passive scanner (WIP)

Watches a network feed — a SPAN port, a mirror or a tap — and infers hosts from the traffic that crosses it. It transmits nothing, which makes it the one discovery source you can point at a segment where an active scan would be unacceptable.

Type name	passive_scanner
Creates	Endpoints
Runs on	A sensor attached to a mirrored feed
Presence flag	passive_scanner_exits
Field prefix	passive_scanner_

Not yet wired end to end

The type is defined, its fields are declared, and the sensor ships the capture engine — but the console's identification stage for this type is still empty, so a run does not yet produce asset change entries. Treat this page as a description of the intended integration and of what is in place today, not of a working inventory path.

Why passive discovery earns its place

An active scan is authoritative but intrusive, and there are always segments where it is not allowed: OT and process networks, medical devices, anything with a vendor support contract that forbids unsolicited traffic. Those segments are exactly where unmanaged assets accumulate.

A passive sensor sees them anyway, because a device that communicates is visible whether or not it is willing to be probed:

	Passive scanner	Active scanner
Traffic generated	None	Probes every address in scope
Finds	Anything that talks on the monitored feed	Anything reachable from the sensor
Misses	Anything silent, or on a segment with no feed	Anything firewalled off, or that ignores probes
Evidence	Inferred from observed traffic	Established by direct response
Freshness	Continuous	Per scan window
Safe on fragile networks	Yes	Not without agreement

They are complements, not alternatives. Passive tells you something is there; active tells you what it is.

How it works today

The sensor runs Zeek against its capture interface, driven by the sensor's own configuration rather than by a scheduled task, and the logs Zeek produces are what a run will eventually turn into assets:

The capture process is tied to whether an enabled passive scanner instance exists for the sensor: the sensor starts Zeek when one is enabled and stops it when none is. So enabling the integration is what turns capture on, and disabling it is what turns capture off.

The protocols that carry identity are the ones that matter here — DHCP requests and offers name a host and its vendor class, ARP and Ethernet headers give addresses, and ordinary IP conversation reveals which addresses are live.

TODO

Document the exact Zeek log set collected, the upload cadence, and the mapping from each log field to an asset field, once the identification stage is implemented.

Requirements

The feed

Need	Why
A SPAN, mirror or tap delivering the traffic you care about	The sensor can only infer from what its interface receives
A capture interface on the sensor host, in promiscuous mode	Mirrored frames are addressed to other hosts
Host networking on the sensor container	The capture engine reads the host's interface directly
Sustained throughput headroom	Capture cost scales with the feed, not with the estate

Placement decides coverage, completely

A passive sensor sees exactly what its feed carries and nothing else. Mirroring an internet edge tells you about north–south traffic and nothing about two hosts talking inside a VLAN. Decide which segments you need visibility into, then arrange a feed per segment — one sensor at the edge is not a substitute.

In this deployment

Need	Why
A registered, healthy sensor on the mirrored segment	See Sensors
An enabled passive scanner instance bound to that sensor	Capture only runs while one exists

Configuration

Field	Required	Notes
Name	Yes	Label for this instance
Sensor	Yes	The sensor attached to the feed

The scan template form is inherited, and most of it does not apply

The template today presents the same fields as the active scanner — subnets, discovery ports, ICMP, OS detection, HTTP probe, scan rates. None of them describes anything a passive listener does. Fill in the name and description; treat the rest as placeholders until the form is trimmed to what this type actually consumes.

TODO

Replace the inherited template with passive-specific settings — the capture interface, the address space to consider internal, and the retention of observed records — and document them here.

Exported fields

Four fields are declared. They are deliberately minimal: passive observation establishes presence and addressing, not platform detail.

Field	Type	Holds
passive_scanner_exits	Boolean	Presence flag marking this asset as seen by passive capture
passive_scanner_address	IP	Address the host was observed using
passive_scanner_hostnames	Text	Name observed on the wire — DHCP client hostname and similar
passive_scanner_last_online	Date/time	When the host was last observed

TODO

Extend the field set once identification is implemented — vendor class, MAC and observed services are all present in the capture and are the obvious next additions.

See also

• Active scanner — the authoritative counterpart
• Sensors — placement, enrolment and health
• Integrations overview — the shared configuration model