Re: Using a database as backend for Nessus (current state and volunteering for development)

Renaud Deraison <[email protected]>
Newsgroups gmane.comp.security.nessus.devel
Message-ID <[email protected]>
On Tue, Jan 14, 2003 at 10:55:33AM +0100, Javier Fernandez-Sanguino wrote:
> >I think it would make more sense to have it on the server side. This
> >way, one could start queries before the scan even finishes, which is
> >definitely interesting.
> >
> I agree for this in the long term. However, for prototype testing and to 
> allow other kind of database management I think it would be pretty 
> useful to have a generic NBE/XML parser that would translate the reports 
> into database INSERT/UPDATES. 

I think this leads us in the wrong path - .nsr reports are nowhere as
complete as what is on the server side and what can be filled in
real time (list of plugins selected, time of the day, and so on...)


[...]
> One of the problems with doing it in the server side (i.e. having the 
> server populate the database as it goes) is that database support is 
> probably going to become a compilation issue. I.e. if SQL calls are 
> going to be done while the nessus server does it work it's going to need 
> proper calls for 
> MySQL/PostgresSQL/Oracle/whatever_you_want_as_a_database inlined in the 
> code. 

autoconf is here for this reason. You can easily create 
nessus-core/nessusd/db_{mysql,oracle,postgres}.c and have them compile
if and only if the relevant libraries are installed on the system.
The difficulty will be to create some kind of clean abstraction layer
for all of these, but we're not doing anything too complicated either, 
so that should not be a problem.


> Also, it would be necessary to add information to the Nessus 
> configuration file so that admins can provide the appropiate database 
> information:
[....]
> Which, obviously, should not be part of the code itself. Otherwise it 
> would be difficult to provide compiled packages with database server 
> support.

nessusd has a very extandable preference system. Most of the code is
here already - just add the options to the nessusd.conf file, and you
can read them within nessusd with no change at all, through
calls to arg_get_value(). This really is not the worse part.

[...]
> However, there is information provided by the plugins 
> which is not available in the KB and that should be included too.

I don't think so. Once you're in nessusd and know that plugin#1234 is
issuing an alert, you can have all the data you want (but CVE/BIDs are
the only thing we'd be missing, and those should be indexed in a
"plugin" table).

> PS: Reanud, you did not include the nessus-extract patch I submited a 
> while back. Did you get it? I didn't want to file a bug report since for 
> this, after all, it's not part of the nessus distribution :)


Please fill a bug report marked as an "enhancement". This allows (and
everyone) to keep track of it, and bugzilla hammers me automatically if
I don't treat it with due care.


				-- Renaud
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.