NMAP Issue with Ping

[Louay Saleh]

Dear All,
 
I have a strange issue when using Nmap. I have a personal firewall. When it is enabled, I always get that the target of the scanning as down (although I am sure that the target is up since I did normal ping from my CMD and it was replying!) and I have to use the -PN switch. I thought my firewall was blocking the received packets of the TCP ping, but when I tried to do a Ping scan (using the -sP swicth, in order to do ICMP ping), I got the same issue. If I disable my firewall, everything is OK. I revised my firewall rules, but I could not find anything blocking the reply from either the TCP ping and the Ping scans of Nmap. It is very strange....this means that the firewall blocks only the ping replies (whether TCP or ICMP) related to Nmap, and allows the normal ping. This is the only conclusion I reached, but why is that?
 
I appreciate your help in advance.
 
Best Regards,



_____________________________________________________
He who learns but does not think, is lost!
He who thinks but does not learn is in great danger.

Confucius
(551-479 BC)
_____________________________________________________




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

[David Fifield]

On Mon, Nov 09, 2009 at 10:30:07PM -0800, Louay Saleh wrote:

> I have a strange issue when using Nmap. I have a personal firewall.
> When it is enabled, I always get that the target of the scanning as
> down (although I am sure that the target is up since I did normal
> ping from my CMD and it was replying!) and I have to use the -PN
> switch. I thought my firewall was blocking the received packets of the
> TCP ping, but when I tried to do a Ping scan (using the -sP swicth, in
> order to do ICMP ping), I got the same issue. If I disable my
> firewall, everything is OK. I revised my firewall rules, but I could
> not find anything blocking the reply from either the TCP ping and the
> Ping scans of Nmap. It is very strange....this means that the firewall
> blocks only the ping replies (whether TCP or ICMP) related to Nmap,
> and allows the normal ping. This is the only conclusion I reached, but
> why is that?
>  
> I appreciate your help in advance.

That's strange, because Nmap sends the same kind of probes that the ICMP
ping program sends. Try running your Nmap scan again, adding the option
"--data-length 64". Add the --packet-trace option to see what Nmap is
sending and receiving.

Nmap always does the same ping probes by default, whether you're port
scanning or only pinging with -sP. Even without -sP Nmap will send an
ICMP ping as one of its four host discovery probes.

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

[David Fifield]

On Fri, Nov 13, 2009 at 08:35:14AM -0800, Louay Saleh wrote:

> --- On Wed, 11/11/09, David Fifield <david@...> wrote:
>     From: David Fifield <david@...>
>     Subject: Re: NMAP Issue with Ping
>     To: "Louay Saleh" <lsaleh77@...>
>     Cc: nmap-dev@...
>     Date: Wednesday, November 11, 2009, 4:56 PM
>
>     On Mon, Nov 09, 2009 at 10:30:07PM -0800, Louay Saleh wrote:
>     > I have a strange issue when using Nmap. I have a personal firewall.
>     > When it is enabled, I always get that the target of the scanning as
>     > down (although I am sure that the target is up since I did normal
>     > ping from my CMD and it was replying!) and I have to use the -PN
>     > switch. I thought my firewall was blocking the received packets of the
>     > TCP ping, but when I tried to do a Ping scan (using the -sP swicth, in
>     > order to do ICMP ping), I got the same issue. If I disable my
>     > firewall, everything is OK. I revised my firewall rules, but I could
>     > not find anything blocking the reply from either the TCP ping and the
>     > Ping scans of Nmap. It is very strange....this means that the firewall
>     > blocks only the ping replies (whether TCP or ICMP) related to Nmap,
>     > and allows the normal ping. This is the only conclusion I reached, but
>     > why is that?
>     >  
>     > I appreciate your help in advance.
>
>     That's strange, because Nmap sends the same kind of probes that the ICMP
>     ping program sends. Try running your Nmap scan again, adding the option
>     "--data-length 64". Add the --packet-trace option to see what Nmap is
>     sending and receiving.
>
>     Nmap always does the same ping probes by default, whether you're port
>     scanning or only pinging with -sP. Even without -sP Nmap will send an
>     ICMP ping as one of its four host discovery probes.
>  
> Thanks for your fast reply.
>  
> I tried the "--data-length 64" option but I am still getting the same
> problem.
>  
> By the way, I am confused a little bit about the last part. My
> understanding (and please correct me if I am wrong) that nmap will do
> a ping scan, then a SYN stealth scan in all case, unless you
> explicitly specify to do a -sP ping, so in that case it only does a
> ping scan; which are two probes. So, what do you mean by the 'four
> discovery probes'?

Nmap used to send two probes for host discovery, but now it sends four
because that was found to be more effective. See
http://nmap.org/book/man-host-discovery.html.

But when the target is on the same Ethernet network, Nmap uses an ARP
ping instead. It was recently discovered that some operating systems
send their ARP replies in a way that was not understood by Nmap. This
has been fixed but the fix is not yet in a released version. Do you know
the operating system of the target? I bet this is the issue.

Try running the scan with the --send-ip option. That will disable the
ARP scan use the normal four-probe IP ping scan.

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

[Corey Chandler]

David Fifield wrote:
> Nmap used to send two probes for host discovery, but now it sends four
> because that was found to be more effective. See
> http://nmap.org/book/man-host-discovery.html.
>
> But when the target is on the same Ethernet network, Nmap uses an ARP
> ping instead.

nmap determines this automatically, correct?  In other words, if I'm
scanning 192.168.1.0/24, and the box itself lives at an IP contained
within that subnet, it'll automatically switch itself over to ARP pinging?

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

[David Fifield]

On Fri, Nov 13, 2009 at 10:46:32AM -0800, Corey Chandler wrote:

> David Fifield wrote:
>> Nmap used to send two probes for host discovery, but now it sends four
>> because that was found to be more effective. See
>> http://nmap.org/book/man-host-discovery.html.
>>
>> But when the target is on the same Ethernet network, Nmap uses an ARP
>> ping instead.
>
> nmap determines this automatically, correct?  In other words, if I'm  
> scanning 192.168.1.0/24, and the box itself lives at an IP contained  
> within that subnet, it'll automatically switch itself over to ARP
> pinging?

Right. See the function route_dst in tcpip.cc, the parts where it sets
rnfo->direct_connect. This code in nexthost in targets.cc does the ARP
ping if 1) it's an Ethernet interface, 2) all the targets in the group
are directly connected, and 3) --send-ip was not used.

/* First I'll do the ARP ping if all of the machines in the group are
   directly connected over ethernet.  I may need the MAC addresses
   later anyway. */
 if (hs->hostbatch[0]->ifType() == devt_ethernet &&
     hs->hostbatch[0]->directlyConnected() &&
     o.sendpref != PACKET_SEND_IP_STRONG) {
   arpping(hs->hostbatch, hs->current_batch_sz);
   arpping_done = true;
 }

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