RE: Nmap Service Detection Proposal

[Fyodor <fyodor () insecure org>]

On Sun, 27 Aug 2000, Jay Freeman (saurik) wrote:

> Unless
> there is some hope that a large number of people out there already have
> libxml, 

Actually, there may be some hope!  Look what I just found on my system:

amy~>ls -ld /usr/lib/libxml.a /usr/lib/libxmlparse.a
-rw-r--r--    1 root     root  402640 Feb  4  2000 /usr/lib/libxml.a
-rw-r--r--    1 root     root  25034  Aug 12  1999 /usr/lib/libxmlparse.a

I don't remember why I installed them (or they could have come with
Redhat).  I could ask rpm, but my point is that libxml may be more common
than we think.

> Xerces is a complete implementation of DOM and SAX and all sorts of
> other XML goodies, plugs into an XSLT container well (Xalan,

Do we need these?  Whatever they are :) ?

> I do like the idea of using XML as the base file library, as it solves all
> of the escaping issues (most, if not all, of the escaping is done by the XML
> parser).

Yeah that is nice.  And it could make future Nmap file formats easier to
parse.  But adding a required library dependancy to Nmap is not something
I take lightly.  Tough call.

> I'm going to sit down sometime tomorrow (assuming I have some time, I think
> I do... have to work on a document with my partner, but that shouldn't take
> _that_ long) think of different ways to handle the jumping issues (if we
> think its HTTP, and fail, but now know it is some other protocol, but have
> to start over again, we know what kind of connection to jump to), and ways
> of using the ports for sorting help without being locked in by them at the
> same time.

I'm not sure I understand the need to jump.  With my latest proposal, the
idea is:

1) find port XX open
2) execute the probe(s) which registered that port (possibly in parallel)
3) If the registered probes fail, execute the other tests (possibly in
   parallel) until one succeeds.

Could you give examples of cases where you think jumping would be a big
help?

> A few issues that need to be dealt with, however, are stuff like timeouts.
> Some services are just slower than others.  I noticed this while building
[ ... ]
> 4 seconds I am going to get a reply, an example (I think, was a while ago)
> was sending a HELP command to a mail server to get more accurate/further
> version information 

Well, this particular case wouldn't be neccessary if you were only looking
for service type (and not version info).  But you are probably right that
some services may take particularly long even for the initial response we
need for service-detection.  If we need it, adding an optional timeout
attribute to the probe line should not be a problem.

> Even if you were to try to give the daemon as much time as possible and go
> on to other things, the data length issue is still a problem.  In the case
> of FTP I use a 4096 byte receive buffer (< 4096) to get data because
> sometimes I couldn't get the version string until long after the initial
> connection as people were putting long connection banners on their FTP

This is another case where trying to get the version # is causing you
pain.  If you were only doing service detection, you would know by the
'^220 ' on the first line.

But your point is still very valid.  If the text we get back does not
match any of the expressions, it would be nice to know when we have
collected enough data to give up (rather than waiting for the timer to
expire).  Perhaps we should add attributes to the probe line specifying
the amount of data (in lines and/or bytes) that we have to get before we
can give up early.

Cheers,
-F


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).