Scanning a network with building a list of devices and their properties, such as a list of network interfaces, and then removing data in monitoring systems, if you do not delve into what is happening, it may seem special, computer magic. How does it work - under the cut.

Disclaimer
The author does not have a specialized education associated with the administration of networks, so there are probably inaccuracies and not all that is mentioned is mentioned.
Detection
To detect a device, i.e. determine if there is anything on the selected ip-address, you can apply the following methods:
- ping scan
Oddly enough, this is the easiest and most common way.
- Check open TCP ports
If the ping response is disabled on the device, you can try to establish a connection using a TCP port. In view of the fact that there are many ports and checking each of them takes considerable time, only the most common ones are usually checked, for example. 80 or 443 used for the web interface of the device. - Verifying the operation of UDP services
The UDP protocol does not send confirmation of receipt of the request and therefore, in general, UDP port scanning is not possible. However, you can try to interrogate services that listen on the UDP port and send a response to the request, for example. SNMP (port 161) or IPMI (port 623). In case a response other than a timeout is received, the device is detected. - ARP scanning
In addition to the usual ICMP requests that use the ping utilities, for devices in the same L2 broadcast domain, you can use faster arping . The MAC address of the requestor ”, and if a response is received, the device is considered detected. - CDP / LLDP
If the network uses the LLDP protocol (or CDP equivalent), then devices can collect information about their neighbors that can be considered detected. This data is available via SNMP.
')
I note that the information about the neighbors together with the traceroute
results can serve as the basis for building a physical map of the network. - NetBIOS scan
The NetBIOS protocol can be used to search for Windows machines, for example using the nbtscan
utility. - DHCP logs (suggested by alexanster )
In the DHCP server logs there is information about issuing ip-addresses to MAC-addresses. For recent entries in the log, we can assume that these devices are detected. - ARPWatch (suggested by alexanster , described by TaHKucT )
Arpwatch keeps track of pairs of IP addresses - MAC addresses, recording new, missing and changed pairs to the log. Devices trapped in the log can be considered detected.
- Analysis of switch FDB tables (suggested by mickvav )
FDB tables (Forwarding DataBase) of managed switches contain data on switching of MAC addresses of subscribers and devices, i.e. corresponding to the MAC address of the device - switch port.
Data is available via SNMP and telnet, and can be used when building a physical network map.
Collection of information
After the device is detected, you can proceed to gathering information about it.
Using the ARP protocol, you can get a MAC address via ip, and a probable manufacturer can get it (some equipment allows changing the address, so the method is not very reliable). Then you can use the
nmap utility, which scans the open ports, compares with its database of fingerprints and
makes an assumption about the operating system used, its version and device type.
Getting device type and operating system using nmap nmap -O -v 192.168.0.1 Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-04 01:17 RTZ 2 (ceia) Initiating ARP Ping Scan at 01:17 Scanning 192.168.0.1 [1 port] Completed ARP Ping Scan at 01:17, 0.70s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 01:17 Completed Parallel DNS resolution of 1 host. at 01:17, 0.00s elapsed Initiating SYN Stealth Scan at 01:17 Scanning 192.168.0.1 [1000 ports] Discovered open port 80/tcp on 192.168.0.1 Discovered open port 49152/tcp on 192.168.0.1 Discovered open port 1900/tcp on 192.168.0.1 Completed SYN Stealth Scan at 01:17, 0.13s elapsed (1000 total ports) Initiating OS detection (try #1) against 192.168.0.1 Retrying OS detection (try #2) against 192.168.0.1 WARNING: OS didn't match until try #2 Nmap scan report for 192.168.0.1 Host is up (0.00s latency). Not shown: 997 closed ports PORT STATE SERVICE 80/tcp open http 1900/tcp open upnp 49152/tcp open unknown MAC Address: A0:F3:C1:35:21:58 (Tp-link Technologies) Device type: WAP Running: Linux 2.4.X OS CPE: cpe:/o:linux:linux_kernel:2.4.36 OS details: DD-WRT v24-sp1 (Linux 2.4.36) Network Distance: 1 hop
To obtain more detailed information on the device, you will need one of the following methods:
- SNMP
SNMP is almost always supported by routers and switches; available in Windows (the corresponding service is disabled by default); Linux requires the installation of the snmpd daemon. Apparently the last third version is quite difficult to implement, so the previous version 2c is still relevant, although not recommended because of the lack of encryption during data transfer. The protocol works on the 161 UDP port of the device.
You can use the Net-SNMP utility package to work with SNMP . To get, for example, a description of the device, you must specify the protocol version, the password for reading (community read, public by default) and the address in SNMP notation called the OID (object identificator) and consisting of numbers and points. All addresses of the device can be represented as a tree, where the addresses are sorted in lexicographical order. The protocol allows you to request the current value at the address, as well as the addresses following the current one.
Getting device description using snmpget snmpget -v 2c -c public 192.168.0.102 1.3.6.1.2.1.1.1.0 SNMPv2-MIB::sysDescr.0 = STRING: Linux debian 3.16.0-4-586 #1 Debian 3.16.43-2+deb8u2 (2017-06-26) i686
The standard set of addresses is very limited and contains a description of the device, contacts, location and uptime. The remaining addresses depend on the device manufacturer and can be obtained by scanning, for example, using the snmpwalk utility. Fortunately, Linux and Windows have typical addresses for network interfaces and CPU / memory load, so all they need to know (or be able to determine) is the operating system used.
Getting Linux disk descriptions using snmpwalk snmpwalk -v 2c -c public 192.168.0.102 1.3.6.1.4.1.2021.9.1.2 UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskPath.2 = STRING: /var UCD-SNMP-MIB::dskPath.3 = STRING: / UCD-SNMP-MIB::dskPath.4 = STRING: /run UCD-SNMP-MIB::dskPath.5 = STRING: /dev/shm UCD-SNMP-MIB::dskPath.6 = STRING: /run/lock UCD-SNMP-MIB::dskPath.7 = STRING: /sys/fs/cgroup
Getting Windows disk descriptions using snmpwalk snmpwalk -v 2c -c public localhost 1.3.6.1.2.1.25.2.3.1.3 HOST-RESOURCES-MIB::hrStorageDescr.1 = STRING: C:\ Label: Serial Number a65ceb77 HOST-RESOURCES-MIB::hrStorageDescr.2 = STRING: D:\ Label: Serial Number ded9f83e HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: E:\ Label: Serial Number 8e764a1 HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: I:\ HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: Virtual Memory HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: Physical Memory
- WMI
WMI technology is an enhanced and adapted for Windows implementation of the WBEM standard that allows you to remotely not only read parameters, but also control the device. WMI runs on top of RPC (TCP port 135) and DCOM (on an arbitrary TCP port above 1024), and is actively used in Power Shell scripts (previously Windows Script Host).
Data can be queried, of course, only from Windows machines.
Get RAM information in PowerShell Get-WmiObject win32_OperatingSystem |%{"Total Physical Memory: {0}KB`nFree Physical Memory : {1}KB`nTotal Virtual Memory : {2}KB`nFree Virtual Memory : {3}KB" -f $_.totalvisiblememorysize, $_.freephysicalmemory, $_.totalvirtualmemorysize, $_.freevirtualmemory} Total Physical Memory: 2882040KB Free Physical Memory : 612912KB Total Virtual Memory : 5762364KB Free Virtual Memory : 1778140KB
There is also a console utility wmic and its Linux port.
Getting device maker with wmic wmic /USER:admin /PASSWORD:mypassword /NODE:"192.168.0.100" computersystem get Manufacturer Manufacturer Gigabyte Technology Co., Ltd.
- Agent monitoring system, for example. Zabbix or Check_MK
If possible, a small program is installed on the device that runs in the background and collects data. The advantage of using agents is that data acquisition is unified regardless of the hardware and operating system used by the device, and it is also possible to collect data available only locally (for example, the result of the console program). - Ssh
Initially, data on SSH can be obtained from Linux and iOS devices. For Windows and Android, you will need to install an SSH server.
Getting CPU information over SSH cat /proc/cpuinfo processor : 0 Processor : AArch64 Processor rev 4 (aarch64) Hardware : sun50iw1p1 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 1 ...
- Requesting data from a management service , such as a virtual machine hypervisor
How it works on the example of Zabbix
As you know,
Zabbix can independently discover new devices on the network and automatically poll some of their parameters. This is called -
Low Level Discovery .
Device discovery is defined by
network discovery rules that combine the detection methods listed earlier, determine whether a device is available and which template to apply to it (the device description is usually examined). The template contains a list of properties that can be obtained from the device, as well as rules for the detection and creation of new, executed on a timer.
In the case of SNMP, this might look something like this: enumerate all the child elements of the
1.3.6.1.2.1.2.2.1.8
node (detection rule) and for each element found (the number placed in
{#SNMPINDEX}
) add new metrics set via prototypes of data elements,
1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}
and
1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX}
, if they are not already there. Read more
here .
In the case of an agent, the rule will look a little different: request one of the discovery properties from the agent, for example
system.cpu.discovery
, get a list of processors in the form of json
[ {"NUMBER": 0, "STATUS": "online"}, {"NUMBER": 1, "STATUS": "online"} ]
and for each element add
system.cpu.load[{#CPU.NUMBER}]
, if there is no such metric yet. It should be noted that Zabbix-agent allows you to create your own elements (
UserParameter
), which can be requested, and therefore you can easily implement, for example, finding files and tracking their size in a given folder. Read more
here .
Conclusion
As you can see everything is quite simple and there is no magic. If you know any other ways to detect devices or get their properties, please report them.