Nmap Development mailing list archives
Re: Windows nmap -sP vs Cisco Firewall
From: "Rob Nicholls" <robert () everythingeverything co uk>
Date: Tue, 27 Jan 2009 09:54:37 -0000 (UTC)
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
Current thread:
- Windows nmap -sP vs Cisco Firewall bitgod (Jan 26)
- Re: Windows nmap -sP vs Cisco Firewall Rob Nicholls (Jan 27)
- <Possible follow-ups>
- RE: Windows nmap -sP vs Cisco Firewall Tom Sellers (Jan 26)