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 16:30:39 -0700
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:
SENT (0.1281s) TCP 192.168.0.21:53940 > 220.127.116.11:443 S ttl=59
id=23310 iplen=44 seq=3166348013 win=1024 <mss 1460>
RCVD (0.1440s) TCP 18.104.22.168: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 > 22.214.171.124:443 S ttl=44
id=41206 iplen=44 seq=3988308439 win=1024 <mss 1460>
RCVD (0.1751s) TCP 126.96.36.199: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.
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.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/