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

From: Kaj Huisman (kaj.huisman_at_gmail.com)
Date: 08/11/05

  • Next message: Martin Mačok: "Re: Nmap/netwag problem."
    Date: Thu, 11 Aug 2005 04:14:19 +0200
    To: Jack <jack@rapturesecurity.org>
    
    

    Jack wrote:
    > 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.
    >
    > Jack
    >

    Thanks for the good reply, I will try to explain what I meant know.
    With the results of two scans allready
    nmap -sS -P0 -T4 <host> resulting in:
    80 Filtered
    17989 Filtered
    Ports not shown closed ?
    and netwag resulting in both open,
    we need to rule out false positives first.
    If we now perform a nmap -sT on the host, if _something_ is listening
    and is unfiltered it will result in port 80 : open.
    If the port would now be reported closed that would make netwag look
    stupid, thus if the port is not reported open we assume it reports filtered.

    If _something_ is listening on the port (iow: connect() succeeds) we can
    continue our quest from there on.
    Considering the nature of the original question I would say a head /
    would suffice. (I dont think this person is scanning high profile
    devices and if he is he should not be imo because one who does should
    know this stuff already)

    If not we need to figure out what kind of scan made netwag report the
    port as open.

    Note that lots of responses in this thread assume that nmap was the one
    that reported it correct. This assumption might not be valid considering
    the fact that aggressive scanning was used and both scans were conducted
    at the same time (?), this would make the possiblity of packet loss
    somewhat higher (resulting in filtered state of the port).
    Therefor the -sT is a valid way of narrowing results (only two ports
    left so timing is not an issue, and we allready used aggressive so we
    are not concerned about any logging).

    recap:
    1: rule out wheter netwag or nmap reported falsely
    2: if port is open escalate focus on listening process on target
    3: if not open (nor closed) investigate responses (raw tcp/ip data)

    G'Day
    Kaj

    ------------------------------------------------------------------------------
    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: Martin Mačok: "Re: Nmap/netwag problem."

    Relevant Pages

    • Re: Deutsche-Telekom sets the standard for network security! (??)
      ... > that people were so hardcore on security. ... > Several of you say that you report port sniffers almost every time. ... I don't see near the hits you report. ... I have a full firewall system {OpenBSD system set up ...
      (comp.os.linux.security)
    • Re: crystal report print to file
      ... i'm not sure which report object you are using - adobe com control I assume ... I am using the .NET CrystalReports ReportDocument which does not expose ... Driver or Port properties. ...
      (microsoft.public.vb.crystal)
    • Re: NIS slowing machine to a crawl?
      ... The problem is NIS. ... Check your computer with a port scanner like grc.com in the internet. ... netstat and if its implementation is bug-free enough to report it ...
      (comp.security.misc)
    • Re: Rhapsody
      ... to authorize access to your playlist. ... would be no bandwidth usage on the server logs. ... >>of add port numbers. ... A quick report over bandwidth usage by internal ...
      (comp.security.firewalls)
    • Re: Storms destroyed 108 offshore platforms
      ... The report *is* correct if not light on the estimates. ... from sea on Oct 18th after a full month of servicing fields below Port ... offshore one needs boats and boats need ports to work out of. ... 300 oil support vessels in port..all seeking fuel and potable water. ...
      (misc.invest.stocks)