1061334686 1 SSL/password=
1061334686 3 Launched/10267=1
1061334686 3 Launched/10881=1
1061334686 1 ssh/openssh=1
* 1061334686 1 SentData/10267/INFO/1=Remote SSH version : SSH-2.0-OpenSSH_3.4p1\n
1061334686 1 Success/10267=1
1061334686 3 Launched/10342=1
* 1061334686 1 SentData/10881/INFO/1=The remote SSH daemon supports the following
versions of the\nSSH protocol :\n\n . 1.99\n . 2.0\n
1061334686 1 Success/10881=1
1061334686 3 Launched/10882=1
==========
From: Jeffrey Ryan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 8:38 AM
To: [EMAIL PROTECTED]
Subject: RE: nessus and syslogs
Thanks Keith - Very intuitive ;)
I had
hoped their might be a way to
transform the form type of
output to
single line syslog type without the
addition of a front end parser.
Jeff
-----Original Message-----
From: Young,
Keith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 19, 2003 7:19 PM
To: George Theall; [EMAIL PROTECTED]
Subject: RE: nessus and syslogs
George,
Looking at his e-mail, I would guess that he is interested in adding Nessus support to the eSecurity SIM product.
Jeffrey, there isn't a way to do this without requiring some client intervention. If the user specifies to save the session data, then your agent can read the /usr/local/var/nessus/users/(userid)/sessions/(timestamp)-data file or the /usr/local/var/nessus/users/(userid)/kbs/(ipaddr) file. Note that the "client intervention" can be automated by editing the kb lines in the /usr/local/etc/nessus/nessusd.conf file.
Maybe adding support to allow the kbs to be sent to a different
file (or
/dev/syslog) would be helpful. Then again, you
may want to check with Tenable to see if they have already solved this in their
commercial products...
--Keith
-----Original Message-----
From: George
Theall [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 19, 2003 5:34 PM
To: [EMAIL PROTECTED]
Subject: Re: nessus
and syslogs
On Tue, Aug 19, 2003 at 03:30:18PM -0400, Jeffrey Ryan wrote:
> Would anyone have any thoughts on sending
the vulnerability output
> to a
syslog ( or just a log ) ? automatically ?
Why are you interested in such an approach? That is, are you looking to:
o access partial results in the event the daemon
crashes / stalls?
o have easier access to
results of continuous, detached scans?
o
improve distribution of results?
o do
something else?
George
--
[EMAIL PROTECTED]
