Re: [Fwd: Re: Nmap/netwag problem.]

From: Jack (jack_at_rapturesecurity.org)
Date: 08/11/05

  • Next message: Rogan Dawes: "Re: Nmap/netwag problem." 
    Date: Wed, 10 Aug 2005 17:57:05 -0700
To: Pete Herzog <lists@isecom.org>

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

  • Next message: Rogan Dawes: "Re: Nmap/netwag problem."

    Relevant Pages

    • Re: [opensuse] SuseFirewall IPv4 vs IPv6
      ... # network security threats. ... # Opening ports for LAN services in the external zone defeats the ... # this setting only works for packets destined for the local machine. ... # If the protocol is icmp then port is interpreted as icmp type ...
      (SuSE)
    • Re: Ports capable of multiple simultaneous connections?
      ... The port number is only one of several attributes used to identify the ... IP passes incoming packets to TCP, ... fields in order to dispatch incoming packets to the right destination. ... A "connection" for a typical ServerSocket might look like this: ...
      (comp.lang.java.programmer)
    • Re: Fee Based Email (From Re: Processs PreciseMail AntiSpam...)
      ... >> SMTP server software should be able to log what it did. ... >see the packet that accepts the connection. ... If there are packets to port 25 that have the sync bit set you may count them. ...
      (comp.os.vms)
    • Re: Fee Based Email (From Re: Processs PreciseMail AntiSpam...)
      ... >> SMTP server software should be able to log what it did. ... >see the packet that accepts the connection. ... If there are packets to port 25 that have the sync bit set you may count them. ...
      (comp.os.vms)
    • Re: security newbie - /var/log/messages scans
      ... SPT DST:DPT frq. ... Looks high rate packets above 11 packets per second. ... address 10.30.101.0/24 port 80|85. ... I guess TCP RST flag was set and initial TTL was 255. ...
      (comp.os.linux.security)