Re: Nmap/netwag problem.

[Pete Herzog <lists () isecom org>]

Rogan,

> Excuse me? Are you suggesting that if I send a Syn to port 80, and don't
> get a Syn/Ack back, I should just go ahead and send a "GET / HTTP/1.0",
> in case there is some kind of application level firewall that will only
> pass my original Syn if it sees a valid HTTP request following it?

Sorry if my post was confusing.  I'm saying that a complete handshake is
not the most reliable way to test for a service.  The matter in question
was what the most reliable way to test further is.  I'm not saying it
should always be done for efficiency sakes, but in matters of
discrepency as per the original post, going further to just look for the
handshake and not send proper data is unreliable.

> Sounds like someone is redefining TCP, to me!

This is about analyzing it and not redefining it. I just would like to
point out that to determine a service on a port it is not enough just to
complete a full TCP hand-shake and Telnet to it if there is a response.

> I can't imagine any TCP/IP implementation (bar Microsoft, of course!)
> that would be so braindead, and would actually do anything further if
> the Syn/Ack was never received.

But the situation it does exist and not just do to the host or a device.
 It's a common phenomenon that the tester does not receive the SYN/ACK
for any number of reasons (like not waiting long enough for it) but the
service is still there.

In addition to that are devices that complete the TCP handshake.  I have
tested where proxy caches used by large ISPs return full TCP handshakes
on port 80 even if the host does not have a service available on that
port.  If the host does have a web port available and you use Telnet to
connect to it then you will not get a banner (service reply) as the
proxy cache will not respond and the host will never see it. The
original poster did say port 80 is one of the ports in question.  So he
needs to verify this through TTLs, sending data properly, etc. where a
TCP full-connect alone is worthless.

> At the very least, once the full TCP connect scan has identified that
> there IS a service running on a particular port, you can then try to
> identify the service by prodding it with various protocols, and seeing
> which respond. I certainly agree with your statement that many services
> do not respond with layer 4 (?) protocol data, if the input is not
> well-formed.

Again, my point is on the more reliable way.  Kaj said in his post to do
a full connect scan and Telnet to it.  That alone is sometimes not
enough to be considered the most reliable as you also concur here.  If
there is a proxy cache then it may be telling the tester that port 80 is
open due to a SYN/ACK but there really is no service on the host.
Looking at the TTLs of the returned packets is quick way to verify this
but not definitive.

> But the original statement was with regards to identifying that a (ANY)
> service is actually listening on a particular port. And I tend to agree
> that a full connect scan is more reliable than a Syn scan.

Yes, I never disputed this. A full connect scan will improve the results
however it is still not the most reliable as it will not say whether
there is a service- just that the packets to that port are being
responded to.

I think the trade off between efficiency and reliability never came to
question here.  The scan was done, discrepencies occurred, and the
poster didn't know why.  To just do a full connect scan on those ports
to search for services is only the next step.  But it's not finished, as
even you stated above.  This shows that a full connect scan is not the
most reliable, only more reliable than a SYN scan.

I hope this clears up any misconceptions from my original reply.  Sorry
for any confusion.

Sincerely,
-pete.

-- 
Pete Herzog - Managing Director - pete () isecom org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.isestorm.org

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