|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
[Nessus-announce] Re: Nessus 2.1.0 : Local Checks |  |
- To: Renaud Deraison <[EMAIL PROTECTED]>
- Subject: [Nessus-announce] Re: Nessus 2.1.0 : Local Checks
- From: Javier Fernandez-Sanguino <[EMAIL PROTECTED]>
- Date: Wed, 07 Jul 2004 09:13:50 +0200
- Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
- In-reply-to: <[EMAIL PROTECTED]>
- Organization: Germinus
- References: <[EMAIL PROTECTED]>
- Sender: [EMAIL PROTECTED]
Renaud Deraison wrote:
[Feel free to pass this message to mailing lists which may be interested
by its content - I need plenty of testers for this]
I am proud to announce the immediate availability of Nessus 2.1.0 (experimental)
Nessus 2.1.0 brings a whole new concept of plugins in Nessus - the ability
to perform _local_ security checks on remote hosts, over SSH.
I'm very interested in helping out in this effort by providing Debian
local security checks for Debian. Count me in for that OS group.
Actually, I believe I could even automatically generate NASL plugins
implementing all relevant local security checks for the current Debian
release (3.0) after writing a proper deb.inc for Debian. What else
would be needed? Notice that Debian provides (as FreeBSD does) a full
CVE cross-reference table [2] and the advisories are easily parseable.
I can also provide a number of scripts to extract information from the
advisories published (through their security mailing lists) by
Conectiva, Debian, Mandrake, RedHat, and SuSE and dump them into an
SQL database. Generating NASL plugins from that information seems
quite easy to me since they will usually have the same structure
code-wise. If that might be useful for other groups feel free to ask
for those.
Renaud, I'm not sure if you are ware of the OVAL [1] project, which
might be useful to take into account when developing this feature.
Actually, the NASL local plugins do similar things as their OVAL
counterpart definitions (check for package versions). Compare, for
example, plugin ID 12467 [3] versus OVAL definition 827 [4]. This
seems to be an unnecesary effort duplication, maybe there could be a
way to integrate both? A lot of work has been done already to create
OVAL definitions for Windows, Solaris and RedHat vulnerabilities, all
the definitions (as well as the source code of the OVAL language
interpreter) are open source (GPLd)
Just a few thoughts.
Javier
[1] oval.mitre.org
[2] http://www.debian.org/security/crossreferences
[3]
http://cvsweb.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/redhat-RHSA-2004-064.nasl?content-type=text/plain
[4] http://oval.mitre.org/oval/definitions/pseudo/OVAL827.html
_______________________________________________
Nessus-announce mailing list
[EMAIL PROTECTED]
http://mail.nessus.org/mailman/listinfo/nessus-announce
| |