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 -------------------------------------------------------------------------------
Current thread:
- Re: [Fwd: Re: Nmap/netwag problem.] Jack (Aug 11)
- Re: [Fwd: Re: Nmap/netwag problem.] Kaj Huisman (Aug 11)
- <Possible follow-ups>
- Re: [Fwd: Re: Nmap/netwag problem.] Omar Herrera (Aug 12)