Re: Looking at how we handle low level TCP connection resets.

[David Fifield <david () bamsoftware com>]

On Fri, May 04, 2012 at 02:24:30PM -0400, James Rogers wrote:
>  o Solve "spurious closed port detection" issue discovered by David:
>    http://seclists.org/nmap-dev/2012/q1/62 .  So we need to figure
>    out what is going on here and then how to fix it.  Note that this
>    doesn't seem to happen when you do ICMP host discovery first (-PE),
>    so it probably relates to the ACK packet that Nmap sends to port 80
>    on the target by default.
>
> Looking at the log file provided it appears that the only difference
> between the good result and the incorrect result was this:
>
> Bad:
> SENT (0.1281s) TCP 192.168.0.21:53940 > 74.207.254.18:443 S  ttl=59
> id=23310 iplen=44 seq=3166348013 win=1024 <mss 1460>
> RCVD (0.1440s) TCP 74.207.254.18:80 > 192.168.0.21:53940  R  ttl=53
> id=0 iplen=40     seq=3166348013 win=0
>
> Good:
> SENT (0.0978s) TCP 192.168.0.21:48346 > 74.207.254.18:443 S  ttl=44
> id=41206 iplen=44 seq=3988308439 win=1024 <mss 1460>
> RCVD (0.1751s) TCP 74.207.254.18:80 > 192.168.0.21:48346  SA ttl=53
> id=0 iplen=44     seq=3034488989 win=14600 <mss 1460>
>
> The bad run we received a reset and incorrectly reported the server as down.

Do you really mean the server was reported as down? Even when we receive
a RST from a SYN (or any TCP) probe during host discovery, we mark the
host up. (Look at the places where "newstate = HOST_UP" is set in
get_ping_pcap_result in scan_engine.cc.)

The bug I observed was that the host was marked up, but later the *port*
was marked closed. We speculated that it is because of the RST reply to
the ACK host discovery probe coming back late and being interpreted by
the port scanning engine, but this is just speculation--we didn't test
it.

> I'm tracking down how we handle a reset on a connection and looking at
> maybe just doing a retry when we get a reset on any TCP protocol check
> (such as seeing if the web server on port 80 is up), up to the retry
> count the user sets.  I believe the default is 10.   This is similar
> to how you sometimes get a "connection reset by remote server" when
> you are making a web server connection with a browser.  The solution
> there is to click reload a few times before you finally decide the
> server is down, so I thought it could work for us too.

My first thought is that retrying is the wrong idea in this case. For
one thing, it's going to roughly double scan times in the common case
that most ports are closed, and it's really only necessary for port 80
if our speculation is correct.

Maybe we need to do more careful seq/ack matching, so that replies to
unrelated probes are not matched up? Try stepping through
tcp_probe_match in a debugger and seeing how the reply is being matched
to a probe. I think it's important to understand how that works.

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