BUG: Solaris 10 arp-reply broadcast and bug in Nmap pcap filter causing host down status for Solaris 10 systems

[Marcus Haebler <haebler () gmail com>]

Hi,

I just ran into an issue with scanning a directly connected (same 
subnet) Solaris 10 from a Linux host with Nmap 4.76.

By default Nmap on Linux sends raw Ethernet frames(--send-eth). For 
L2 connected targets Nmap uses "ARP ping". Nmap sends the ARP request 
packet correctly. To receive the reply Nmap listens to the sending 
network interface using a libpacp filter that filters for its own MAC 
address in the destination address field of the Ethernet(!) header. 

Here is the output (-d3):

Pcap filter: arp and ether dst host <MAC>
Packet capture filter (device eth0): arp and ether <MAC>

<MAC> is the six octet MAC address of the Ethernet interface used for 
sending the ARP request. 

Under "normal" circumstances the target sends a unicast ARP reply 
back to Nmap. The reply passes the filter and Nmap marks the host 
as up.

If the target is a Solaris 10 system the behavior is different. 
Solaris 10 (seen with one set of Solaris 10 systems so far) sends 
the ARP reply back to Nmap as a broadcast. Meaning, the Ethernet 
header destination address is FF:FF:FF:FF:FF:FF. This reply gets 
dropped by the above pcap filter, and Nmap falsely marks the target 
as down.

I could not find any reference in any of the RFCs that the ARP reply 
must be unicast but from a network performance point of view it 
makes sense to send unicasts.

The solution to this is a pcap filter that filters for the sending 
interface MAC in the 'Target MAC Address' field of the ARP(!) reply 
message. Unfortunately, it is a bit ugly since libpcap does not seem 
to have the ability to address that field by name and does not handle 
6 byte fields directly.

arp and 
arp[18:4] = 0x<1st four bytes of MAC> and 
arp[22:2] = 0x<last two bytes of MAC> 

The different bytes in the filter string above are NOT colon 
separated. If the MAC address were 001122334455 the filter would look 
like this

arp and arp[18:4] = 0x00112233 and arp[22:2] = 0x4455

It is probably OK to omit the '^arp and' part but the above filter is 
on the safe side.

This filter is set in scan_engine.cc and tcpip.cc in slightly different 
ways (code differs). The code in scan_engine.cc is the one handling the 
"ARP ping" in the case above. I am not sure when the code in tcpip.cc 
is called. Nevertheless, I modified the code in both files to generate 
the filter above and Nmap started working on that set of Solaris 10 
hosts.

Another option is to just filter for all ARPs ("arp") but it will 
generate a lot more data on a busy network to be searched for the 
replies to the probes.

BTW using "--send-ip" works fine and is a possible workaround.

The Solaris 10 behavior was recently described on the sunmanagers 
mailing list. See this post:

<http://unix.derkeiler.com/Mailing-Lists/SunManagers/2009-01/msg00015.ht
ml>

I am not sure at this point if this is a general Solaris 10 behavior or 
if this changed in one of the latest 10u<x> releases.

Hopefully this bug can be fixed in the next Nmap stable release.

Thanks,

Marcus



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org