From: Omar Herrera (oherrera@prodigy.net.mx)
Date: Wed Aug 10 2005 - 19:48:41 EDT
> -----Original Message-----
> 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.
>
> 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.
?
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
request).
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
results.
> 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.
>
> Aleph
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
sniffer...
Regards,
Omar Herrera
------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:44 EDT