Re: Proposed schema for the backend database for Nessus

Alex Zimin wrote:

>>You will see there is no such thing as a "report" in this schema. Other
>>proposals (from front-ends) include directly the report information into
>> the database. I'm not doing this since it is already redundant. If you
>>check carefully, a report on a given session is just all the
>>vulnerabilities that have been detected in a given session. I.e.
>>
>>SELECT Nessus-plugin.Description, Vulnerability.Type,
>>Vulnerability.AdditionalInformation from Vulnerability, ExecutedPlugins,
>> NessusPlugin where Vulnerability.ExecutionID =
>>ExecutedPlugins.ExecutionID AND
>>ExecutedPlugins.PluginID=NessusPlugin.PluginID AND
>>ExecutedPlugins.SessionID="A GIVEN SESSION"
>>
>>Does this make sense at all?  :-)
>>    
>>
>
>It will not be too difficult to generate a report based on provided
>tables, however I want to notice one thing.
>About month ago Renaud did a clean up of the plugins and several plugins
>were removed, due to the same functionality included in different plugins
>
>If plugin table would not contain outdated plugin data, it will not be
>possible to generate proper report.
>
There's no reason why the Nessus-plugin table would not be able to 
contain outdated data. As long as pluginIDs are not reused whenever they 
are removed (are they?) you can have all the information there. Since 
you create this information with your first Nessus installation and 
update it regularly you are going to have always both the old plugins 
and the (updated) new ones...

>Should we add a table which would list substituded plugins in case old
>plugins would be replaced with a new plugins, with better functionality?
>
>Table structure will be very simple
>
>PluginID (original pluginID)
>SubstPluginID (new PluginID)
>SubstitutionDate (optional)
>
That's not a bad idea, it would make report generation more complex, though.

>In this case report will be generated and will display the description of
>the substituted plugin.
>
But that description might not be proper or valid. Take for example that 
the 'default_accounts' plugin (10328) is substituted by the hydra plugin 
(10909) which checks, not only telnet but many other services (not that 
it's going to happen). Even if the end functionality is the same, if you 
are not providing a proper username/password file for hydra then you 
might not detect (i.e. bruteforce) and account that the previous plugin 
did detect (it provides an 'accounts.txt' file which includes some 
common user/password combinations).

So, not only would the output information differ the results as well as 
the references (CAN-1999-0502 for 10328) might even do too..

>
>Or maybe even just add SubsPluginID and Date to the Nessus-Plugins table,
>but in this case we may have too much garbage in that table.
>
Yes. I guess this "feature" is not going to be used all the time, just 
in some specific locations.

>
>Does it make sense?
>
>  
>
Yes it does and you've brought up a valid issue. I'm not sure if Renaud 
has reused plugin-ids after removing them for whatever reason (Renaud?).

Regards

Javi

PS: If someone can provide comparison of plugins from the different 
Nessus releases I would be more than grateful (and the 'nessus-extract' 
tool would be useful here, hint, hint...)