Re: Windows nmap -sP vs Cisco Firewall

["Rob Nicholls" <robert () everythingeverything co uk>]

> The work around seems to be adding an addition flag like "-PE", but it
> doesn't seem that should be required, and I've got a handful of customers
> complaining a firewall migration to Cisco from a Linux IPtable setup
> "broke"
> Windows Nmap.  It appears the firewalls are doing their job, where as the
> older firewalls were not stateful in the same sense, and are stopping a
> connectionless packet sent from Windows nmap.
>
> Any feedback?  Thank you!

I can't remember what version started doing it (version 4.11 and above
appear to do it), but more recent versions of Nmap will send an ACK packet
to TCP port 80 when performing a ping scan (-sP), which is what's seen in
the ASA debug output (if the error doesn't appear when scanning from the
Linux host it suggests 4.03 doesn't try sending an ACK). The -PE flag
forces Nmap to only send echo requests (which is presumably all that 4.03
is doing during -sP), which is why both state the host is down. You can
verify what packets are sent and received by appending --packet-trace.

If the Cisco device is dropping/filtering the ACK packets then the -sP
scan on Windows shouldn't get any response back from the ACK or the ICMP
echo request and should therefore declare the host is down. Therefore, I'm
wondering if the Cisco device is returning a TCP reset when it sees the
ACK?

A quick look on Google suggests that if "service resetoutside" is enabled
on the Cisco device then (instead of dropping the packet by default) it
will actively reset denied TCP packets and another reference suggests that
it will attempt to impersonate the destination IP too. If so, this
probably causes Nmap to think the host at that IP address is up as it got
some form of response (IIRC Nmap looks for a SYN/ACK or RST from the IP
address after it sends an ACK).

If you can run Nmap on the Windows host with --packet-trace then you
should be able to see what responses you get back during the -sP scan.
It's just a guess, but I suspect the Cisco device is spoofing the IP
address and returning TCP resets when it sees the ACK packets and it can't
associate it with any connections, while the Linux firewall was possibly
filtering the ACK packet (like a lot of firewalls do nowadays) so Nmap
4.76 on their Windows box never previously saw a response.

Rob



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