Technical information on agentless connections for network devices
Cyberwatch scans network devices (routers, switches, firewalls, appliances…) with an agentless connection, through SNMP on UDP port 161. The scan queries the SNMP agent of the device, without installing or modifying anything on it, and reports:
- the system and its version (firmware), from which vulnerabilities are deduced;
- the hostname and the IP addresses;
- metadata: location, serial number, model, high availability role, license expiration dates…;
- the listening ports;
- security issues of the SNMP configuration.
The flows matrix is available in the prerequisites of agentless connections, and the supported devices in the list of supported systems.
SNMP versions and credentials
Cyberwatch supports SNMP v1, v2c and v3:
- in v1 and v2c, the credential is a community;
- in v3, the user must have authentication and encryption (
authPrivsecurity level). ThenoAuthNoPrivandauthNoPrivlevels are not supported.
The available authentication protocols are SHA, SHA-256, SHA-512 and MD5, and the encryption protocols are AES, AES-256 and DES.
We recommend SNMPv3 with SHA-256 or SHA-512 and AES. A scan in v1 or v2c, or with an SNMPv3 user using MD5 or DES, produces a security issue on the asset.
MIB views to allow
Cyberwatch only needs read access. The SNMP view of the user or of the community used must include the following branches:
| MIB | OID root | Data read | If the view excludes it |
|---|---|---|---|
| SNMPv2-MIB, system group | 1.3.6.1.2.1.1 | Description, object identifier (sysObjectID), uptime, name, location and contact | The scan fails. |
| Vendor branch | 1.3.6.1.4.1.<number> | System, version and vendor-specific characteristics | The detection fails, see If the detection fails. |
| HOST-RESOURCES-MIB | 1.3.6.1.2.1.25 | Device uptime; installed software, which gives the version of some devices | The uptime is the one of the SNMP agent. The version of these devices is not detected, and the detection fails for Cisco ISE, Ucopia, and Juniper when the description does not give the version. |
| IP-MIB, OSPF-MIB | 1.3.6.1.2.1.4, 1.3.6.1.2.1.14 | IP addresses | The IP addresses are missing. |
| ENTITY-MIB | 1.3.6.1.2.1.47 | Manufacturer, model, serial number and hardware revision of the chassis | The model and the serial number are read in the vendor branch, when it gives them. The detection of Arista, which reads its version there, fails. |
| TCP-MIB, UDP-MIB | 1.3.6.1.2.1.6, 1.3.6.1.2.1.7 | Listening ports | The ports are missing. |
| SNMP-USER-BASED-SM-MIB, SNMP-VIEW-BASED-ACM-MIB, SNMP-COMMUNITY-MIB | 1.3.6.1.6.3.15, 1.3.6.1.6.3.16, 1.3.6.1.6.3.18 | SNMPv3 users, v1/v2c access and communities configured on the device | Only the security issues of the credential used are reported. |
<number> is the IANA enterprise number of the vendor, with which the object identifier of the device starts: 1.3.6.1.4.1.9.1.… for a Cisco device, for example. For a device built on the net-snmp agent, Cyberwatch also reads the net-snmp branches (1.3.6.1.4.1.8072 and 1.3.6.1.4.1.2021), and the one of its vendor. A view that includes 1.3.6.1.2.1 and 1.3.6.1.4.1 therefore covers all the required branches.
The three tables of 1.3.6.1.6.3 describe the SNMP configuration of the device. Opening them to Cyberwatch is optional. Cyberwatch only reports security issues from them: it never reports a community outside the list of weak communities, nor the name of a user without authentication.
Apart from the system group and the vendor branch, a table that is missing, excluded from the view or that does not respond does not make the scan fail: the corresponding information is simply missing.
Metadata
The scan reports metadata, displayed in the “Metadata” tab of the asset. They are updated at each successful scan: a metadata that the scan no longer reads disappears. Empty values and the default values of SNMP agents (Unknown, root@localhost…) are ignored, and a value is truncated to 255 characters.
Common metadata
These metadata are read in the standard MIB modules, whatever the vendor:
| Key | Source | Description |
|---|---|---|
snmp-location | sysLocation (SNMPv2-MIB) | Location declared in the SNMP configuration |
snmp-contact | sysContact (SNMPv2-MIB) | Contact declared in the SNMP configuration |
system-manufacturer | entPhysicalMfgName (ENTITY-MIB) | Manufacturer of the chassis |
system-product-name | entPhysicalModelName (ENTITY-MIB), otherwise vendor branch | Model of the chassis |
system-serial-number | entPhysicalSerialNum (ENTITY-MIB), otherwise vendor branch | Serial number of the chassis |
system-version | entPhysicalHardwareRev (ENTITY-MIB) | Hardware revision of the chassis, and not firmware version |
snmp-agent-version | versionTag (UCD-SNMP-MIB) | Version of the net-snmp agent |
The ENTITY-MIB columns are read on the first entity of the chassis class. When ENTITY-MIB gives neither model nor serial number, they are read in the vendor branch, for most of the supported vendors.
The system-* keys are those reported by the scan of Linux assets. The same filter, for example meta:system-serial-number:FCW2140, therefore finds a server as well as a network device.
Device-specific metadata
| Key | Devices | Value |
|---|---|---|
ha-state | Check Point, Cisco ASA, F5 BIG-IP, FortiGate, Juniper | High availability state, standalone outside a cluster for Cisco ASA, Check Point, F5 BIG-IP and FortiGate. In a cluster, Cisco ASA, Check Point and F5 BIG-IP give the role of the device (active, standby, offline for F5, active-attention for Check Point…). FortiGate gives the mode of the cluster (active-active, active-passive), the same on each member. Juniper: virtual-chassis for a Virtual Chassis, no value for a standalone device. |
virtual-chassis-member | Juniper | One member of the Virtual Chassis per value: identifier, role, serial number, model and version, for example 9 master LX0213388389 ex4550-32f 15.1R7-S10 |
config-unsaved | Cisco (IOS, IOS XE, IOS XR, NX-OS, ASA…) | true if the running configuration was modified since it was last saved, otherwise false |
boot-image | Extreme Networks EXOS | Booted image: primary or secondary |
firmware-pending-version | Extreme Networks EXOS | Version of the image selected for the next boot, when it differs from the running version |
routerboot-pending-version | MikroTik | RouterBOOT version provided by RouterOS, when it differs from the installed one: the RouterBOOT upgrade remains to be done |
firmware-update-available | Synology | true if DSM reports an available update, false if it reports none. No value when DSM could not check. |
av-signature-version, av-signature-date | FortiGate | Version and date of the antivirus signature database |
ips-signature-version, ips-signature-date | FortiGate, Sophos (version only) | Version and date of the IPS signature database |
license-expiration | Cisco AsyncOS, Sophos, WALLIX Bastion | Nearest license expiration date |
support-expiration | Check Point, Sophos | Nearest support expiration date |
Dates are in the YYYY-MM-DD format.
Use the metadata
- In the inventory, filter the assets with the Metadata filter, or by entering
meta:key[:value]in the search bar. The key and the value are searched by prefix (see the search anchors). For example:meta:ha-state:standby: standby devices in a cluster;meta:config-unsaved:true: Cisco devices whose configuration is not saved;meta:license-expiration:2026: devices with a license that expires in 2026.
- Display a metadata as a column of the inventory, as described in Adding a metadata column. A key with several values, such as
virtual-chassis-member, displays its values separated by commas. - These filters can also be used in assets rules, alerts and exports. The API v3 returns the metadata in the details of an asset, and filters the list of assets by
metadata_keyandmetadata_value.
Listening ports
The scan reports the listening ports of the device in the “Ports” tab of the asset. It reads:
- for TCP, the
tcpListenerTabletable, or failing that the listening connections oftcpConnTable(TCP-MIB); - for UDP, the
udpEndpointTabletable, or failing thatudpTable(UDP-MIB).
The ports of loopback addresses are ignored, as are connected UDP sockets. A port that listens on all addresses is reported without address. SNMP gives neither the service nor the product of a port: these columns remain empty.
Reading is limited to 500 lines per table and to 60 seconds for all the tables. Beyond that, or if the device stops responding, Cyberwatch keeps the ports already read and reports it in the raw result of the scan with a # Listening ports from <table>: <reason> line.
As for other assets, a listening TCP port 21, 23 or 873 produces the FTP-port, Telnet-port or rsync-port security issues.
SNMP security issues
The scan reports the following security issues in the “Security issues” tab of the asset:
| Identifier | Severity | Title | Reported when | Detail |
|---|---|---|---|---|
SNMP_weak_community_string | High | SNMP weak community string | A community from the list of weak communities is accepted by the device, or is in its community table (snmpCommunityTable) | Community string: <community> |
SNMP_v1_v2c_enabled | Medium | SNMP v1/v2c enabled or configured | The scan is done in v1 or v2c, or the access configuration of the device (vacmSecurityToGroupTable) contains a v1 or v2c entry | SNMPv1 or SNMPv2c |
SNMP_no_authentication | Medium | SNMPv3 user without authentication | An SNMPv3 user of the device (usmUserTable) has no authentication | User: initial, otherwise User without authentication |
SNMP_weak_authentication_protocol | Low | SNMPv3 MD5 authentication | The scan user, or a user of the device, authenticates with MD5 | User: <user> (MD5) |
SNMP_weak_privacy_protocol | Medium | SNMPv3 weak or no encryption | The scan user, or a user of the device, encrypts with DES or does not encrypt | User: <user> (DES) or User: <user> (no encryption) |
These issues are deduced from the credential used and from the tables that the view makes readable. The scan remains non-intrusive: it never tries to authenticate otherwise than with the credential of the connection, except for the weak community test. This test only takes place for a scan in v1 or v2c. It tries, read-only, the communities of the list of the Nmap snmp-brute script: public, private, snmpd, mngt, cisco, admin, PUBLIC, PRIVATE, rmonmgmtuicommunity, secret, cascade, ANYCOM, ILMI, volition, TENmanUFactOryPOWER, MiniAP and snmp-Trap.
The name of a user without authentication is enough to query the device: it is not displayed, unless it is public, such as initial.
Each user, version or community gives a distinct occurrence of the security issue. An occurrence that is no longer detected during a successful scan is fixed, and an ignored occurrence remains ignored. The life cycle of security issues is described in Use security issues.
If the detection fails
If the scan fails, the asset keeps its last known state: firmware, vulnerabilities, metadata, ports and security issues are not erased. The failure is reported:
- on the analysis script of the asset, which goes into “Communication failed” with the error message;
- on the agentless connection, in the “Last connection error” column of the Agentless connections menu.
If the failures repeat, the asset eventually goes into communication failure.
Each SNMP request waits 3 seconds for its response and is retried 2 times. A scan lasts at most 5 minutes. The error message is prefixed with the enterprise number of the vendor, when it is known (PEN 9: …). The most common messages are:
| Message | Probable cause | Resolution |
|---|---|---|
Timeout after 3 seconds | The device does not respond: UDP 161 flow blocked, SNMP agent stopped, or community unknown to the device (v1, v2c) | Check the flows matrix, the SNMP configuration of the device and the credential. |
Unknown user name | The SNMPv3 user of the credential does not exist on the device | Check the username of the credential and the SNMP configuration of the device. |
Authentication failure (…) | Wrong SNMPv3 password or authentication protocol | Check the password and the authentication protocol of the credential. |
Decryption error | Wrong SNMPv3 password or encryption protocol | Check the password and the encryption protocol of the credential. |
Unsupported security level | The SNMPv3 user of the device does not have both authentication and encryption | Configure it with the authPriv level, see SNMP versions and credentials. |
Could not retrieve the version of <product> | The device does not give its version where Cyberwatch reads it | Check that the view includes the vendor branch, then contact the support. |
No Such Instance currently exists at this OID (<OID>), No such name (…) | An OID required for the detection is missing or excluded from the view | Check that the view includes the quoted OID, then contact the support. |
Time limit of 300 s exceeded | The device responds too slowly to complete the scan within 5 minutes | Check the load of the device and the network latency. |
If the device is not recognized, or if its detection keeps failing, write to support@cyberwatch.com with the error message and a complete SNMPWalk of the device (snmpwalk -On <device> 1.3.6.1).