Re: [Fwd: Re: Nmap/netwag problem.]

[Omar Herrera <oherrera () prodigy net mx>]

----- Mensaje original -----
De: Jack <jack () rapturesecurity org>
Fecha: Miércoles, Agosto 10, 2005 7:57 pm
 
> > Uhm, before _any_ data gets sent a full tcp handshake has takes 
> place.> Thus a full connect scan will reliably report a port open 
> if it is.You
> > From the nmap man:
> >     If the port is listening, connect() will succeed, otherwise the 
>                       port
> > isn't reachable.
>
> There are a lot of devices that do a 3way handshake on behalf of a 
> device, lots of DDoS protection
> devices, devices seen on high latency/lossy networks, etc. a syn 
> scan will just show you that
> something is there (or perhaps it wont, if you use nmap (-sS), 
> with its predictable tcp signature, it
> may just drop the packet). 

I agree with this statement and I also agree with Pete, when he states that more has to be done to accurately identify 
services on open ports, but first you need to see if you have access to these services (i.e. if the port is open). 

However, whether the response comes really from the machine you are scanning or from a filtering device in the middle, 
doesn't has anything to do with the reliability of full connect port scans. The tools do just what they were intended 
to do (with the options discussed in the original post): report the port as open, closed or filtered.

You can always test further (enumeration, manual testing, etc.) at later stages; once you have finished your port scan, 
and focusing only on services you can access (open).

> If you fail to send valid tcp data, then you wont get any data 
> back, so you wont be able to see any difference,
> making your scan useless. Sometimes you can see subtle variations 
> inside the tcp packets coming as `open' and
> `fake-open' (ttls, timestamps, options, blah blah blah) ports 
> (after the handshake generally) that give away what
> ones are fake without sending data, YMMV. i would say that doing a 
> full 3 way handshake (with retransmissions)
> and trying to send data (or not if you get a banner back right 
> away) is one of the only ways to cope with modern
> networks.

I agree as well with all arguments you post here, but help me clarify some things:

Are you proposing to mix port scanning and enumeration on a single stage (i.e. detect if a port is open or colesd, and 
if open, identify the running services, protocols and all that before going on with the next por on the list)? I don't 
say this would be bad; a different paradigm at least. However, I'm not sure I would rely on this approach, it might be 
just too time consuming and extremely difficult to estimate the time it will take at the planning stage of the 
engagement.

Second question: are you proposing to do all this extensive research for each port shown as closed or filtered by a 
mere full-connect scan, just because, maybe, there is some way to get around? I think not. probably just in cases like 
this, where a second round of port scanning yields different results by using a different tool, but even here (pending 
what Aleph has to say after hearing suggestions from this forum) I think that the problem will be much easier to detect 
with less effort (probably it was just the timing issue, after all).

I would just like to stress (again) that, when you are with tight time restrictions during a pentest (which one 
doesn’t), even if we all of us would love to do such extensive testing as you have here, in practice you just can’t do 
that without the risk of not finishing on time (with a proper and complete assessment). 

I think that Aleph 1 (bis) did what was most reasonable here: double checked with a different tool. Planning and 
scheduling another port scan (including it in the project scope),  seems also more reasonable to me than planning 
possible full reviews of God-knows-how- many services (definitely, not for every port in every IP address you would 
test). 

In short, I would still rely first on the results of a full-connect scan (double checked with another scan/tool, yes), 
and then, proceed with a more thorough test of  those services and devices behind ports reported as open by the port 
scanner(s). 

Cheers,
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
-------------------------------------------------------------------------------