Nmap Development mailing list archives
RE: Nmap Service Detection Proposal
From: Fyodor <fyodor () insecure org>
Date: Sun, 27 Aug 2000 03:09:28 -0700 (PDT)
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).
Current thread:
- Nmap Service Detection Proposal Fyodor (Aug 27)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 27)
- RE: Nmap Service Detection Proposal Fyodor (Aug 27)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 27)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 28)
- RE: Nmap Service Detection Proposal Fyodor (Aug 27)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 27)
- <Possible follow-ups>
- Re: Nmap Service Detection Proposal Paul Tod Rieger (Aug 28)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 29)
- Re: Nmap Service Detection Proposal Fyodor (Aug 29)
- Re: Nmap Service Detection Proposal H D Moore (Aug 29)
- Re: Nmap Service Detection Proposal Paul Tod Rieger (Aug 28)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 29)
- RE: Nmap Service Detection Proposal Jay Freeman (saurik) (Aug 29)