Start using Nessus for free in five easy steps or if you are feeling confident about it already and want to purchase an annual subscription. Tenable’s vulnerability scanner, Nessus is a comprehensive vulnerability scanner and is one of the most popular in use today.
With a Nessus essentials free license you can scan up to 16 ip addresses but if that is not enough you can buy tenable.io too which grants you unlimited scanners. In this tutorial, how to use Nessus at home in 5 steps, I’ll cover how to install Nessus and start making scans.I cover making API calls to Nessus as well. Use Splunk? Look at making calls to Splunk’s API, How to Thwart Splunk Man In the Middle Attacks With Go.
Table of Contents
Here’s What You Need
Need help installing Go? You’ll find it in the Best GUI framework for Go post.
- Kali Linux virtual machine
- Go installed on Kali Linux
- Live Windows AD Domain Controller
- Live Domain-joined Windows host
- Credentials for an AD user with Domain Admins group permissions
Step 1: Register An Account
Go to the Tenable site. Create an account for Nessus Home. It’s important to make the distinction here between the two. Nessus Home is the free version we are using, while Nessus Professional is the commercial paid version. Again Tenable makes it clear that the trial Home version is not for commercial usage. Notice how it says “thanks for choosing too…to protect your personal network.”
Please note that Nessus Home is available for non-commercial, home use only. If you will use Nessus at your place of business, you must purchase a subscription.
tenable.com
Step 2: Get Nessus Home
The download for Nessus Home is found on the site. From the list choose Nessus-8.2.3-debian6_amd64.deb, the Debian/Kali Linux package. Using the default package manager for Debian dpkg, install the .deb file. The “-i” flag is short for “–install”.
# install Nessus
dpkg -i Nessus-8.2.3-debian6_amd64.debStep 3: Start Nessus Service
Upon running the installation command the terminal prompts to be aware of the two-step process to start Nessus.
- You can start Nessus Scanner by typing /etc/init.d/nessusd start
- Then go to https://kali:8834/ to configure your scanner
# start Nessus daemon
/etc/init.d/nessusd startDo this by going to https://kali:8834 and begin the installation process.
- Create a Nessus user account.
- Register the product using the trial code.
- Initialization process completes.
Step 4: Create Nessus Policies
Policies versus scans. The difference is that policies create templates for scans. When scans launch and then complete the results are stored in the My Scans folder on the dashboard. Let’s discuss the types of scans. We are going to do a basic scan and a credentialed scan. The latter requires an Active Directory user credentials for scanning Windows machines.
Scans in Nessus are enabled by the user accounts they operate as. Credentialed scanning employs file system level access. In other words the highest level of privilege enables the highest level of access for the scan. This means the most accurate reporting. This usually produces reports with more findings than just network-level scanning. The goal is to assess true patch level of a system by reading its file system attributes, this requires user privileges on the system.
Resources tab > Policies
Basic Scan: Click on create new scan. Give the scan a name such as basic_scan. In the Targets field put the ip address of the Windows 7/10 host. Save the new scan.
Credentialed Scan:
Create a new Scan. Choose the “basic network scan”. Give it a specific name such as credentialed_scan. Under the Credentials tab. Click on Windows. Enter credentials for a Domain Admins group account. Not sure what the domain name is? Check on the machine by going to System and Security > System > Computer name, domain, and workgroup settings. Look under “Domain: {domain}”. Click check on the “Never send credentials in the clear.” Under Targets put the ip address of the Windows 7/10 host AND the Windows domain controller. Save the new scan.
Note: A possible account for this purpose could be a service account created just for credentialed Nessus scans.
Virtual Networking
Let’s cover the virtual networking required to carry out the scan. Not sure how to setup a Windows Active Directory Domain Controller? Read my post, it’s very simple.
For all the virtual machines do this one step: add an internal network adapter. Beware that this means a few things. First, it means that VirtualBox is not serving as the DHCP server anymore for your virtual machines. This duty will now fall to the domain controller.
Kali Linux: We now need to assign a static ip address for the Kali Linux instance since it is now on a Host-Only network. Give the machine an IPv4 address on the same subnet as the gateway. 192.168.56.1 is the ip address of the Windows Server Domain Controller. 192.168.56.1 is the ip address of the VirtualBox network adapter. Find this by doing an “ipconfig” on any of the Windows hosts. It will be the “Default Gateway”.
Windows Domain-joined Host: Now on this virtual machine, configure the networking settings for the Ethernet adapter.
Windows Domain Controller: This is essentially a Windows 2016 Sever with Windows Active Directory installed. The setup is the same except that the Preferred DNS server is localhost, or 127.0.0.1.
Step 5: Scan
Navigate to https://kali:8834/#scans/folders and click on My Scans. Now click Launch on the selected scan we just configured!
Run a scan for the Windows 10 host. Running a basic network scan with no credentials stored produced a basic report with a single informational-level finding. After a credentialed scan I see at least 10 extra findings, although still info-level. Throwing in the ip address for the domain controller comes back with bigger and better results.
For every vulnerability found there is a plugin ID. You can use this to learn more about how Nessus defines the vulnerability.
Basic vs. Credentialed
As you can see the results of the basic scan versus the credentialed scan are extremely disparate and reenforces the idea that the latter should be preferred to engage your IT team.
Bonus: Nessus API
Every ethical hacker should be familiar with APIs. They are everywhere now. So then let’s take a look at Nessus’s API. Nessus requires all requests that require authorization either contain a session token or an API key in the headers of that request. Think of the process as a badge reader at an office. You flash your ID card to the scanner and are granted access as a result. In this scenario, instead of being granted entry, you’re being granted a session token. This session token expires with time and therefore we will check for the presence of it in every request made after the initial token-granting request.
The Nessus API documentation can be found internally to the application at https://kali:8834/api.
Authentication
- 1. API Keys
Go to the page, https://kali:8834/#/settings/my-account/api-keys.Click on “Generate”. Two API keys are created, the access key and secret key. This will be set with a single HTTP header, “X-ApiKeys”.
req.Header.Add("X-ApiKeys", fmt.Sprintf("accessKey=%s";secretKey=%s", accessKey, secretKey))To demonstrate try a simple curl request made to the Nessus server API. So what is happening here? The request being made is authenticated using the API keys. Note: never store the API keys locally or on the network! Access them as environment variables instead, which I will cover.
# make the request
curl -H -X -k "X-ApiKeys: accessKey={your key}; secretKey={your key}; https://kali:8834/server/status"
# json response
{"code":200, "status":"ready"}- 2. User Credentials (username and password)
The second option is basic authentication, which is a method most APIs support by default. The process is simple. Pass the credentials and then a session token is sent in the response. Now that token should be added to a new HTTP header, “X-Cookie: token={token};” for each subsequent request.
Make a Request, Securely
Design: A few words on the design of the program we’ll code. The implementation for the Nessus client is meant to aid in convenience in making API calls. Think convenience and therefore a wrapper. Yes, a wrapper simplifies the interactions between an API and a client application. See another similar example.
Secure-Design: The right design performs digital certificate verification. In other words, not turning off all ssl verification! Go, like other high-level languages has the ability to check the root certificates installed on a device. In the context of making API calls why install a new one, when you can place it in the program itself.
In one sentence: We are literally telling the client application to trust the Nessus server’s self-signed digital certificate by embedding it in the program.
Create the file ~/go/src/nessus.go. Add the following.
package main
const(
nessusCert = `---BEGIN CERTIFICATE---3asljk5...`
)
type Client struct{
httpc *http.Client
aK string
sK string
url string
}
func NewClient(httpc *http.Client, accessKey, secretKey, url string){
return &Client{
httpc: hc,
aK: accessKey,
sK: secretKey,
url: url,
}
}
// add certificate check in http client
func CustomHttpClient() *http.Client{
tlsConf := &tls.Config{RootCAs:x509.NewCertPool()}
trans := &http.Transport{TLSClientConfig:tlsConf}
client := &http.Client{Transport: trans}
certBytes := []byte(nessusCert)
check := tlsConf.RootCAs.AppendCertsFromPEM(certBytes)
if !check {
panic("Could not parse x509 cert!")
}
return client
}
// make a request using API keys auth method
func (client *Client) makeExampleRequest() string, error {
req, err := http.NewRequest(http.MethodGet,fmt.Sprint("%s/server/status",client.url))
req.Header.Add("X-ApiKeys",fmt.Sprintf("accessKey=%s;secretKey=%s",client.aK, client.sK))
resp, err := client.httpc.Do(req)
if err != nil{
return "", err
}
defer resp.Body.Close()
bytes, err := ioutil.ReadAll(resp.Body)
stringbody := string(bytes)
return stringbody, nil
}
func main(){
accessKey := os.getenv("ACCESSKEY")
secretKey := os.getenv("SECRETKEY")
httpClient := CustomHttpClient()
nessus := NewClient(httpClient,accessKey,secretKey)
resp, err := nessus.makeExampleRequest()
if err != nil {
fmt.Printf("error! %v/n", err)
}
fmt.Println(resp)
}The response is going to be identical to the one retrieved by the curl request seen earlier in this post. {“code”:200, “status”:”ready”}