Home page logo
/

pen-test logo Penetration Testing mailing list archives

Re: [Fwd: Re: Nmap/netwag problem.]
From: Jack <jack () rapturesecurity org>
Date: Wed, 10 Aug 2005 17:57:05 -0700

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault