Home page logo

pen-test logo Penetration Testing mailing list archives

Re: [Fwd: Re: Nmap/netwag problem.]
From: Kaj Huisman <kaj.huisman () gmail com>
Date: Thu, 11 Aug 2005 04:14:19 +0200

Jack wrote:
On Thu, 11 Aug 2005 00:22:43 +0200

Pete Herzog <lists () isecom org> wrote:


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.


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

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)


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:


  By Date           By Thread  

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