syn scan vs connect scan

[Paul Johnston <paul () westpoint ltd uk>]

Hi,

I'm wondering about the merits of syn scan vs connect scan.

I believe what is sent on the network is the same for closed ports, but
for open ports the syn scan sequence is: send syn, recv syn-ack, send
rst. For connect scan it's send syn, recv syn-ack, send syn-ack-ack,
send rst. So they should produce get exactly the same results, as the
network sequence is identical up to the point the open/closed decision
is made.

Actually, they're not exactly the same. The source port pattern is
different, as is the window size, isn, and the connect scan has these
options:
<mss 1460,sackOK,timestamp 1141465056 0,nop,wscale 0> (DF)
Do these make much difference?

Which scan is more likely to damage the target host? I would have
thought connect scan more intrusive, as syn scan will only touch the
kernel on the target, but connect scan will hit all the user space
processes. I've heard suggestions that the syn-scan can leave sockets in
a half-open state and exceed resource limits. I doubt it as the reset is
sent, but what do you guys think?

I've heard claims that some systems (e.g. mobile phones) crash on a syn
scan but not on a connect scan. Has anyone here encountered this in
practice? And if you haven't, please still let me know, so I've got some
idea!

Does syn scan violate the tcp standard? I've heard this suggested, but I
think not because you are allowed to tear down the connection with a
reset any time you want.

Seems to me the main advantage of syn scan is that it performs better
against firewalled hosts. Using Redhat-7.2 (kernel 2.4.7-10) and
nmap-3.30 I watched scans of a single port against a firewalled host.
Syn scan sent the syn packet 6 times in total, with a gap of 6 seconds.
Connect scan sent the syn packet 16 times in total!!! These are the
times packets were sent:

14:52:24.537637
14:52:27.537637
14:52:30.557637
14:52:33.537637
14:52:33.557637
14:52:36.577637
14:52:39.557637
14:52:39.577637
14:52:42.617637
14:52:45.617637
14:52:48.637637
14:52:51.617637
14:52:51.637637
14:52:54.657637
14:52:57.637637
14:52:57.657637

That's a funny retry pattern - and I bet it's caused by the combination
of the kernel retrying syn's, and nmap retrying connect calls.

I then traced a 100 port scan, each method. Both took 108 seconds. The
syn scan generated 460 packets, while connect scan generated 1180.

Looking at a full 1-65535 scan, syn-scan took 52631.048 while connect 
scan took 52623.696 seconds.

Thanks for reading all this! I'd really appreciate some feedback from
expects as to the merits of each.

Regards,

Paul

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul () westpoint ltd uk
web: www.westpoint.ltd.uk




---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).