Mailing List Archive

Nessus 2.1.0 : Local Checks
[.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.

To enable this feature, simply give nessusd a valid SSH public and private
key, configure an account on the remote host, and perform a regular scan
against it. For more details, please read :

<http://www.nessus.org/doc/nessus_ssh_local.html>


I have just commited our first batch of security checks (over 300 plugins)
for the following platforms :

- Red Hat Enterprise Linux 2.1
- Red Hat Enterprise Linux 3
- Mac OS X 10.2 and 10.3 (Client and Server)
- FreeBSD


We are looking for volunteers willing to maintain security checks for their
favorite Unix systems. Basically, I would like to constitute "teams" of
individuals, each team being in charge of providing the checks for one
operating system. If you want to lead such a team (and cope with the
responsability) or just write plugins for your system every now and then,
please contact me directly.


What we are going to do with the local checks
---------------------------------------------

We intend to use these new checks in two ways :

- To make sure that the remote hosts are up-to-date patch-wise. This means
that Nessus will tell you that the remote host is missing a patch for squid,
even though squid is not running (and there's a good reason for that: we
consider it as a 'latent' vulnerability) ;

- To reduce the number of false positives against operating systems whose
vendors backport their security fixes.


I really want to stress out the fact that we are *not* moving away from
remote security checks. We are perfectly aware that in some cases, it's
infeasible for the security teams to get an account on every system
they are scanning. However we are also aware that it's way more feasible
for the security team to ask for a non-root account on a sensitive server
than to ask for the installation of a local agent which will give good
security

To put it simply, the whole reasoning behind simply is that if you _can_ get an
account on the remote hosts, it would be a shame not use it to get a 100%
accurate security check.


The heroes of the day
---------------------

The heroes of the day are :

- Nicolas Pouvesle for having written a full SSH client implementation in NASL

- Tenable Network Security for having written the initial 300 plugins for
local security checks. For those among you who do not know, Tenable is the
company I co-founded with Ron Gula which sells enterprise products around
Nessus - http://www.tenablesecurity.com

I would also like to thanks the FreeBSD security team who is doing an
awesome job at keeping track of the vulnerabilities in the FreeBSD ports
and indexing them on http://www.vuxml.org/freebsd/index-date.html



Before you install Nessus 2.1.0
-------------------------------

Please note that the whole Nessus 2.1.x series is considered as being
EXPERIMENTAL. Therefore, this means that you may experience lockups, segfaults
and other kind of crashes not experienced with Nessus 2.0.x. This is
especially true since we have changed the way the internal communication
between the various Nessus processes is being done, and I'm waiting for
feedback on that.

Also, please note that installing Nessus 2.1.0 do _not_ require any additional
dependencies - not even ssh, since we have our own implementation in NASL.

However, I do not expect the 2.1.x cycle to last long. I'm aiming at
releasing Nessus 2.2.0 (or 3.0 :) in early september. So maybe 2.1.0
is stable already - test it please !

The two other major changes in Nessus 2.1.0 are :

- Re-written the internal KB API to use hash tables (instead of the slow
linked lists) and arbitrarily-sized KB items (there was a hard limit set
to 65k) ;

- Re-written the whole internal communication between the nessusd processes.
The new API is lighter on CPU and system calls, and may be a first step
to re-write the client-server communication protocol entirely ;

I also re-wrote some internal routines which had to do with how the
plugins dependencies are computed and run, which should also result in a
lighter CPU load.

Also, Nessus 2.1 (finally) supports GTK+ 2.2. This fix has been backported
to Nessus 2.0.12 which will be made available this week as well.


If you are a user of the Lightning Console, version 2.5.3 will be shortly
made available (within a day or two) and will support the new SSH-specific
options in Nessus 2.1.


Availability
------------

Nessus 2.1.0 is available immediately :

http://www.nessus.org/nessus_2_1.html


I really need a lot of testers for this - please try to install this version
and report your failures (and successes) !

For those who are cowardly waiting for Nessus 2.1.x to stabilize,
Nessus 2.0.12 will be made available later on this week. I'm bumping the
revision number from 2.0.10 directly to 2.0.12 because there was a 2.0.11 for
a long time in CVS. Nessus 2.0.12 does NOT contain the SSH checks, it will
only contain minor bug fixes.


Comments ? Questions ?
----------------------

I'm interested in your comments and questions about this feature. Please
send them to the Nessus mailing list (nessus@list.nessus.org). Implementation
details should be discussed on nessus-devel@list.nessus.org and plugins
ideas submitted to plugins-writers@list.nessus.org. You can also mail me
directly if you prefer.


If you experience bugs, please fill a bug report at http://bugs.nessus.org/.
I'm sorry for the mandatory account creation, but we need it to be able
to stay in touch with bug reporters. If you are a privacy advocate, feel
free to send me your bugs directly, but don't be surprised if I drop the
ball at some point.

-- Renaud

--
Renaud Deraison
http://www.nessus.org
http://www.tenablesecurity.com
Re: Nessus 2.1.0 : Local Checks [ In reply to ]
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