Looking at how we handle low level TCP connection resets.

[James Rogers <jamesmrogers () gmail com>]

As I learn things about nmap I am going to write up what I find.

--

I'm learning how raw sockets on multiple platforms work:

http://mystry-geek.blogspot.com/2012/05/researching-raw-sockets-in-unixlinuxmac.html

--

and looking at the source code for nmap with LXR:

http://mystry-geek.blogspot.com/2012/05/setting-up-apache-and-linux-cross.html

--

Looking at this bug:

http://seclists.org/nmap-dev/2012/q1/62

 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.

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.

Any solution along these lines should also wait a random, increasing
amount of time between retries.  Can't recall the rfc that specifies
this technique.

I believe this method would be very effective because nobody is seeing
these resets very often.  Just one in ten or twenty times.  When they
retry the command it almost always works the second try.

What does everyone think about retrying when we get a tcp reset?
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/