Re: SYN scan running slower than Connect scan?

[Fyodor <fyodor () insecure org>]

On Sat, Mar 18, 2006 at 11:50:50PM -0600, Ron wrote:

> Well, with the advice of "kx," I will re-post this and try to sound a
> little bit less abrupt.

Yeah, KX is pretty wise on these matters.

> 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.

Yeah, general Nmap questions are OK here.  Maybe I'll create an
nmap-helpers list someday for users to help each other use Nmap.  But
for now this is the closest we have got.  The nice thing is that
questions (and the answers) here are archived so that (we can hope)
future people with similar questions will find them.

> 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.

This packet count is true for open ports, but that is only a handful.
In your 65K-port scan, probably at 99.9% of the ports are in the
closed state.  In that case, both scan types involve two packets: A
SYN to the target and a RST coming back.

> 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?

First remember that we are talking about a very small time difference
here.  The 10.53 second run is 0.16 milleseconds per port and the
13.63 second scan is 0.21 milliseconds per port.  So we are talking a
difference of only one twentieth of a millisecond per port.  At these
speeds (you're obvilusly on a fast, reliable, low-latency network
without a firewally blocking any packets), issues like how many
context switches are required start making a big difference.  Both SYN
and connect() scan use basically the same algorithm (the ultra_scan()
function), so the differences mostly relate to how we interface with
the kernel:

Connect scan: Use the connect() call, then select() to determine which
file descriptors connected and which ones (the vast majority) didn't.

Syn scan: Use libpcap to listen for packets on the wire, react
appropriately when we see the RST's.

Which one is faster at these low levels depends on a lot of factors,
including the exact timing and especially what sort of system you are
running the scan on.  SYN scan is almost always faster than connect()
on Windows, for example, because there implementation is so lame (and
even intentionally inserts delays with SP2).  All in all, SYN scan is
the one to use unless you can't (aren't root, IPv6 scan, Windows
non-ethernet).  It's behavior against nonresponsive ports is much
better since it gives Nmap full control of retransmission times.
Also, Nmap is better able to interpret responses since it can read the
returned packet directly rather than having to divine what it might
have been based on the connection error.

Hope this helps,
Fyodor


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