Installing Nessus on Backtrack 4

Here is an easy to follow tutorial on installing nessus on the Backtrack 4 Pre Release. This is courtesy of secure_it at the remote-exploit forums.

First download these packages


Nessus-3.2.1-ubuntu804_i386.deb
NessusClient-3.2.1-debian4_i386.deb


(I have chosen debian package because NessusClient-3.2.1.1-ubuntu804.i386.deb was missing some of dependencies and was not installing correctly.instead the debian package worked like a charm as its upto-date with dependencies and it produces no error at all.


Next register your copy to get plugins update using homefeed and please provide the real mail ID as they will send you the activation key for homefeed.


Regsiter Here


Click accept and enter a valid working email ID.


now we start installing the packages.


root@ThUndErbOLt:~#dpkg -i Nessus-3.2.1-ubuntu804_i386.deb


now configure the certificate & admin user for nessus
root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-mkcert (this is neccessary to communicate between nessus client to nessus daemon/remote host)
(configure options accordingly or just press enter for default)

CA certificate life time in days [1460]:
Server certificate life time in days [365]:
Your country (two letter code) [FR]:IN
Your state or province name [none]: Karnataka
Your location (e.g. town) [Paris]: Bangalore
it should show the message
Congratulations. Your server certificate was properly created.
hit enter to come out


root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-adduser
enter information about the user.
Login
Authentication (Pass/Cert)
Password:
confirm password:
after configuring the parameters it ask for rule-set.we have configured the admin user having full permissions.if we wants to limit and want to add certain users then we can use rule-set here.
For configuring ruleset please refer to nessus-adduser(8) man page for the rules syntax as it limit the use of nessus.
press ctrl + d
it asks for confirmation.choose y


now start Nessus daemon by using
root@ThUndErbOLt:~# /etc/init.d/nessusd start
$Starting Nessus : .


confirm that its running using
root@ThUndErbOLt:~# netstat -ant|grep 1241
tcp 0 0 0.0.0.0:1241 0.0.0.0:* LISTEN
tcp6 0 0 :::1241 :::* LISTEN


now Install NessusClient(the GUI Frontend to use nessusd)
root@ThUndErbOLt:~# dpkg -i NessusClient-3.2.1-debian4_i386.deb


now register the plugin feed for updating nessus
root@ThUndErbOLt:~#/opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX(replace X with your keys)
Your activation code has been registered properly - thank you.
Now fetching the newest plugin set from plugins.nessus.org...
now it will download the plugins and will purge them into database.if you don't wan't to do this now.press ctrl + c to cancel it.later you can download it using



root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-update-plugins



run the scan using NessusClient
backtrack menu->Internet->NessusClient
click on + icon
by default selected radiobox is single host
type Host Name localhost & hit save
select the localhost & press connect
from connect option box choose edit
set the Login & Password which we created earlier using nessus-adduser
hit Save
select localhost & hit connect
first time it asks for logging into nessus server.hit yes

now you can customize the default scan/microsoft scan policy and can scan.that's it!

***note if you are having dependency issues with the Nessus Client use the following command: apt-get update

Comments

Post a Comment

Popular posts from this blog

Cracking OS X Lion Passwords

Image
UPDATE [2011-10-15]: The issues described in this post have now been resolved by Apple. Users running OS X Lion 10.7.2 or security update 2011-006 are no longer affected by the vulnerabilities detailed below (CVE-2011-3435 and CVE-2011-3436). For further details on this security update please see Apple's advisory . In 2009 I posted an article on Cracking Mac OS X passwords . Whilst this post has been quite popular, it was written for OS X 10.6 and prior. Since the release of Mac OS X Lion (10.7) in July, I have received numerous requests for an update. Typically, I would have just updated the existing article without the need for a new post. However, during my research I discovered something interesting about OS X Lion that I'd like to share. In previous versions of OS X (10.6, 10.5, 10.4) the process to extract user password hashes has been the same: obtain the user's GeneratedUID and then use that ID to extract hashes from a specific user's shadow file (See my pr...
Read more

Cracking Mac OS X Passwords

In this post I will demonstrate how to both extract and crack Mac OS X passwords. The OS X variants that this tutorial is aimed at are 10.4 (Tiger), 10.5 (Leopard) and 10.6 (Snow Leopard). Whilst Mac OS X is based on a Unix variant (BSD), there are several key differences between traditional Unix-based and Mac OS systems when it comes to password storage. Lets take a quick look at some of the differences. If you have ever poked around on an OS X system, you may have noticed the absence of the /etc/shadow file. Whilst traditional Unix and BSD variants store their password hashes in /etc/shadow and /etc/master.passwd respectively, Mac OS X does not. Since the release of OS X 10.3 in 2003, Macintosh products have stored their shadow files in the /var/db/shadow/hash/ directory. Another key difference is the way in which the two systems store their hashes. On a Unix-based system, every hash associated with the system is stored in the /etc/shadow file. This differs from OS X whereby each ...
Read more

Attacking LM/NTLMv1 Challenge/Response Authentication

Image
In Part 1 of the “LM/NTLMv1 Challenge/Response Authentication” series I discussed how both the LANMAN/NTLMv1 protocols operate and the weaknesses that plague these protocols. In this post I will demonstrate how attackers leverage these weaknesses to exploit the LANMAN/NTLMv1 protocols in order to compromise user credentials. For the remainder of this article I will be focusing on attacking the SMB protocol (Windows file sharing) as this is where LANMAN/NTLMv1 is most commonly used. Capturing the Response In order to capture a client’s LANMAN/NTLMv1 response, attackers will often utilise one of two methods: Force the client host to connect to them Conduct a man-in-the-middle (MITM) attack and “sniff” the client’s response To demonstrate these methods, I will be using the Metasploit Framework or Cain and Abel respectively. Metasploit In order for a client host to connect to us, we first need to create a listening SMB service that will accept incoming connections. Fo...
Read more