Re: Weird Crash - "WAITING_TO_RUNNING"

[Rob Nicholls <robert () robnicholls co uk>]

On Mon, 8 Nov 2010 14:40:07 -0700, Nathan <nathan.stocks () gmail com> 
wrote:
> We believe that many of the connections we are scanning are satellite
> Internet connections (some of our clients are retail stores or
> restaurants, and they tend to have exotic ways to connect to the
> Internet).  I speculate that perhaps the inbound routers for these
> high-latency connections tend to proxy stuff...which may or may not
> have anything to do with anything.  But I though I'd throw it out
> there.

Is it possible that a Performance Enhancing Proxy is sending back the 
SYN/ACK you're seeing if the satellite connection gets busy (which might 
be why scanning the top 100 ports works in many cases, as it might be 
below the threshold required for the proxy to kick in)? I get the 
impression that such a proxy will always return a SYN/ACK even though it 
has no idea what the state is of the port at the other end (it probably 
hopes/assumes that most requests are legitimate ones from authorised 
hosts for known open ports?), which is why Nmap sees the SYN/ACK and 
assumes that the port is open - because the PEP claims that it is. It's 
possible that the PEP eventually returns a RST from the end device for 
closed ports, but Nmap would discount that packet as it's already 
perform the SYN scan. Even a full three way handshake wouldn't fix the 
scan results. Your best bet for accurate results is probably to slow 
down the scan to prevent the PEP from kicking in (if it's always present 
then you'll never get around it and always get false positives; Nmap 
could possibly check for RST packets afterwards, but filtered ports 
would probably still look open). Do you get accurate results with a much 
larger scan delay? I appreciate it'd take a day or so to scan, but can 
you try a scan delay of 1 second rather than 1ms? I presume you'd know 
prety quickly (e.g half way) if it was identifying loads of open ports 
like before.

Rob

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