Mailing List Archive: Serious trouble: plugins not always executed

Serious trouble: plugins not always executed

Jan 6, 2005, 4:13 AM

Post #1 of 5 (2439 views)

Hi,

we are currently intensively testing the 2.3.0 version
(mostly current CVS) and we faced a serious problem
that unfortunately appears very hard to track.

Using 2.3.0 or current CVS using only Local Security
Checks plugin (ie. only uname -a) does only occasionally work.
Whether it works or not seems to change with using
different servers that have different plugin sets.

We even observed that, when using many plugins, only
a portion of it is really executed (no error messages).

Debugging is difficult, but it seems that the SSH access
sometimes really happens but the results don't make it
back to Nessus Server. Sometime even SSH access did
not happen and, alas, sometimes everything works.

If someone of you is interested in helping us to track
down the problem it would be most helpful for us
if you try to reproduce the problem.

For this, basically you need to:
- install everything from CVS into a new location
(with a new Nessuse Server users and a new Cert)
- use a new user for Nessus GTK Client
- Create and place the SSH certificate properly
- Select only "Local Security Checks" plugin
and switch on dependencies consideration.
- Enter the SSH properties in the Plugin Prefs.
- Run the test multiple times.

If you just have a idea where we might have to look for in
the code this would be equally welcome.

One of our suspects is the hashing. We'll remove it and see
if it works better.

Best

Jan

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/

Re: Serious trouble: plugins not always executed [ In reply to ]

jan at intevation

Jan 6, 2005, 5:09 AM

Post #2 of 5 (2367 views)

Permalink

On Thu, Jan 06, 2005 at 12:13:42PM +0100, Jan-Oliver Wagner wrote:
> Debugging is difficult, but it seems that the SSH access
> sometimes really happens but the results don't make it
> back to Nessus Server. Sometime even SSH access did
> not happen and, alas, sometimes everything works.

For a case where it does not work I find the following in

nessusd.dump:
| error: 'kern.maxfiles' is an unknown key
| [25580] nessus_get_socket_from_connection: bad fd <-1>
| [25580] nessus_get_socket_from_connection: bad fd <-1>
| [25585] nessus_get_socket_from_connection: bad fd <-1>
| [25596] nessus_get_socket_from_connection: bad fd <-1>
| [25598] nessus_get_socket_from_connection: bad fd <-1>
| [25600] nessus_get_socket_from_connection: bad fd <-1>
| [25581] nessus_get_socket_from_connection: bad fd <-1>

any idea what the reason might be for these errors?

nessud.messages:
| [Thu Jan 6 12:55:56 2005][25533] nessusd 2.3.0. started
| [Thu Jan 6 12:56:22 2005][25533] connection from 192.168.11.13
| [Thu Jan 6 12:56:22 2005][25568] Client requested protocol version 12.
| [Thu Jan 6 12:56:22 2005][25568] successful login of test from 192.168.11.13
| [Thu Jan 6 12:56:29 2005][25568] Redirecting debugging output to /var/nessus/logs/nessusd.dump
| [Thu Jan 6 12:56:52 2005][25568] user test starts a new scan. Target(s) : thetis, with max_hosts = 20 and max_checks = 4
| [Thu Jan 6 12:56:52 2005][25568] user test : testing thetis (192.168.11.13) [25571]
| [Thu Jan 6 12:56:52 2005][25571] user test : launching ssh_settings.nasl against thetis [25572]
| [Thu Jan 6 12:56:52 2005][25571] ssh_settings.nasl (process 25572) finished its job in 0.003 seconds
| [Thu Jan 6 12:56:52 2005][25571] user test : launching ping_host.nasl against thetis [25573]
| [Thu Jan 6 12:56:52 2005][25571] ping_host.nasl (process 25573) finished its job in 0.011 seconds
| [Thu Jan 6 12:56:52 2005][25571] user test : launching nessus_tcp_scanner.nes against thetis [25574]
| [Thu Jan 6 12:56:57 2005][25571] nessus_tcp_scanner.nes (process 25574) finished its job in 5.207 seconds
| [Thu Jan 6 12:56:57 2005][25571] user test : launching find_service.nes against thetis [25578]
| [Thu Jan 6 12:59:51 2005][25571] find_service.nes (process 25578) finished its job in 173.202 seconds
| [Thu Jan 6 12:59:51 2005][25571] user test : launching ssh_get_info.nasl against thetis [25644]
| [Thu Jan 6 12:59:51 2005][25571] ssh_get_info.nasl (process 25644) finished its job in 0.014 seconds
| [Thu Jan 6 12:59:51 2005][25571] Finished testing thetis. Time : 178.49 secs
| [Thu Jan 6 12:59:51 2005][25568] user test : test complete
| [Thu Jan 6 12:59:51 2005][25568] user test : Kept alive connection

Looks fine. Except that I don't get the uname -a for SSH.

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

Re: Serious trouble: plugins not always executed [ In reply to ]

deraison at nessus

Jan 6, 2005, 5:24 AM

Post #3 of 5 (2357 views)

Permalink

On Thu, Jan 06, 2005 at 12:13:42PM +0100, Jan-Oliver Wagner wrote:
> - Run the test multiple times.

Try to disconnect from the server and scan again - does the problem
occur again ?

> One of our suspects is the hashing. We'll remove it and see
> if it works better.

Why would it be ?

-- Renaud

Re: Serious trouble: plugins not always executed [ In reply to ]

jan at intevation

Jan 6, 2005, 6:03 AM

Post #4 of 5 (2369 views)

Permalink

On Thu, Jan 06, 2005 at 01:24:05PM +0100, Renaud Deraison wrote:
> On Thu, Jan 06, 2005 at 12:13:42PM +0100, Jan-Oliver Wagner wrote:
> > - Run the test multiple times.
>
> Try to disconnect from the server and scan again - does the problem
> occur again ?

yes.

> > One of our suspects is the hashing. We'll remove it and see
> > if it works better.
>
> Why would it be ?

changing the number of plugins selected/available seemed to
have influence on success/failure. But the reason might well
be something else.

Jan
--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/

Re: Serious trouble: plugins not always executed [ In reply to ]

jan at intevation

Jan 6, 2005, 8:30 PM

Post #5 of 5 (2370 views)

Permalink

Hi,

I think I solved this issue now.

I detected that the version that has a strange behaviour was
the one build through rpmbuild.
In fact it turned out that if you compile nessus-libraries with
./configure
CFLAGS='-O2' make
this will create a libnessus.so which will behave strange when
doing SSH tests. The strangeness are multiple broken pipes
one can watch in the nessus.dump file.
The file size of the so-file is different if you use the CFLAGS
or not.
Maybe the multiple goto statements are too hard to optimize for gcc.

I 'healed' that in RPM by using this line
CFLAGS='' make
because rpmbuild default is a environment CFLAGS with -O2 set.

Alas, that took _quite_ some hours to find out :-(

Best

Jan

On Thu, Jan 06, 2005 at 12:13:42PM +0100, Jan-Oliver Wagner wrote:
> we are currently intensively testing the 2.3.0 version
> (mostly current CVS) and we faced a serious problem
> that unfortunately appears very hard to track.
>
> Using 2.3.0 or current CVS using only Local Security
> Checks plugin (ie. only uname -a) does only occasionally work.
> Whether it works or not seems to change with using
> different servers that have different plugin sets.
>
> We even observed that, when using many plugins, only
> a portion of it is really executed (no error messages).
>
> Debugging is difficult, but it seems that the SSH access
> sometimes really happens but the results don't make it
> back to Nessus Server. Sometime even SSH access did
> not happen and, alas, sometimes everything works.
>
> If someone of you is interested in helping us to track
> down the problem it would be most helpful for us
> if you try to reproduce the problem.
>
> For this, basically you need to:
> - install everything from CVS into a new location
> (with a new Nessuse Server users and a new Cert)
> - use a new user for Nessus GTK Client
> - Create and place the SSH certificate properly
> - Select only "Local Security Checks" plugin
> and switch on dependencies consideration.
> - Enter the SSH properties in the Plugin Prefs.
> - Run the test multiple times.
>
>
> If you just have a idea where we might have to look for in
> the code this would be equally welcome.
>
> One of our suspects is the hashing. We'll remove it and see
> if it works better.

--
Jan-Oliver Wagner http://intevation.de/~jan/

Intevation GmbH http://intevation.de/
FreeGIS http://freegis.org/