nessusd -R every time?

[Simon John]

Hi,

I'm writing some NASL plugins at the moment and am getting fed up of
going through the following procedure to make sure the new script is
seen by NessusClient:

1. copy script from Git repository to the plugins directory
2. sign the script with nasl -S
3. nessusd -R
4. /etc/init.d/nessusd restart
5. reconnect client to server

The worst part is nessusd -R which takes forever even on a 3.2GHz quad
core! Isn't there a way this can be skipped or sped up as its a bit of a
pain, especially when you've forgotten a semi-colon somewhere in your
script and you've got to go through it all again!

I can only think of temporarily moving most of the plugins out of the
way, just leaving enough to satisfy dependencies.

Any other ideas?

[Renaud Deraison]

Hi John,

Post by Simon John
Hi,
I'm writing some NASL plugins at the moment and am getting fed up of
going through the following procedure to make sure the new script is
1. copy script from Git repository to the plugins directory
2. sign the script with nasl -S
3. nessusd -R
4. /etc/init.d/nessusd restart
5. reconnect client to server
The worst part is nessusd -R which takes forever even on a 3.2GHz quad
core! Isn't there a way this can be skipped or sped up as its a bit of a
pain, especially when you've forgotten a semi-colon somewhere in your
script and you've got to go through it all again!
I can only think of temporarily moving most of the plugins out of the
way, just leaving enough to satisfy dependencies.
Any other ideas?

nessusd -R purges the entire plugin database and re-processes every
plugin. This should only be used when a DB is corrupt.

For your use case, you should use nessusd -t which performs a checksum
on each plugin and only reprocesses those which changed. It's way
faster and should remove the pain.

Also, prior to putting the script into the plugins/ directory, you
should use nasl -L to make sure it parses properly.



-- Renaud

[Simon John]

Renaud Deraison wrote:

[snip]

Post by Renaud Deraison
For your use case, you should use nessusd -t which performs a checksum
on each plugin and only reprocesses those which changed. It's way
faster and should remove the pain.

That does seem to be a lot faster thanks, however it never returns
control to the console, you need to Ctrl-C it.

A quick "strace nessusd -t" reveals that it sits there trying to bind to
ipv6 or something - which I have disabled on my Linux install (and have
enable_listen_ipv6=no in nessusd.conf) :

open("/proc/net/if_inet6", O_RDONLY) = -1 ENOENT (No such file or
directory)

Post by Renaud Deraison
Also, prior to putting the script into the plugins/ directory, you
should use nasl -L to make sure it parses properly.

Yes that's a good point!

[Renaud Deraison]

Post by Simon John
[snip]

Post by Renaud Deraison
For your use case, you should use nessusd -t which performs a
checksum
on each plugin and only reprocesses those which changed. It's way
faster and should remove the pain.

That does seem to be a lot faster thanks, however it never returns
control to the console, you need to Ctrl-C it.

That's because 'nessusd -t' is similar to 'nessusd' in the sense that
it really starts the nessusd process and won't return.
Use nessusd -t -D to make it run in the background.

Post by Simon John
A quick "strace nessusd -t" reveals that it sits there trying to bind to
ipv6 or something - which I have disabled on my Linux install (and have
open("/proc/net/if_inet6", O_RDONLY) = -1 ENOENT (No such file or
directory)

Even though you disabled binding to ipv6, nessusd checks wether ipv6
is enabled -- you could have a nessusd daemon explicitely listening on
IPv4 only, but still want it to scan IPv6 targets.


-- Renaud

[Bob Babcock]

Post by Renaud Deraison
nessusd -R purges the entire plugin database and re-processes every
plugin. This should only be used when a DB is corrupt.
For your use case, you should use nessusd -t which performs a checksum
on each plugin and only reprocesses those which changed. It's way
faster and should remove the pain.
Also, prior to putting the script into the plugins/ directory, you
should use nasl -L to make sure it parses properly.

What about under Windows? It's been a while since I did any plugin
modifications; as I recall, I deleted the database files and ran
build.exe, and it was rather slow.

[Charles Wu (CTI)]

Hello,

With a variety of Client options beyond the "standard" Nessus Client (e.g. Nessconnect, etc) that each put their own "twist" on reporting/scheduling/automating/etc with the Nessus Server, one can't help but think that there's some type of API / interface for "communicating" with the Nessus server (in our case, we just want to add the functionality to automate scans on a recurring basis a little more elegantly than using cron jobs and we may want to integrate this into our corporate sharepoint portal so that our end users would have a "click to scan your machine" button or something)

Any leads in this direction?

I've checked the ProfessionalFEED customer service portal and I can't seem to find anything in regards to this

Thanks

-Charles

This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivery of the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone at 630-344-1586.

[Mercer, Jeff C - Raleigh, NC]

You want the Nessus Tranfer Protocol (ntp). Download the Nessus 2.2.11
core source code from the nessus.org website. In the archive is a
doc/ntp folder with the whitepaper.

--------
Jeff Mercer - CISO - Security Vulnerability Assessments

-----Original Message-----
Sent: Tuesday, December 30, 2008 3:29 PM
Subject: Nessus Server API for customized clients
Hello,
With a variety of Client options beyond the "standard" Nessus
Client (e.g. Nessconnect, etc) that each put their own "twist"
on reporting/scheduling/automating/etc with the Nessus Server,
one can't help but think that there's some type of API /
interface for "communicating" with the Nessus server (in our
case, we just want to add the functionality to automate scans
on a recurring basis a little more elegantly than using cron
jobs and we may want to integrate this into our corporate
sharepoint portal so that our end users would have a "click to
scan your machine" button or something)
Any leads in this direction?
I've checked the ProfessionalFEED customer service portal and
I can't seem to find anything in regards to this
Thanks
-Charles
This message is intended only for the use of the individual or
entity to which it is addressed and may contain information
that is privileged, confidential and exempt from disclosure
under applicable law. If the reader of this message is not the
intended recipient, or the employee or agent responsible for
delivery of the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you
have received this communication in error, please notify us
immediately by telephone at 630-344-1586.
_______________________________________________
Nessus mailing list
http://mail.nessus.org/mailman/listinfo/nessus