On Tue, 18 Feb 2003, Javier Fernandez-Sanguino wrote:
> (I'm going to add the [Database-devel] for q&a on the database
> integration to the list so people can filter them out, if needed)
>
> For those that have been taken a look at the schema for integration of
> Nessus with a relational database you might have noticed there is a
> service table which is referenced by the plugins that get executed.
> There is an issue, though.
>
> We can easily add all the information in /etc/services (or the one
> generated by Nessus) and /etc/protocols into the database's Service
> table. But how should the non-standard ports be treated? (i.e. ports
> that show up as 'unknown' in the report).
>
> There are two options:
>
> 1.- add new (unknown) ports on the fly to the database when a plugin
> detects them
>
> 2.- create a service table which contains all 65535 tcp/udp ports and
> just reference it.
>
> The advantages of 1) is that tables are smaller but the hooks in the
> nessus code are more complex: it needs to check in the database if the
> port is already included there before inserting information in the
> 'ExecutedPlugins' table and has to insert the port into the 'Services'
> table.
>
> The advantages of 2) are that it's easier to code: just check which
> ServiceID is associated with the port its going to add to the
> 'ExecutedPlugins' table. The disadvantage is that the table is, always,
> quite big (131070 rows, at least, compare this against ~2184 ports which
> is the numer of known ports)
>
> Anyone?
>
I think that the unknown services should be added on the fly.
Every DB is unique to a Nessus server and that server is (most likely)
used to scan a certain group of computers. It is most likely that
those computers will always have a similar set of services that are
running on the same ports.
By limiting the ports/services, an admin could go in and "define" the
unknown services that were found.
The first option (my choice) isn't that much harder to code and will, as
Javi pointed out, significantly cut down on the size of the Services
table.
Also if I'm not mistaken, something similar to option 1 will have to be
done with Services running on non-standard ports. (If this is the case,
option 2 will make coding more difficult ;)
P.S.
It might be best if we could ask Renaud to set up a list for Nessus
database development. This would let people opt-in in order to get the
e-mails.
----------------------
William Heinbockel
Information Security Incident Response Assistant
Co-op Risk & Safety Management
Rochester Institute of Technology
E-mail: wjh3710@rit.edu
>
> Regards
>
> Javi
>
> PS: There is another option: have a way to add 'generic port'
> information in plugins. I can see how this could be done in the database
> but it breaks some assumptions..
>
> PPS: Probably the Plugin -> Service association needs to be 1:x because
> some plugins (i.e. hydra, find_services) affect more than one port.
>
>
> (I'm going to add the [Database-devel] for q&a on the database
> integration to the list so people can filter them out, if needed)
>
> For those that have been taken a look at the schema for integration of
> Nessus with a relational database you might have noticed there is a
> service table which is referenced by the plugins that get executed.
> There is an issue, though.
>
> We can easily add all the information in /etc/services (or the one
> generated by Nessus) and /etc/protocols into the database's Service
> table. But how should the non-standard ports be treated? (i.e. ports
> that show up as 'unknown' in the report).
>
> There are two options:
>
> 1.- add new (unknown) ports on the fly to the database when a plugin
> detects them
>
> 2.- create a service table which contains all 65535 tcp/udp ports and
> just reference it.
>
> The advantages of 1) is that tables are smaller but the hooks in the
> nessus code are more complex: it needs to check in the database if the
> port is already included there before inserting information in the
> 'ExecutedPlugins' table and has to insert the port into the 'Services'
> table.
>
> The advantages of 2) are that it's easier to code: just check which
> ServiceID is associated with the port its going to add to the
> 'ExecutedPlugins' table. The disadvantage is that the table is, always,
> quite big (131070 rows, at least, compare this against ~2184 ports which
> is the numer of known ports)
>
> Anyone?
>
I think that the unknown services should be added on the fly.
Every DB is unique to a Nessus server and that server is (most likely)
used to scan a certain group of computers. It is most likely that
those computers will always have a similar set of services that are
running on the same ports.
By limiting the ports/services, an admin could go in and "define" the
unknown services that were found.
The first option (my choice) isn't that much harder to code and will, as
Javi pointed out, significantly cut down on the size of the Services
table.
Also if I'm not mistaken, something similar to option 1 will have to be
done with Services running on non-standard ports. (If this is the case,
option 2 will make coding more difficult ;)
P.S.
It might be best if we could ask Renaud to set up a list for Nessus
database development. This would let people opt-in in order to get the
e-mails.
----------------------
William Heinbockel
Information Security Incident Response Assistant
Co-op Risk & Safety Management
Rochester Institute of Technology
E-mail: wjh3710@rit.edu
>
> Regards
>
> Javi
>
> PS: There is another option: have a way to add 'generic port'
> information in plugins. I can see how this could be done in the database
> but it breaks some assumptions..
>
> PPS: Probably the Plugin -> Service association needs to be 1:x because
> some plugins (i.e. hydra, find_services) affect more than one port.
>
>