[Openvas-devel] Get rid of old services concept
lists at securityspace.com
Mon Sep 7 20:58:45 CEST 2009
Jan-Oliver Wagner wrote:
> 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
> * 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
> * 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