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

[Kaj Huisman <kaj.huisman () gmail com>]

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