Re: nmap+V

["Ryan Permeh" <Ryan () eeye com>]

Comments in the message, kinda long too:)
Signed,
Ryan
eEye Digital Security Team
http://www.eEye.com
----- Original Message -----
From: "H D Moore" <hdm () secureaustin com>
To: "Paul Tod Rieger" <prie () abl com>
Cc: <nmap-dev () insecure org>
Sent: Wednesday, August 23, 2000 11:57 PM
Subject: Re: nmap+V


> Paul Tod Rieger wrote:
> > Fyodor <fyodor () insecure org> wrote:
> >
> > > What are others doing?  Nessus has mentioned in various announcements
> > > that they detect services rather than rely on static port mapping.  Has
> > > anyone looked into their approach?  Sharing service detection
> > > mechanisms/scripts with Nessus or other scanners would be a plus.
>
> > > The syntax needs to be powerful enough to handle the vast majority of
> > > protocols.  Ideally, it could even handle binary protocols like SMB
>
> There are some issues with this, namely DoS attacks caused by the
> 'detection' packets.  An example are some wind0z3 SQL boxes that have
> port 6666 open, but if you make a connection to that port and send ASCII
> data it crashes whatever service was listening on that port.

This is due to a broken server handling by APC for handling UPS re
quests, supposedly it is fixed.  we can't really stop going forward with a
feature because some vendor makes a horribly crappy daemon that might crash
based on a normal portscan.(PS, a regular portscan will crash this port).

> Some protocols are always in a specific state based on what data they
> have already received, what probe packets do you send to determine which
> service it is, and not inadvertently set the daemon/service into a mode
> where it wont respond to the same string it would if that string was the
> first thing you sent?  If this doesnt make sense, imagine a service like
> SMTP, where sending a specific string will put it into DATA mode where
> it will accept anything.  If you send a command to determine what
> version/type this service is and change the response of the service by
> doing so (no return code after SMTP is in data mode), then your
> detection routine is self-defeating.

not certain where you are going with this. sure, some protocols are
stateful, but we could make a simple state machine to model each suspected
protocol and as soon as it deviates from that state machine it is obviously
not that protocol(or at least not that protcol as we know it from the
RFC/research).  Most protcols can be identified in less than 2 packet
interchanges or state machine shifts, many in even less(due to logical
packet layout, or banner formatting, etc)

> What will your detection packets show in the system's log files?
> Invalid requests will normally be logged (a HTTP GET request to an
> unknown RPC port?).  While I agree that nmap+V is "nifty", I think it is
> pushing nmap in a direction that would be better handled via
> scripts/plugins/etc.  Wouldn't a modularized plugin
> output/filtering/processing system make all of this a non-issue and
> allow people developing things like version and banner detection do so
> without needing to "taint" core nmap development?

i totattly agree with this in theory.  right now, nmap doesn't have a
modular design, so to acheive "modules" would require a wrapper around
nmap(as if there weren't enough of those already), or a serious rework of
the core scanning engine.  As for what remote protcol scans would look like
in the system logs, they would look like failed connections, or misformed
packlets.  i don't think this is such a big deal because it would likely be
coming up after a hellish syn storm and 8-10 tests for os detection, and if
the admin is clueful at all, they will already know that they are being
scanned.
> Most of the above doesn't apply to currently known services, but I think
> these are issues that need to be kept in mind while the infrastructure
> is still being designed.
>
> > Nessus has "bind/version" and seems to do in-depth analysis of ftp and
> > finger.
>
> <offtopic>
> Nessus is a great "blanket" tool, but I feel that some things would be
> better accomplished by other tools and integrated.  For instance, nessus
> has a plugin called nmap_wrapper which simply calls nmap and parses the
> results.  What if you already did a
> long-painful-through-a-portsentried-firewall scan and would rather
> nessus use your scan logs?  I have a rewritten wrapper which does that
> and will send a copy to anyone that wants it.  Command-line nessus usage
> with it is broken due to the nessus preferences file being rebuilt with
> default settings when run that way, but GUI scans work great.  Whisker
> should replace all of the cgi checks and SSL web/port detection/scanning
> is a place where it lacks the most.  My solution was to use native perl
> ssl modules with a modified whisker and a nessus plugin which called
> whisker...
> </offtopic>
not certain on this, i haven't used nessus at all, so i wouldn't know.
perhaps another thread on this list(the XML output one) could help this
signifiantly.  a tiny xpat(or insert your xml parser here) wrapper parsing
the nmap output could be fed into just about any xml aware system, or
wrapped so that it ends up looking like nmap generated the output itself.
in fact, XML could be used in just about all of those scenarios and parsed
when needed.  just a thought, take it how you may.

> > As for version scanning with nmap, I'd like to see banner scanning as
well.
> > The regexp parsing leaves out too much information for me.  For
instance, I
> > not only want to know what version of Sendmail is running but also the
> > hostname and the date; not only what version of Apache is running but
also
> > where the root document is (another machine?), when was it last
modified,
> > and what exactly is that spammer trying to sell me.  :-)
>
> A 40Mb spam-correlating, linguistic-analyzing, banner-detecting nmap....

I  100% agree with the whole banner output idea.  we have code to do this
that we are toying with integrating into a patch.  if you want to regex your
output at a later date, you can, but a tight regex can miss important peices
of information, and if it is a hardcoded regex, it's not possible to go back
and get that information from a stored file.  use regexes in reporting
engines to smooth it out, not in data gathering tools.  (Just my opinion of
course:)
> > (For my requirements, maybe rain.forest.puppy's "nmap stubs" in Perl
would
> > automate nmap (-O, -I, -sR), ftp, binfo, finger, and telnet 80 for me,
but
> > the http://www.angio.net/security/rfp link on
http://www.insecure.org/nmap/
> > doesn't seem to work....)
>
> http://www.wiretrip.net/rfp/
>
> -HD
>
>
> PS.  I apologize for the ramble, sleep deprivation doing it's worst...
>
>
> http://www.digitaloffense.net/ (tools site)
>
> ---------------------------------------------------------------------
> 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).


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