[Openvas-devel] Get rid of old services concept

Thomas Reinke lists at securityspace.com
Mon Sep 7 20:58:45 CEST 2009

Jan-Oliver Wagner wrote:
> Hi,
> I looked at the code/concept we inherited from Nessus
> regarding services handling (modules openvas-libraries/misc/services*).
> To me it looks like multiple broken concept.
> What I understand so far is:
> * /etc/services is used through the standard glibc API
> * in openvas-server there is a  openvas-services file
>    that may work as an alternative to the system wide
>    file.
> * nmap knows even more about services.
> What's broken?
> (I might be wrong here, so please comment, discuss)
> * My guess is that the nessus authors believed
>    the system wide file is not always enough up-to-date.
>    With their own file they unlink dependency to OS version
>    and introduce dependency link to Scanner version.

As far as I can see, the daemon does a fallback to glibc linked
to /etc/services - it's just that first dibs are given to the
daemon's version of the services file, and only if the name cannot
be found does it fall back to glibc use of /etc/services.

>    This leads to the problem that in several cases, people
>    may use even older services data because they use
>    an old scanner on a new OS.
>    They might also have had the intention to make
>    the scanner run on Windows eventually.
> * It is questionalbel whether it makes sense at all
>    to maintain services database on out own at all.
>    In case we would do it, the only sensible way
>    is to distribute it over the feed so it is always
>    uptodate.
> * What we might really want is to share effords
>    with the nmap people. Distributuing the newes
>    data via the feed remains still an option here.
> What to do?
> IMHO, we should drop the whole services code
> stuff and use the glibc API using a thin layer
> that allows us to go for a nmap database
> distributed via feed.
> You opinions welcome!

I'm not sure I see too much wrong with the fall-back approach
currently in use. That being said, the services file I think
could benefit from being distributed with the feed to have it
be up to date, so moving this file from the $CONF directory to
the script feed direction seems to make good sense.


More information about the Openvas-devel mailing list