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

[David Fifield <david () bamsoftware com>]

On Fri, May 04, 2012 at 05:11:43PM -0400, James Rogers wrote:
> On Fri, May 4, 2012 at 2:56 PM, David Fifield <david () bamsoftware com> wrote:
> > 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
>
> I will look at the tcp_probe_match area.
>
> Still learning how this scanning works.  Trying to connect to
> localhost:8080 and capturing the packets on wireshark gives me this:
>
> 1     0.000000        127.0.0.1       127.0.0.1       TCP     48877 > http-alt [SYN] Seq=0
> Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSV=46034350 TSER=0 WS=6
> 2     0.000030        127.0.0.1       127.0.0.1       TCP     http-alt > 48877 [RST, ACK] Seq=1
> Ack=1 Win=0 Len=0
>
> Which has both the ACK and the RST set.
>
> I am not positive, but the packet with the bug report looks like it
> just had the reset bit set.

What you're seeing is just the normal closed-port response. My guess is
you see the RST/ACK because it's in response to a SYN. Seeing just the
RST in the original is probably caused by the original probe being an
ACK, not a SYN. A RST is what we expect in response to an ACK probe, but
the SYN port scan is interpreting it as a response to a SYN probe, which
is wrong. But I don't think the presence or absence of the ACK flag is
really important here--my guess is that nmap-os-db has cases where
different OSes handle those flags differently.

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