Nmap Development mailing list archives

SYN scan running slower than Connect scan?


From: Ron <iago () valhallalegends com>
Date: Sat, 18 Mar 2006 23:50:50 -0600

Well, with the advice of "kx," I will re-post this and try to sound a 
little bit less abrupt.  If my first post annoyed anybody, sorry.  I 
thought it was a simple question with a simple answer that I was 
missing, but perhaps I was wrong.  I will elaborate on the background 
and on what exactly I have done in the hopes that it will be more 
answerable, or something.

It may be debatable whether or not this is appropriate for the nmap-dev 
forum, but I suspect that this weirdness (that I will describe) stems 
from something weird in the implementation of Nmap.  Since this is the 
densest group of people who are knowledgeable in that area, it seems 
logical to post this here.

First, some background.  I am doing a University project about 
portscanning (and host enumeration, OS detection, etc.).  I have been 
using Nmap for many of the tests because, having worked as a security 
analyst for some time, I know that Nmap is the best tool ever made.  Not 
that I'm trying to suck up.  But anyways, I have come across a piece of 
odd behaviour that I have been unable to account for.

Before continuing, I should make it clear that I understand how each of 
the scans work.  In fact, that is pretty much the reason I knew that 
something was up.  A SYN scan sends SYN, receives SYN/ACK, and responds 
with RST (for open ports).  A Connect scan sends SYN, receives SYN/ACK, 
sends SYN, and closes the connection (either with RST or FIN FIN/ACK 
ACK, I'm not really sure) (for open ports).  Closed ports are the same, 
I think, with SYN RST.  Filtered ports are not relevant, I'm scanning 
over a LAN.  So, a SYN scan sends 2 packets: SYN and RST, and receives 
1: SYN/ACK.  A Connect scan sends at least 3 packets: SYN, ACK, and RST, 
and receives 1: SYN/ACK.  Because it sends more packets, it is logical 
to me that a Connect scan would run slower on any system with open ports.

Now, here's what I found odd:

When I perform a SYN scan on 65,535 ports against Linux (from Linux), it 
takes 10.53 seconds (average of 10 tries).  When I perform a Connect 
scan on the same port range and OS, it takes about 13.63 seconds 
(average of 10 tries).

When I perform the same SYN scan against Windows (from Linux), it takes 
12.93 seconds, on average.  If I perform the same Connect scan against 
Windows, it takes 10.74 seconds, on average.

I graphed the results, because my professor likes graphs.  It can be 
found at http://www.javaop.com/~iago/65535.png .  I apologize in advance 
for the ugly green.

As far as I know, neither of the scan targets (or the source) is rate 
limiting or doing anything strange with packets.

Does anybody here know any reason why a SYN scan would run slower than a 
Connect scan, from Linux?  Is it just weirdness in the implementation? 
Or is there some networking reason?

Thanks for any responses,
Ron


Ron wrote:
Hello,

I'm doing a school project on port mapping (why not?), and I was looking 
at the timings for different scans.  I noticed that a SYN scan (-sS) 
takes a little bit more time than a Connect scan (-sT).  Does anybody 
know why?  I figured that -sS would be faster because it uses less 
packets, but apparently that's not the case.

Thanks
Ron


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev


Current thread: