mailing list archives
RE: Nmap/netwag problem.
From: Omar Herrera <oherrera () prodigy net mx>
Date: Wed, 10 Aug 2005 18:48:41 -0500
From: Pete Herzog [mailto:lists () isecom org]
Sent: Wednesday, August 10, 2005 2:10 PM
To: Kaj Huisman
Cc: Aleph One; pen-test () securityfocus com; Security-Basics
Subject: Re: Nmap/netwag problem.
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.
Before dealing with the specific protocol at higher levels, unless it is not
tcp based, you still need to perform a complete 3-way-handshake. From the
discussion the problem seems to be: why does one tool reports all ports 80,
1723 as filtered (nmap) and another tool (netwag) reports them as open? And
not whether this or that protocol is running on these services. If it is web
based, a 3-way-handshake must take place before anything else (i.e. any http
Just to see whether a certain port is visible from the outside (which
ultimately means that you will be able to connect to it to fingerprint the
service, analyze vulnerabilities, etc.) the connection to the socket must be
established. For this reason, I agree with Kaj here, a full connect scan
should be the most reliable among all TCP scans available.
Back to the original post:
I faced a problem running two tools producing totally different
What i did is described as ...I ran nmap on a IP with these parameters
: syn scan,dont ping,very verbose ,aggressive scan..it showed ports 80
n 1723 filtered.I ran this scan from Linux box.
Same time ,i used netwag to scansame ip which showed these ports open.
What can be the problem..??please help.
Syn scan (half scan) should work here as well here, my guesses:
a) Aggressive setting (-T4) might not be slow enough for the response, this
setting has a default max_rtt_timeout = 1250ms. Testing with the default -T3
(max_rtt_timeout = 10sec) should be enough if this is the problem.
b) There is indeed a filtering device detecting the scan and blocking
answers. Since there are 2 tools here, one reporting it as filtered (which
means no response at all, so a filtering device or a timeout sounds logical)
and another reporting the port as open, It could be that timing, again is
messing with the results. For nmap's aggressive scan, there is no default
scan delay, with a max. scan delay of 10ms; also, the scan is performed in
parallel (I think the default was 36 sockets in parallel). If this is the
case, nmap might be to fast with this option, producing a block in the
filtering device while netwag, with the options you run it with, might be
slow enough to pass undetected.
c) Less likely, but could be, there is something (a pattern) within the
initial SYN sent by nmap's syn scan that triggers a filter device. See:
http://www.sans.org/resources/idfaq/nmap.php, I'm not sure about the status
with the latest version of nmap
In any case, to be sure, my suggestion would be:
1) make sure to change your IP address
2) execute a complete scan just on port 80 (use also -P0)
3) wait a few seconds and also execute the complete scan with the other port
This really should avoid any timing problems and filters. If it still shows
it as filtered, then do it the old way (you might want to try it right
away): as others already suggested, run the scan with both tools with a
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:
Re: Nmap/netwag problem. Martin Mačok (Aug 11)
Re: Nmap/netwag problem. Josh Zlatin-Amishav (Aug 10)
RE: Nmap/netwag problem. Drage, Nick (Aug 10)
Re: Nmap/netwag problem. eliudgarcia (Aug 10)
RE: Nmap/netwag problem. laurent . constantin (Aug 11)
RE: Nmap/netwag problem. Paul J Docherty (Aug 11)
RE: Nmap/netwag problem. ankush.kapoor (Aug 12)
- RE: Nmap/netwag problem., (continued)
- RE: Nmap/netwag problem. Omar Herrera (Aug 11)