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:
- Question about timings Ron (Mar 18)
- SYN scan running slower than Connect scan? Ron (Mar 18)
- Re: SYN scan running slower than Connect scan? Fyodor (Mar 18)
- SYN scan running slower than Connect scan? Ron (Mar 18)