Penetration Testing mailing list archives
Re: Nmap/netwag problem.
From: Bill Weiss <houdini+pen-test () clanspum net>
Date: Wed, 10 Aug 2005 21:29:44 +0000
Pete Herzog(lists () isecom org)@Wed, Aug 10, 2005 at 09:10:06PM +0200:
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.
How does that work? Before you send a request of any type, your connect() will have succeeded. There is the possibility of the other side blocking you for later port attempts, but that port has to work if it's a running service. I suppose that the "security defensive process" could accept your connection and check for a proper request before passing it on to the internal service, but that would result in false-positives, not false-negatives as "you will not see a service behind the web port" implies. A connect() scan, barring any automatic blocking on the remote side, will always be the most accurate as to what is accessable from where you're scanning from. The reason all the other scan types exist is either: 1. To evade detection (connect() is noisy, leaves lots of logs) 2. To evade firewalls I quote nmap's man page: " TCP connect() scan: This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn't reachable. One strong advantage to this technique is that you don't need any special privileges. Any user on most UNIX boxes is free to use this call. This sort of scan is easily detectable as target host logs will show a bunch of connection and error messages for the services which accept() the connection just to have it immediately shutdown. " -- Bill Weiss ------------------------------------------------------------------------------ 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:
- Nmap/netwag problem. Aleph One (Aug 09)
- Re: Nmap/netwag problem. James Riden (Aug 10)
- 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)
- <Possible follow-ups>
- RE: Nmap/netwag problem. Drage, Nick (Aug 10)