nmap and your network

Nmap, or Network Mapper, is a free, open-source tool that scans networks for security vulnerabilities. It’s used by network administrators, security professionals, and others to:

• Discover hosts on a network
• Identify open ports
• Detect running services
• Find security loopholes
• Monitor host and service uptime
• Audit network inventory

A common method used to ‘map’ what hosts are on a network is to use nmap with something like

nmap -sn 192.168.1.0/24

which will list out hosts found to be up and then, to examine in a little more detail an indivdiual host on that network we may use something like :

nmap 192.168.1.141
Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-21 11:07 GMT
Nmap scan report for OnePlus-9.lan (192.168.1.141)
Host is up (0.23s latency).
All 1000 scanned ports on OnePlus-9.lan (192.168.1.141) are in ignored states.
Not shown: 1000 closed tcp ports (reset)
MAC Address: 7A:A0:F3:62:95:53 (Unknown)

the above is from a list of ips found with leases in a test network, running on wifi with dual band, this one as it happens is on the upper 5Ghz connection

sometimes, this returns nothing, even though it is on

root@OpenWrt:~# nmap 192.168.1.141
Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-21 11:10 GMT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 1.79 seconds

so the nmap needs to be run several times to get an answer ( on this network and in this scenario )

reasons for this could be varied

one could be power saving mode that some wifi devices may be set to us

ping responses are given lower priority by devices and sometimes the routers themselves on that network, depending on load

connection could be flaky, wifi is subject to interferance from external sources

other devices come back with less information than the previous

nmap 192.168.1.197 | tee nmap-jons-phone1.txt 
Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-21 11:23 GMT
Nmap scan report for 192.168.1.197
Host is up (0.0026s latency).
All 1000 scanned ports on 192.168.1.197 are in ignored states.
Not shown: 1000 closed tcp ports (reset)
MAC Address: 72:0A:F5:2A:C8:50 (Unknown)

as it happens, this device is very similar to the first, yet it obstinately refuses to say anything about its type or origin

several things could be happening here but one possibility could be that one of the devices is configured in some way not to return a hostname and the other is, dynamic dns is recording one and thus not the other

nslookup 192.168.1.141
Server:		127.0.0.1
Address:	127.0.0.1:53

141.1.168.192.in-addr.arpa	name = OnePlus-9.lan

so this is born out by doing a reverse lookup of the device nmap picks up with a name

nslookup 192.168.1.197
Server:		127.0.0.1
Address:	127.0.0.1:53

** server can't find 197.1.168.192.in-addr.arpa: NXDOMAIN

and with the other device, no hostname is found, which correlates with the nmap from above

another, rather hidden aspect but none the less relevent is that MAC addresses of devices are often not the ‘real’ hardware address of a given device as is oft the case now, where for security reasons, devices generate a random MAC address for each network that they join.

The reason behind this is so that bad actors cannot track users as they go from one public wifi network to the next.

If on your own network you are filtering traffic based upon MAC address you need to be cognicent of this. The consequence is that if a users device ‘forgets’ a network and re-joins the same network, a new MAC is generated so you can’t rely on the MAC they were origonally logged as using being constant. Any session based information would need to be persisted at an application level where a users logs could be associated with 1 or more MAC addresses. There would need to be a mechanism also for re-associating such a user with their ‘old’ records and logs.