This is the first in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes“.
The book Nmap Network Scanning has this to say about the ARP Scan:
One of the most common Nmap usage scenarios is to scan an ethernet LAN.
[....]
Nmap issues raw ARP requests and handles retransmission and timeout periods at its own discretion.
And the above Wireshark book:
The disadvantage of uing an ARP scan is that the ARP traffic can’t get through a router or any layer 3 device. The advantage of running and ARP scan is that you can discover local devices that may be hidden from other discovery methods by a firewall. If the firewall blocks ICMP-based pings, you can use an ARP scan to discover the device. You cannot disable ARP responses – that would break the TCP/IP communications system.
Keep in mind that ARP scans will not cross a router. If you detect an ARP scan taking place, the source will be on the same network you are capturing traffic on.
OK, I performed the following Nmap ARP scan on my hacking lab:
~# nmap -PR 192.168.1.79
Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-08 12:15 BST
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.052s latency).
Not shown: 949 closed ports, 41 filtered ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
912/tcp open apex-mesh
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)Nmap done: 1 IP address (1 host up) scanned in 2.23 seconds
I observed in Wireshark and the only indication of the scan were the ARP requests:
The Wireshark book notes: “Common ARP scan processes send ARP requests to broadcast MAC address 0xff:ff:ff:ff:ff:ff”, this was proved correct on analysing one of the ARP packets:
