Mailing List Archive: Service identification

Service identification

mikhail at nessus

Apr 16, 2004, 4:07 AM

Post #1 of 6 (2664 views)

I planned to change the current way find_service & Co works.
My reason for this are:
- Many services are identified by find_service.nes, which is a C
plugin and is not updated by nessus-update-plugins; so many users
have to wait for the next release.
- too slow
- too intrusive
- unreliable on services like FTP, NNTP or even SMTP which all use a 3
digit code to answer to queries.
[any other problem?]

The modifications I planned:
- first open a plain TCP connection (no SSL/TLS) and try to read a
banner without sending anything. If we get a banner, store it and test
next port. Wrapper services are identified at this point.
- Try SSL/TLS connections (if asked), then plain connection. Register
the "transport" (as we do currently)
Try to read a banner. If this works, register it, otherwise, register
the service as "Mute".
[.so far, this is slower than the current behaviour. Maybe we should
still send the GET request?]

One or two other NASL plugins will be in charge of sending "HELP /
HTTP/1.0" or "HELP" on "mute" services.

One NASL plugin will parse the banners and decide if the service can
be identified or if more information is needed. e.g. anything that
answers with something like 3 digits followed by a space or a minus
sign might be a FTP service, NNTP, SMTP etc. Requests like EHLO or
HELP should avoid false identifications.

This way, new services are added only in NASL plugins.

Any comments?

--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/

Re: Service identification [ In reply to ]

scheidell at secnap

Apr 16, 2004, 4:12 AM

Post #2 of 6 (2581 views)

> [.so far, this is slower than the current behaviour. Maybe we should
> still send the GET request?]
>
> One or two other NASL plugins will be in charge of sending "HELP /
> HTTP/1.0" or "HELP" on "mute" services.
>
> One NASL plugin will parse the banners and decide if the service can
> be identified or if more information is needed. e.g. anything that
> answers with something like 3 digits followed by a space or a minus
> sign might be a FTP service, NNTP, SMTP etc. Requests like EHLO or
> HELP should avoid false identifications.
don't forget to ignore 'printers' if asked to.
don't want 120 printers to all say 'help' on the first page on every
nessus run.!~

--
Michael Scheidell
SECNAP Network Security Corporation
Main: 561-368-9561 / www.secnap.com
We are expanding and need security professionals
http://www.secnap.com/careers/

Re: Service identification [ In reply to ]

mikhail at nessus

Apr 16, 2004, 4:39 AM

Post #3 of 6 (2583 views)

Michael Scheidell <scheidell@secnap.net> writes:

> don't forget to ignore 'printers' if asked to.

Don't worry. dont_scan_printers.nasl is declared as "ACT_SETTINGS"; so
it runs before find_service and other similar scripts
(ACT_GATHER_INFO)

Re: Service identification [ In reply to ]

lionel.cons at cern

Apr 20, 2004, 8:17 AM

Post #4 of 6 (2583 views)

Michel Arboi <mikhail@nessus.org> writes:
>
> Any comments?

Why not using the results of "nmap -sV"?
It's a pity to duplicate the code finding network services...

__________________________________________________________
Lionel Cons http://cern.ch/lionel.cons
CERN http://www.cern.ch

The sooner you fall behind, the more time you'll have to catch up.

Re: Service identification [ In reply to ]

mikhail at nessus

Apr 20, 2004, 8:30 AM

Post #5 of 6 (2583 views)

Lionel CONS <lionel.cons@cern.ch> writes:

> Why not using the results of "nmap -sV"?

For many reasons. The main one being that I don't believe in the
technique used by nmap -sV. This does not mean that we will never use
the output of nmap (I planned to rewrite the plugin as a NASL "trusted
plugin"), anyway we will always have out own code.

> It's a pity to duplicate the code finding network services...

The code is not duplicated, it is different.

Re: Service identification [ In reply to ]

rrich at gstisecurity

Apr 20, 2004, 9:02 AM

Post #6 of 6 (2585 views)

I say go for it. Nmap's approach is fairly effective, but we won't know
if it could be better without someone putting in the effort to try it a
different way. As part of Nessus, whatever you put together will
certainly get its share of use.

From my admittedly user-centric perspective, i'd toss out a few pennies
of thought.

- nmaps service database is probably nearly as valuable as the code
itself...might be a good idea to see if any of the information contained
therein is usable in an alternate approach and start off with a fairly
big database

- my biggest beef with the nmap service output is that it is just a
single string...i like the vendor/product/release/misc (patch level,
whatever)...it's not always easy to categorize products, but being able
to roll up stuff by vendor or whatever is nice

- one of the things that helps nmap's database grow is the fingerprint
output when a service has not been successfully identified... some
ability for end users to upload a copy of the fingerprint with a
positive ID of the service would ensure the list stays up to date

Were you planning on building it in nasl or C?

Michel Arboi wrote:

>Lionel CONS <lionel.cons@cern.ch> writes:
>
>
>
>>Why not using the results of "nmap -sV"?
>>
>>
>
>For many reasons. The main one being that I don't believe in the
>technique used by nmap -sV. This does not mean that we will never use
>the output of nmap (I planned to rewrite the plugin as a NASL "trusted
>plugin"), anyway we will always have out own code.
>
>
>
>
>>It's a pity to duplicate the code finding network services...
>>
>>
>
>The code is not duplicated, it is different.
>_______________________________________________
>Nessus-devel mailing list
>Nessus-devel@list.nessus.org
>http://mail.nessus.org/mailman/listinfo/nessus-devel
>
>