Penetration Testing mailing list archives
RE: Nmap/netwag problem.
From: Omar Herrera <oherrera () prodigy net mx>
Date: Wed, 10 Aug 2005 18:48:41 -0500
-----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 -------------------------------------------------------------------------------
Current thread:
- RE: Nmap/netwag problem., (continued)
- RE: Nmap/netwag problem. Irene Abezgauz (Aug 10)
- Re: Nmap/netwag problem. Kaj Huisman (Aug 10)
- Re: Nmap/netwag problem. Pete Herzog (Aug 10)
- Re: Nmap/netwag problem. Bill Weiss (Aug 11)
- Re: Nmap/netwag problem. Kaj Huisman (Aug 11)
- Re: Nmap/netwag problem. Rogan Dawes (Aug 11)
- Re: Nmap/netwag problem. Pete Herzog (Aug 11)
- Re: Nmap/netwag problem. Irene Abezgauz (Aug 11)
- Re: Nmap/netwag problem. Daniel Miessler (Aug 12)
- Re: Nmap/netwag problem. Pete Herzog (Aug 12)
- Re: Nmap/netwag problem. Pete Herzog (Aug 10)
- RE: Nmap/netwag problem. Omar Herrera (Aug 11)
- RE: Nmap/netwag problem. Irene Abezgauz (Aug 11)
- Re: Nmap/netwag problem. Kaj Huisman (Aug 12)
- Re: Nmap/netwag problem. Fyodor (Aug 12)