mailing list archives
Re: Looking at how we handle low level TCP connection resets.
From: David Fifield <david () bamsoftware com>
Date: Fri, 4 May 2012 11:56:37 -0700
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:
SENT (0.1281s) TCP 192.168.0.21:53940 > 126.96.36.199:443 S ttl=59
id=23310 iplen=44 seq=3166348013 win=1024 <mss 1460>
RCVD (0.1440s) TCP 188.8.131.52:80 > 192.168.0.21:53940 R ttl=53
id=0 iplen=40 seq=3166348013 win=0
SENT (0.0978s) TCP 192.168.0.21:48346 > 184.108.40.206:443 S ttl=44
id=41206 iplen=44 seq=3988308439 win=1024 <mss 1460>
RCVD (0.1751s) TCP 220.127.116.11: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
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.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/