If you will search articles about OpenVAS most of them will be about installation: installation in Kali (in 3 lines) and various bash scripts for installing it from the sources.
Pros of using installation the sources:
- It is the the fastest way to obtain current stable and beta version OpenVAS for every day use and testing.
- Security reasons. As soon as there are no official OpenVAS packages you need to rely on some individuals who provide packages for popular distributions and in some cases it is not the option.
- Some scripting for updating OpenVAS database and managing OpenVAS services will be required anyway. Starting the OpenVAS is still a quest: you need to check the statuses of database, start the services in a right order.
- This is the first step towards the full automation of OpenVAS scanning and testing.
- You will need to install lot’s of additional packages to build OpenVAS binaries. More than 2Gb of files should be downloaded. It may take hours to install configure all this packages on a slow machine (especially all those TeX packages).
- Building all packages also takes time. It takes as much time as knowledge base update.
I wrote a small bash script to simplify OpenVAS installation and management of – openvas_commander.sh. Tested on Debian 8.5, should work on Ubuntu and Kali.
chmod +x openvas_commander.sh
What are its advantages over other similar scripts?
Nessus update may be required for bugs and vulnerabilities fixing, and to enable some new features as well. While using of an old scanning engine or plugin feed may lead to incorrect scan results.
However, during the update process of Nessus engine, you need to stop it. What about the running and scheduled scanning tasks?
Someone might think that it is possible to put running Nessus scan task on pause and launch it when update process is finished. Well, not really. All paused scan tasks will be marked as “aborted” after updating.
Even if Tenable will ever fix this, delayed scans may still be incorrect. Different targets should be scanned at the right time. It’s not a good idea to scan windows desktops after the end of the working day, when they will be probably turned off.
We all want to have a reliable and efficient Vulnerability Scanner. This scanner should be able to find any vulnerabilities immediately, as soon as the information about them is published. And, to be honest, no one wants to research how the scanner do it. Really. It’s not our job. We purchased the product, we trust the vendor and if this product does not work as we would like, it is a vendor’s problem. Is that right?
Not really. If we do not properly recognize the condition of our infrastructure and do not properly assess the risks, because of this vendor’s faults, this would be our problem. It’s relatively easily to find out that some detected vulnerabilities from scanning report are false positives, what if scanner didn’t find an existing vulnerability? How would you even know this happened?
That’s why we still have to understand how the scanners work, to watch the watcher.
A recent example. CVE-2016-2107: OpenSSL AES CBC cipher information disclosure.
upd. For this vulnerability Tenable released addition detection plugin: “Use multiple vulnerability scanners in the name of good”.
This vulnerability may be detected by free vulnerability scanning services and practically could not detected by Nessus via unauthenticated scanning. You can see on the screenshots how we have scanned the same host with Nessus and free service by High-Tech Bridge. And Nessus did not detect CVE-2016-2107.
In this first article about Nessus API I want to describe process of getting scan results from Nessus.
Of course, it’s also great to create and run scans or even create policies via API. But to be honest, in practice, you may need this functionality rarely. And it’s easier to do it manually in GUI. On the other hand, sometimes it very efficient to create automatically some specific scan task for specific group of hosts using existing (inventory) scan results. But we will talk about this topic next time (Upd. I wrote post about scan creation “Nessus API for hosts scanning”).
Now, imagine that we have configured regular Nessus scans. And we want to get this scan results on a regular basis to make some analysis and maybe create some tickets in Jira.
As usual, I will use curl for all examples, because it is easy to read and easy to test in any Linux terminal.
Starting from Nessus v.6 the API manual is built in GUI: https://<scanner_ip>:8834/api#