Home page logo

pen-test logo Penetration Testing mailing list archives

Re: Nmap/netwag problem.
From: Kaj Huisman <kaj.huisman () gmail com>
Date: Thu, 11 Aug 2005 19:02:21 +0200

Paul J Docherty wrote:
Whilst the points you are making are correct once you have discovered
open ports, I think you have raced ahead of the question, which was I
think, "which port scanner is giving the correct results?" As many
others have elegantly answered use a packet sniffer and look at the raw
data to see what's going on.

I dont need to use any sniffer to _see_ what happens in the following three states it might report. (nmap -sT <host>) 80: OPEN Here the following sequence took place syn_to_server->_syn_ack_response_from_server->ack_to server
(iow full connection).
If it succeeds you _will_ have a point of entry.
Then you move on to find out what the possibilities of the point of entry (or service) are. You might (at this stage) continue with scanning (version scan, different scanners, sniffers loaded. all valid points) but you will have allready the knowledge that you _are_ indeed able to connect(); to the port.
80: CLOSED      Here something like:
syn_to_server->no_service_here_from_server EOT *
Note that the dumps posted earlier show _filtered ports.
On a closed port it is unlikely that an aplication will send a sequence of syns, if it gets the 'port_not_reachable' it will stop (telnet would give you a 'connection refused' on a closed port, not a timeout(filtered port).

*One poster validly pointed out that a closed port can send out different responses (depending on stack implement) thus the results CLOSED is not 100%. OPEN = 100 % reliable and a definite elevation.

80: FILTERED    Any other case, would require more investigation.

If it is filtered then all the replies about using <name tool> are valid (good replies). If the -sT replies with either *closed or open then you have a certainty, something that needs to be written into the rapport and more closely investigated, but you _will_ have this certainty.

* see above

There is no use in using any tool at all if you cannot filter out the results

Time is an issue in most pen-tests. I will now hypotheticly recreate the situation:

Boss "dude, perform a blackbox test on that machine"
nmap -sS -vv -P0 -O -oN logfile.nmap x.x.x.x & netwag blah logile.nwox x.x.x.x &
interesting ports on [..]
80 Filtered
1723 Filtered
Other ports are closed  // <-- *note assumption
OSGuess: unreliable
80 Open
1723 Open
Other : ?? // closed ?

* the assumption is valid since if the ports were filtered they would be listed and if they would all be reported open,... well.

// Note that a firm (or proper) pen-test at this point allready has the sniffer/dumper running (imo atleast).

Based on the above results alone I extract the hypothesis that the machine is some midrange business server, since the reports (wheter filtered or open) report the well-known port numbers of a webserver (80) and Point to Point tunneling protocol (1723). Making a note of that allready. We have different results so we need to weed them out here, most reliable way to confirm wheter the port is open or not is to perform a full-connect on the port. So we do. We could use a little handcrafted c code that will :
/* side note here, if you dont wrap connect within a alarm_timer(); here , your app will try to connect untill infinity and will never reach the the 'connection timed out' status */

But why go trough all the hassle when nmap (and most other scanners) allready have the ability to do a 'void' connect ability built in.
nmap -sT -p 80,1723 -vv x.x.x.x
80 Open
1723 Open
nmap -sT -vv -sV -O -p 80,6767
80 Open Apache 1.3.26
6767 Closed // Assumption with above explained logic
OsGuess: Red_Hat linux, kernel 2.x.x
Uptime: xdays,xminutes
We want to be sure so we will use _every_ other tool in out toolkit to verify this as well as with manual inspection of packets and grabbing of banners (which is the least reliable).
Then we fire up metasploit and gain a shell, from here on blah.. blah..
[Report box as vulnerable and move on from there (depending on the clients need)]
(I know, this is a bit shortcutted, for explanatory purposes)

Note that the above sketched situtation is _invalid_ if the -sT reports the port as closed (which we should write down as a *confirmed closed which may later on in the process be used to bind a shell on perhaps).
If report is filtered, _then_ the whole other chain of events steps in.

* see above point

All other scantypes (excluding -sS which send back a syn_rst after the syn_ack_from_server (preventing the server from logging a full connection), and is therefore evenly reliable with -sT) rely on protocol definitions vs vendor implemantations. Windows TCP stack functions different as Linux' TCP stack, most scanners rely on guessability for any other scan type, makeing them all sortof questionable (allthough some tools are really good at guessing).

Thus indeed, if the port is filtered you would need to go more low level, try FIN packets or Fragmented packets, perhaps a sombie scan to find out if there is a trust relation with some other box somewhere else on the net. My point was that you should not make something more difficult then it is.

I hope this clears some confusion.


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 ]