Active scanner

Probes the subnets you name, enumerates what answers, and turns the result into assets. It is the only source in the catalogue that discovers a host nothing else knows about — no agent, no directory record, no cloud API — which is precisely what it is for.

Type name	active_scanner
Creates	Endpoints
Runs on	A sensor with routed access to the target subnets
Presence flag	active_scanner_exits
Field prefix	active_scanner_

Active scanning is intrusive by nature

This integration sends traffic to every address in scope. It can trip IDS rules, and on fragile devices — industrial controllers, older printers, embedded appliances — a port scan can cause instability. Agree the target scope and the window with the network owners before enabling it, and start with one small subnet.

What it contributes

• Reachability — which addresses answered, and nmap's view of their state
• Open ports and services — what is actually listening, versus what is documented
• Hostnames — from reverse DNS, traceroute, NetBIOS, SMB, RDP and TLS certificates
• OS identity — from nmap's fingerprinting and from protocol-specific probes
• Hardware identity — vendor and model, where an HTTP probe recognises the device
• SSH host key fingerprints — a stable identifier that survives address changes
• Host detail from an authenticated SSH probe, if you enable it and supply credentials

Alongside its own active_scanner_* fields it writes the shared asset fields, so what it finds correlates against every other source. Nearly all of them are written in do-not-override mode — see Exported fields.

How a run works

Half the work happens on the sensor and half in the console. The split matters when you are debugging: a scan that "found nothing" failed on the sensor, a scan that found hosts but created no assets failed in identification.

Subnets are processed sequentially, and each one reports progress back to the console as it completes — a long run is visible in Scan history while it is still going.

Requirements

Network access

From	To	Protocol	Port
The sensor running the scan	Every address in the configured Subnets	TCP (and ICMP where the network permits)	The ports nmap selects — see What the scan actually sends
The sensor	Open HTTP/HTTPS ports on discovered hosts	HTTPS/HTTP over TCP	The ports listed in Ports for HTTP Probe
The sensor	Open SSH ports on discovered hosts	SSH over TCP	The ports listed in Ports for SSH Probe, if the SSH probe is enabled

This is the one integration whose traffic is inbound to your own estate, so the firewall work is internal: the sensor's segment needs a route to each target segment, and inter-VLAN ACLs have to permit it. A sensor that cannot route to a subnet reports a clean, empty scan rather than an error.

On the sensor host

Need	Why
nmap installed	The sensor shells out to it; the container image ships it
Raw socket privileges	OS fingerprinting and SYN scanning need them — the sensor container runs privileged with host networking for this reason
Local disk for the run	Raw XML plus every probed HTTP page is written to a temporary folder, archived, then uploaded
CPU and time proportional to scope	The sensor scans one subnet at a time, so wall-clock grows with the address count

In this deployment

Need	Why
A registered, healthy sensor placed inside the network	See Sensors
One sensor per routing island	A sensor only scans what it can reach; segments behind a firewall need their own

Configuration

Two layers, as with every integration. The instance holds almost nothing — the scan template holds everything that decides what a run does.

Instance

Field	Required	Notes
Name	Yes	Label for this instance
Sensor	Yes	The sensor that will do the scanning — and therefore what the scan can reach

Scan template — basic

Field	Required	Default	What it does
Template name, description	Yes	—	Labels the template
Subnets to scan	Yes	—	Comma-separated CIDR ranges, e.g. 192.168.10.0/24,10.10.0.0/16. Scanned one at a time, in order
Ports to discover	Yes	21, 22, 23, 25, 53, 67, 68, 80, 135, 139, 161, 443, 445, 3389, 8443, 8834	Ports used for discovery — see the warning below
Use ICMP	Yes	On	Use ICMP for host discovery — see the warning below
Detect OS	Yes	On	Attempt OS identification — see the warning below
Probe HTTP ports	Yes	On	Fetch web pages from open HTTP(S) ports and identify the device from the response
Ports for HTTP Probe	Yes	80,443	Which open ports the HTTP probe visits. 443 is treated as TLS; everything else as plain HTTP
Minimum scan rate	Yes	0	Lower bound on packet rate — see the warning below
Maximum scan rate	Yes	1000	Upper bound on packet rate — see the warning below
Exclude default gateways	Yes	Off	Drops any finding whose address ends in .1
Probe SSH ports and pull host information	Yes	Off	Log in over SSH and run a fixed set of read-only commands — see SSH probe
Ports for SSH Probe	No	22	Which open ports the SSH probe tries
Credentials for SSH Probe	No	—	The credentials to try, stored as a secret

Scan template — advanced and actions

Group	Setting	What it does
Advanced	Internal domains	Comma-separated list of your own domains. Used to discard useless certificate names — see How a name is chosen
Advanced	Ignore if host is offline	Present on the form; carries no meaning for this type, since every record in a scan result is by definition current
Advanced	Scan timeout	Upper bound on a single run
Actions	On new asset discovered / Existing asset updated / Asset missing / On scan complete / On scan failed	The shared action model — see Integrations overview

Several scan settings are not yet passed to the scanner

Ports to discover, Use ICMP, Detect OS, Minimum scan rate and Maximum scan rate are stored on the template but the sensor's current nmap invocation does not apply them. Every run uses the same fixed command described below, which means the port list you enter does not narrow the scan and the rate limits do not slow it down. Scope a run with Subnets, and control its impact with the schedule window, until these are wired through.

TODO

Wire discoveryPorts, useICMP, detectOS, minRate and maxRate through to the sensor's nmap arguments, then replace the warning above with the real mapping from each field to its flag.

What the scan actually sends

Per subnet, the sensor runs one nmap process:

nmap --stats-every 10 -Pn -A <subnet> -oX <result>.xml

What that means in practice:

Flag	Effect
-Pn	Skip host discovery — treat every address in the range as online and scan it regardless of whether it answers a ping
-A	Enable OS detection, service and version detection, the default NSE script set, and traceroute
-oX	Write structured XML, which is what the console parses
--stats-every 10	Emit progress every ten seconds

With no explicit -p, nmap scans its own default selection of the most common 1000 TCP ports per address.

-Pn makes scope expensive, and noisy in the inventory

Because host discovery is skipped, a /16 is a thousand-port scan against 65,536 addresses rather than against the handful that answer — and every address is reported as "up", so records can arrive for addresses where nothing exists. Scan the ranges you actually use, sized in /24s, rather than the whole supernet. Watch the first run of a new subnet with On new asset discovered set to To approve before letting it create anything.

TODO

Confirm how records for non-responding addresses behave end to end on a live deployment, and document the recommended filter for suppressing them.

HTTP probe

Where a discovered host has one of the Ports for HTTP Probe open, the sensor fetches / and, if the response looks like a device it recognises, follows up with that device's specific pages — a printer's network configuration page, an appliance's about page. The pages are uploaded with the scan result, and the console matches them against a library of device fingerprints.

A match can supply the hostname, MAC, OS, device type, hardware vendor and model — identity a port scan alone cannot produce. The recognised families are:

Category	Recognised
Printers and MFPs	HP LaserJet, Ricoh, Zebra, HID
Network	Cisco routers, Cisco switches, Cisco IP phones, Juniper NetScreen (ScreenOS), FortiGate, Alcatel-Lucent OmniSwitch, Ruijie Easy Smart, Ubiquiti, Proxim wireless
Serial and device servers	Lantronix XPort, Moxa NPort
Power and environment	Schneider Electric APC, Knürr PDU, Knürr RMS Compact, Emerson NXS UPS, NTI Enviromux
Cameras	Hikvision, Hanwha Vision
Storage and other	ExaGrid, CMI Genus

The first match wins

Fingerprints are evaluated in a fixed order and evaluation stops at the first module that claims the response. A device that two modules would match is identified by whichever comes first, so a wrong hw_vendor on an otherwise correct asset is usually an over-eager fingerprint rather than a bad scan.

Certificate validation is off for probes

Probe requests are made without verifying TLS certificates, because the devices this is aimed at almost universally present a self-signed one. The probe reads pages only; it never submits credentials to a web interface.

SSH probe

Optional, off by default, and the only part of the scanner that authenticates. When enabled, the sensor connects to each open SSH port and tries the configured credentials in order until one works, then runs a fixed set of read-only commands:

hostnamectl · ip addr show · ip link · ip route · uptime · lscpu · free · df -h · lsblk

The console parses two of them today — hostnamectl for hostname, operating system, hardware vendor and model, and ip addr show for addresses and MAC addresses. The rest are collected and stored with the raw result.

Credentials are tried against every host that answers

The credential list is attempted host by host across the whole scanned range. Against a domain-joined estate with lockout policies, a scan can lock the account out; against monitored hosts it produces a wave of failed-logon events that looks exactly like credential spraying. Use a dedicated, unprivileged, non-lockout account, tell your SOC before the first run, and keep the SSH probe scoped to subnets where you know it is welcome.

Host keys are accepted automatically

The probe accepts unknown SSH host keys rather than refusing to connect, so a host that has been re-keyed or spoofed is still logged into. The fingerprint is recorded in active_scanner_ssh_fingerprint, which is what you compare against when that matters.

How a name is chosen

Hostname is the field correlation leans on hardest, so it is worth knowing where it comes from. The run takes the first of:

1. The name nmap resolved for the address
2. The last traceroute hop's name, ignoring _gateway
3. An NSE script result — rdp-ntlm-info, ms-sql-ntlm-info, smb-os-discovery, nbstat, or ssl-cert on ports 443 and 3389
4. A hostname asserted by an HTTP device fingerprint
5. hostnamectl output from the SSH probe

Whatever wins is then trimmed to its first label, so dc-01.corp.example.com becomes dc-01 — unless the value is an IPv4 address, which is kept whole.

Internal domains feeds step 3: certificate names that match one of your own domains, or a wildcard for one, are discarded rather than used as a hostname. Without it, every host behind a wildcard certificate ends up sharing one name — and correlation then happily merges them.

Set internal domains before the first run

It costs one field and it prevents the single most common way an active scan corrupts an inventory. List every domain your internal certificates use.

How the OS is chosen

Protocol evidence is preferred over fingerprinting, in this order:

1. fingerprint-strings on port 32775 — IBM FileNet Content Platform Engine
2. smb-os-discovery
3. rdp-ntlm-info and smtp-ntlm-info — an NTLM product version, mapped to a release name
4. vmware-version
5. nmap's own osmatch / osclass guess
6. An HTTP device fingerprint
7. hostnamectl from the SSH probe

The NTLM mapping is exact where the build is known:

Reported build	Becomes
10.0.10240	Windows 10
10.0.14393	Windows Server 2016
10.0.17763	Windows Server 2019
10.0.20348	Windows Server 2022
10.0.22621	Windows 11
10.0.26100	Windows 11 if port 5357 or 2701 is open, otherwise Windows Server 2025
5.1 / 5.2 / 6.0 / 6.1 / 6.2 / 6.3	Windows XP / Server 2003 / Server 2008 / Server 2008 R2 / Server 2012 / Server 2012 R2

Client-or-server is inferred from open ports

Windows client and server builds share a version number in recent releases, so the run decides between them by looking for ports 5357 (WSD) and 2701, which are typical of a workstation. A server with those ports open is labelled as a workstation, and vice versa. Where the distinction matters for reporting, check type against an EDR-sourced value.

Exported fields

Each <host> element in the nmap output becomes one asset record. Two rules drop records before anything is written:

• Exclude default gateways, if enabled, discards any finding whose address ends in .1
• A record whose fingerprint — instance, hostname, address and SSH host key — already appeared in this run is skipped as a duplicate rather than written twice

Identity

Field	Type	Holds
active_scanner_exits	Boolean	Always true — the presence flag marking this asset as scanner-covered
active_scanner_status	Text	nmap's host state. With -Pn in force this reads up for every address scanned
active_scanner_hostnames	Text	The name chosen by the ladder in How a name is chosen

Network

Field	Type	Holds
active_scanner_address	IP	The host's IPv4 address, as reported by nmap
active_scanner_address_type	Text	Address family — ipv4
active_scanner_ports	Text	The open ports found on this host
active_scanner_ssh_fingerprint	Text	SSH host keys as type=fingerprint lines, one per key. Stable across address changes, which makes it the strongest match key this integration produces

Platform

Field	Type	Holds
active_scanner_os_full_name	Text	OS as chosen in How the OS is chosen, normalised to a canonical name
active_scanner_os_vendor	Text	Normalised vendor — Windows, Linux, MacOS, OpenBSD, VMware
active_scanner_os_family	Text	OS family as the evidence reported it, before normalisation

Timing and raw result

Field	Type	Holds
active_scanner_last_online	Date/time	When the finding was processed — see the note below
_meta_active_scanner_scan_result	Text block	The complete nmap record for this host, kept verbatim so any value on the asset can be traced back to the evidence for it

active_scanner_last_online is the processing time, not the probe time

The field is stamped when the console identifies the record, not when the packet came back. For a long scan those differ by the length of the run, and for a requeued task by longer. Use it to answer "was this host seen by the most recent scan", not to time an event.

Shared fields it writes

Shared field	Derived from	Mode
names	The chosen hostname	Do-not-override
private_ip	The host address, plus any addresses the SSH probe reported	Merge
mac	nmap's MAC, nbstat, an HTTP fingerprint, or the SSH probe	Merge
os	The chosen OS, normalised	Do-not-override
os_vendor	The chosen OS, normalised to a vendor	Do-not-override
os_version	The OS family string	Do-not-override
type	An HTTP fingerprint's device type, else inferred from os	Do-not-override
hw_vendor	An HTTP fingerprint, or hostnamectl	Do-not-override
hw_product	An HTTP fingerprint, or hostnamectl	Do-not-override
opened_ports	The open port list	Overwrite
first_seen / last_seen	active_scanner_last_online	—
updated_at	Time of the run that produced the record	Overwrite

Nearly everything here is do-not-override — deliberately

A network scan is an outside view. It infers where an agent knows, so it fills fields that are empty and steps aside where a stronger source has already spoken. The two exceptions are private_ip and mac, which merge: a host with two NICs accumulates both addresses rather than flapping between them.

os_version receives an OS family, not a version

The field is populated from the family string — Windows, Linux — rather than from a release number. Read os for the release, and treat os_version from this source as a coarse label.

How results match existing assets

Identification tries a ladder of rules and stops at the first that matches. The rule that fired is recorded on the change entry, so the console can always tell you why a record landed on a given asset:

Order	Matches when the candidate agrees on
1	active_scanner_hostnames and active_scanner_address
2	names and active_scanner_address
3	names and private_ip
4	active_scanner_hostnames and private_ip
5	active_scanner_hostnames
6	active_scanner_ssh_fingerprint
7	names
8	mac
9	active_scanner_address, with no conflicting name
10	private_ip, with no conflicting name

Where more than one existing asset matches, the change entry is marked as needing manual input instead of being applied — it lands in the approval queue rather than merging two assets on a guess.

Address-only rules and DHCP do not mix

Rules 9 and 10 match on address alone, guarded only by the absence of a conflicting name. In a DHCP range, yesterday's laptop and today's laptop share an address, so an unnamed record can attach to the wrong asset. The name guard is what prevents most of it — which is another reason to get Internal domains right, and to prefer scanning static ranges where you can.

Operating it

• Start narrow. One /24 you know well, On new asset discovered set to To approve, and read what it proposes before widening.
• Schedule against the window, not the calendar. Because the port list and rate limits are not yet applied, run duration is driven by address count; a scope that grows will eventually outgrow its window.
• Tell the people who watch the network. The first run of an active scan is indistinguishable from reconnaissance, because it is reconnaissance.
• Keep one instance per network island, each bound to the sensor that can reach it, rather than one instance listing every subnet in the company.

See also

• Passive scanner — discovery without sending anything
• Sensors — the component that runs the scan, and where to place it
• Integrations overview — the shared configuration model
• Scanning — templates, schedules and run history
• Assets — inspecting which source asserted an attribute