(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?
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.
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?
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.