nessusd killing and and still getting the logs

Hello all-

I was looking through the man pages for nessus and could not find anything on this, but I was wondering if there is a "safe" way to terminate a nessus scan forked from a cron job?

Also - if killed, does NESSUS save off it's log files so that you can review them? We found some type of log files in /tmp, but we were wondering if there's another location to look as well?

Finally, if NESSUS crashes an application, or a server, is there a way, via the logs to see what plugin caused the incident?

Searching the NESSUS mail log yielded the following on the shutdown of the daemon - basically a init.d script setup:

http://mail.nessus.org/pipermail/nes.../msg00095.html

However, I wanted to see if there is an updated solution anyone here may have.

We are currently using NESSUS 2.2.4

Thanks in advance and let me know if I can provide anymore information.

Hey Hey,

I'm not sure aout a safe way to kill the process, but should it crash something, you can find error logs in the /var/log/nessus folder usually (depending on your install of course)... In there you should find a standard log and also nessus.dump... which may have the information you are looking for.

Peace,
HT

I think you should sign up for the nessus mailing list if you're going to start using it. I've been on it for 8 months or so and I find it useful. This question would probably be answered in about 6 hours on there.

here is the link http://list.nessus.org/


I do not qualify myself to answer your question, but that may be a useful tool for you.


*edit*

Unfortunately I know they would first tell you to get version 2.2.6



Cheers,

The_Captain

Quote:

---

I'm not sure aout a safe way to kill the process, but should it crash something, you can find error logs in the /var/log/nessus folder usually (depending on your install of course)... In there you should find a standard log and also nessus.dump... which may have the information you are looking for.

---

Ahh yes - thanks HTRegz - looking now.

Quote:

---

I think you should sign up for the nessus mailing list if you're going to start using it. I've been on it for 8 months or so and I find it useful. This question would probably be answered in about 6 hours on there.

here is the link http://list.nessus.org/


I do not qualify myself to answer your question, but that may be a useful tool for you.


*edit*

Unfortunately I know they would first tell you to get version 2.2.6

---

Ok - thanks Captain - I will be joining the maillist today and I just saw that 2.2.6 was released today.

Thanks much for the response thus far.

Also - we were able to restore the session, let it run for a while @20minutes - without being plugged into the network, killed it and was able to create a report with more information in it that we hoped to get.

I've been a member of that list for a long time and it is very helpful.

There was a logging bug in the build you are running. My advice would be to upgrade to the latest build. The bug is related to logging actually stopping after you HUP the process.

Your questions are not new ones to the mailing list.

Two log files to work with are:

/usr/local/var/nessus/logs/

nessusd.dump and nessusd.messages

The messages file is the one you're going to want to look at. The format is something like:

Code:

---

TIMESTAMP user genxer: launching netbios_name_get.nasl
TIMESTAMP netbios_name_get.nasl finished its job in [seconds]
TIMESTAMP Finished testing [IP ADDRESS] Time: [seconds]
TIMESTAMP user genxer: test complete

---

Anyway, you're going to need to filter through the log file. My advice is to get your PERL junky on the case and develop a few simple parsing scripts. That's what I've done and I'm lovin life.

Also, I have yet to find a foolproof way to determine which NASL actually caused a problem but using timestamps on the nessus box and your target (assuming they are in sync) can help you narrow down the cause.

The reason for this is that one nasl could have clipped a service and when another nasl comes along it may choke on this and *appear* to be the problem but in actuality, it was an earlier fired nasl that created the condition for this particular nasl to crap out. Make sense?

Anyway, this topic and various ideas to approach it are discussed on the mailing list.

PS

The 2.2.6 build has New NASL function socket_get_error() which returns the last error
which occured on a socket (timeout, connection reset, etc...)

This will also help out when determining what went sour during a particular type of test.

--TH13

TH13 - thanks much for the information as well. It is much appreciated. Just finished upgrading and joining the maillist - searching now - we originally thought we had a DOS flag thrown, but we didn't. So we will follow up on your advice and start digging through our logs and check the maillist as well. I noticed that a init.d startup may also help with closing down the nessusd daemon cleaner - although, and my apologies for not knowing Linux inside-out, but they mention "killproc" and I can't find it on our machines - 'course it could be something else I am investigating right now as well in terms of patching or a lack thereof... so I will check and report back on that.

Also - with (In zombie Skinner's voice) "your big chess-club brain" - why aren't you working for the NSA or something - I'm sure they could make good use of your talents, not to mention some of the other talented people here. Serious - many of you run rings around me in terms of this security and OS knowledge, just glad I can tap into it when needed.

Thanks again all!

Quote:

---

Also - with (In zombie Skinner's voice) "your big chess-club brain" - why aren't you working for the NSA or something - I'm sure they could make good use of your talents

---

I already work for the Govt. and deal with many three letter abreviated law enforcement/defense depts.

;)

Quote:

---

I already work for the Govt. and deal with many three letter abreviated law enforcement/defense depts.

---

Cool, then they have at least one person with a good head on their shoulders.

Sorry to get off topic, but I have always been curious, and maybe you know, even though the NSA says it accepts applications, does it instead really "look" for it's real talent from what people have done and comb through schools like MIT?

And back on topic, still going through logs - I love it!

There are two methods of hiring. The traditional red tape of running through the application process, then when they want some extreme talent, they have a 'fast track' hiring process. This includes talent discovered in top universities such as MIT, Purdue, etc..

Keep in mind that a lot of talent comes in through intelligence agencies, various branches of the DoD and points throughout.

Yeah, Nessus does a pretty decent job of keeping track of events.

I bet horse was leading the cyber warfare charge in desert storm. Riding across the desert in a hummer using MIL-STD-810F tested laptops, breaking into Uday's computers looking for intel. Sending teraflops into space to be relayed to SOCOM. :D