RE: Host Discovery and RST Packets

["jmk" <jmk () foofus net>]

Hi Daniel,

 

If I was doing host discovery as part of penetration test, or similar task, the manual filtering would definitely work. 
I’d probably just build a target list of only the addresses that Nmap reports back as having an open port. The problem 
here is that Nexpose is kicking off Nmap and using it to feed the scan. The scan will also be scheduled to run 
automatically on a weekly basis. This makes any manual filtering and uploading of a target list challenging.

 

I haven’t identified any of the available options that seem to do the job. For example, -PA gets a RST and flags the 
host as up. –PU flags hosts with open TCP ports, but no UDP, as down. ICMP is blocked for some of the subnets, but not 
others. Jacek emailed me off-list with a suggestion on where to modify the Nmap source to ignore the RST packets. This 
appears to be working in my initial testing. The trick will be how to integrate the change into the Nexpose scan 
engines and their respective copies of Nmap. I’m sure I’ve run into this “firewall sending RSTs for non-existent hosts” 
situation in the past. In those cases, I just manually filtered out what I wanted. If this is indeed a not completely 
unheard of situation, would it make sense to have it as a configurable option within Nmap? 

 

Thanks,

Joe

 

 

From: Daniel Miller [mailto:bonsaiviking () gmail com] 
Sent: Friday, December 4, 2015 4:02 PM
To: jmk <jmk () foofus net>
Cc: Nmap-dev <dev () nmap org>
Subject: Re: Host Discovery and RST Packets

 

Joe,

Nmap has lots of options for doing host discovery. With a little experimentation, you can probably find some probe that 
avoids being intercepted. Likely options are -PA (unsolicited ACK) and -PU (UDP), especially in combination with -PE 
(ICMP Echo request) and -PP (ICMP Timestamp request). Try each alone to a known-bad address and use all the ones that 
do not list that address as "up"

Alternatively, you could do a manual filtering step between host discovery and port scan phases. Use the -sn option to 
turn off port scanning (and leave off -A, -O, --script, and other -s* options) and save XML output with -oX or -oA. 
Then use an XML parser to extract the //host/status/@reason_ttl attribute for each host (you could probably also 
collect any @reason != "syn-ack"). More than likely, the firewall sending spoofed replies will be distinguishable from 
the real replies because the packets originated closer to you, so they will arrive with a higher TTL. So if you have a 
ton with @reason_ttl == "53" and a few with 52 or lower, then extract the addresses of the ones with a lower TTL. These 
are your real targets. Then use the -iL option to input the target list from a file when you do your port scan phase. 
Don't forget to add -Pn to skip the already-accomplished host discovery.

Dan

 

On Fri, Dec 4, 2015 at 12:56 PM, jmk <jmk () foofus net <mailto:jmk () foofus net> > wrote:

Hi,

 

I’m using Nexpose to scan a highly segmented internal network. Nexpose calls Nmap to handle host discovery and is 
finding thousands of assets that don’t really exist. It looks like there is an intermediate device between the target 
subnets and my scanner that is sending a RST,ACK for every SYN to a non-existent host. Unfortunately, Nmap flags this 
as the target host being up. Is there a way with Nmap to force it to only report a host being up if it either receives 
a SYN,ACK and/or ICMP reply? I should note that some network segments block ICMP, so I can’t rely on that alone for 
asset discovery.

                                                                                                                        
                                                                                                                    

Thanks,

Joe

 

 


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

 

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