From: Jack (jack@rapturesecurity.org)
Date: Wed Aug 10 2005 - 20:57:05 EDT
On Thu, 11 Aug 2005 00:22:43 +0200
Pete Herzog <lists@isecom.org> wrote:
> > Kaj,
> >
> >
> >>Anyway. a 'full connect' scan (one that performs the complete three-way
> >>handshake will _always_ (?) be the most reliable.
> >>My sugeestion is to perform either a nmap connect scan on the ports from
> >>both results or to manually telnet to the ports and see the response.
> >
> >
> > I have to disagree with you here. A full connect scan is not the most
> > reliable. There are many security defensive processes now which require
> > proper protocol queries to provide a response- I see this very often
> > with web ports. If you send anything other than a http request, you
> > will not see a service behind the web port.
>
> Uhm, before _any_ data gets sent a full tcp handshake has takes place.
> Thus a full connect scan will reliably report a port open if it is.You
> From the nmap man:
> If the port is listening, connect() will succeed, otherwise the port
> isn't reachable.
>
There are a lot of devices that do a 3way handshake on behalf of a device, lots of DDoS protection
devices, devices seen on high latency/lossy networks, etc. a syn scan will just show you that
something is there (or perhaps it wont, if you use nmap (-sS), with its predictable tcp signature, it
may just drop the packet). Tcp sockets generally retransmit (configurable but i want to say 3
to 7 times as a guess) the syn packet before giving up. here is some data.
$ telnet Y.Y.Y.Y 6767
Trying Y.Y.Y.Y...
telnet: connect to address Y.Y.Y.Y: Connection timed out
16:49:01.561861 IP X.X.X.X.49418 > Y.Y.Y.Y.6767: S 3402173335:3402173335(0) win 5840 <mss 1460,sackOK,timestamp 603323243 0,nop,wscale 2>
16:49:04.559560 IP X.X.X.X.49418 > Y.Y.Y.Y.6767: S 3402173335:3402173335(0) win 5840 <mss 1460,sackOK,timestamp 603326243 0,nop,wscale 2>
16:49:10.556772 IP X.X.X.X.49418 > Y.Y.Y.Y.6767: S 3402173335:3402173335(0) win 5840 <mss 1460,sackOK,timestamp 603332243 0,nop,wscale 2>
16:49:22.562504 IP X.X.X.X.49418 > Y.Y.Y.Y.6767: S 3402173335:3402173335(0) win 5840 <mss 1460,sackOK,timestamp 603344243 0,nop,wscale 2>
16:49:46.573175 IP X.X.X.X.49418 > Y.Y.Y.Y.6767: S 3402173335:3402173335(0) win 5840 <mss 1460,sackOK,timestamp 603368243 0,nop,wscale 2>
16:50:34.581894 IP X.X.X.X.49418 > Y.Y.Y.Y.6767: S 3402173335:3402173335(0) win 5840 <mss 1460,sackOK,timestamp 603416243 0,nop,wscale 2>
$ nmap -p 6767 Y.Y.Y.Y
Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-08-10 17:05 PDT
Interesting ports on HOSTNAME (Y.Y.Y.Y):
PORT STATE SERVICE
6767/tcp filtered unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 18.536 seconds
16:58:59.410732 IP X.X.X.X.35423 > Y.Y.Y.Y.6767: S 4039998975:4039998975(0) win 5840 <mss 1460,sackOK,timestamp 603920920 0,nop,wscale 2>
16:59:02.259431 IP X.X.X.X.35424 > Y.Y.Y.Y.6767: S 4039646320:4039646320(0) win 5840 <mss 1460,sackOK,timestamp 603923763 0,nop,wscale 2>
# nmap -sS -p 6767 Y.Y.Y.Y
Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-08-10 17:08 PDT
Interesting ports on HOSTNAME (Y.Y.Y.Y):
PORT STATE SERVICE
6767/tcp filtered unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 0.639 seconds
17:01:55.257716 IP X.X.X.X.37113 > Y.Y.Y.Y.6767: S 4154350949:4154350949(0) win 3072
17:01:55.457732 IP X.X.X.X.37114 > Y.Y.Y.Y.6767: S 4154416484:4154416484(0) win 3072
Now you can see that nmaps `connect' mode is not quite the same as a generic (ie without setsockopt) socket
it only retransmits 2 times, and worse so in syn scan mode, the backoff timer is missing ;] of course
most port scanners have options for these sorts of things, to increase reliability of data, these settings are
critical to testers, who sometimes have networks with loss. if the idea is to guard against syn packet drops,
in that case a generic socket seems the best way to do it. unicornscan can deal with this too, but not
if you are only scanning a small network, its retransmission is more of a repeat, so if you are scanning 1 host
and as for 2 repeats (with one port) it will send to packets at whatever pps rate you asked it for so youll end up
with this:
(not ideal, clearly)
# unicornscan -Iv -R 2 Y.Y.Y.Y/32:6767
Adding Y.Y.Y.Y/ffffffff (Y.Y.Y.Y -> Y.Y.Y.Y) mode `TCPscan' ports `6767'
Scaning 1 total Hosts at 300 pps with 2 total packets, should take a little longer than 7 Seconds
average `295.95' [2 0.01] packets per second at end of run
Packets recieved: 2 Packets Dropped: 0 Interface Drops: 0
17:21:34.805421 IP X.X.X.X.22483 > Y.Y.Y.Y.6767: S 2850949798:2850949798(0) win 16384 <mss 1436,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 447140369 0>
17:21:34.815090 IP X.X.X.X.45259 > Y.Y.Y.Y.6767: S 2851007934:2851007934(0) win 16384 <mss 1436,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 447140369 0>
with a larger amount of things to scan, its better
# unicornscan -Iv -R 2 Y.Y.Y.Y/32:q
Adding Y.Y.Y.Y/ffffffff (Y.Y.Y.Y -> Y.Y.Y.Y) mode `TCPscan' ports `7,9,11,13,18,19,21-23,25,37,39,42,49,50,53,65,67-70,79-81,88,98,100,105-107,109-111, ...
Scaning 1 total Hosts at 300 pps with 670 total packets, should take a little longer than 9 Seconds
Added Y.Y.Y.Y port 113 ttl 226
Added Y.Y.Y.Y port 80 ttl 226
Added Y.Y.Y.Y port 22 ttl 226
average `287.11' [670 2.33] packets per second at end of run
Open ssh[ 22] From Y.Y.Y.Y ttl 226
Open http[ 80] From Y.Y.Y.Y ttl 226
Open ident[ 113] From Y.Y.Y.Y ttl 226
Packets recieved: 22 Packets Dropped: 0 Interface Drops: 0
17:24:08.885957 IP X.X.X.X.25401 > Y.Y.Y.Y.4321: S 3841188318:3841188318(0) win 16384 <mss 1436,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3786731697 0>
17:24:10.044980 IP X.X.X.X.11373 > Y.Y.Y.Y.4321: S 3841185962:3841185962(0) win 16384 <mss 1436,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3786731697 0>
If your saying that some devices (toplayer?) require tcp data, yes, i have seen this too, youll need
to have your scanner send a valid payload into this device, like so:
# unicornscan -Iv -msf Y.Y.Y.Y/32:78,79,80,81,82
Adding X.X.X.X/ffffffff (X.X.X.X -> X.X.X.X) mode `TCPscan' ports `78,79,80,81,82'
Scaning 1 total Hosts at 300 pps with 5 total packets, should take a little long er than 7 Seconds
connected X.X.X.76:45008 -> X.X.X.X:82
Added X.X.X.X port 82 ttl 248
connected X.X.X.76:35423 -> X.X.X.X:80
Added X.X.X.X port 80 ttl 248
connected X.X.X.76:53339 -> X.X.X.X:79
Added X.X.X.X port 79 ttl 248
connected X.X.X.76:14724 -> X.X.X.X:78
Added X.X.X.X port 78 ttl 248
connected X.X.X.76:43069 -> X.X.X.X:81
Added X.X.X.X port 81 ttl 248
Main [DEBUG connect.c:701] 1 connections left hanging
TCP STATS:
Connect related TCP Segments sent: 17
Stream Reassembly aborted due to damaged tcp segment: 0
Stream death due to remote reset: 4
TCP Segments to a Closed socket: 5
TCP Segments out of window: 4
TCP Segments with data truncated that went past window: 0
TCP Seqments recieved out of order: 0
Connections Established: 5
TCP Triggers sent: 5
TCP Dynamic Triggers sent: 1
TCP segments to non-existant sockets: 0
Open vettcp[ 78] From X.X.X.X ttl 248
Open finger[ 79] From X.X.X.X ttl 248
Open http[ 80] From X.X.X.X ttl 248 Banner `HTTP/1.0 403 ForbiddenServer: XXXXXXXXXXXMime-Version: 1.0Date: Thu, 11 Aug 2005 00:37:14 GMTContent-Type: text/htmlContent-Length: 149Expires: Thu, 11 Aug 2005 00:37:14 GMTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Open hosts2-ns[ 81] From X.X.X.X ttl 248
Open xfer[ 82] From X.X.X.X ttl 248
If you fail to send valid tcp data, then you wont get any data back, so you wont be able to see any difference,
making your scan useless. Sometimes you can see subtle variations inside the tcp packets coming as `open' and
`fake-open' (ttls, timestamps, options, blah blah blah) ports (after the handshake generally) that give away what
ones are fake without sending data, YMMV. i would say that doing a full 3 way handshake (with retransmissions)
and trying to send data (or not if you get a banner back right away) is one of the only ways to cope with modern
networks.
Jack
------------------------------------------------------------------------------
FREE WHITE PAPER - Wireless LAN Security: What Hackers Know That You Don't
Learn the hacker's secrets that compromise wireless LANs. Secure your
WLAN by understanding these threats, available hacking tools and proven
countermeasures. Defend your WLAN against man-in-the-Middle attacks and
session hijacking, denial-of-service, rogue access points, identity
thefts and MAC spoofing. Request your complimentary white paper at:
http://www.securityfocus.com/sponsor/AirDefense_pen-test_050801
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:44 EDT