Ninja’s OpenVAS Reporting

Here is a quick blogpost which might be helpful to the OpenVAS users. OpenVAS is a free vulnerability scanner maintained by a German company. Initiality, it was a fork of Nessus but today it has nothing in common with the commercial vulnerability scanners. OpenVAS is a good alternative to commercial solutions when you need to deploy a vulnerability management process and you lack of a decent budget. But, like many “free” solutions, it does not mean that they don’t have a cost associated to it. Particularly, OpenVAS is lacking of a good documentation, even if the users mailing list is quite active.

I used OpenVAS for a project which involved a scanning of multiple IP subnets (multiples /16’s and /24’s – for those who are not familier with the CIDR notification, a /16 is 65536 IP addresses). For performance reasons, you have to install OpenVAS on a very strong server. The scan took several hours but was completed successfully. The problems came with the generation of reports. OpenVAS offers multiple report formats:

When you select “XML” as output format, data are simply extracted from the internal database by the process “openvasmd” which is the manager daemon. The default format being XML, when you select another type of report, the XML data must be also processed by external tools to generate the final file. In my case, besides XML, I also needed the TXT and PDF reports. And problems started…  My sessions always reached a timeout and the browser returned all the time the same error message. After some investigations, here is how to generate your reports manually. [Requirement: you need root access to the OpenVAS server]

When you select an alternative file format, OpenVAS creates a temporary directory containing interesting files and scripts. On my standard Debian server running OpenVAS 6 (installation performed using the packages), the temporary directory was:

/usr/share/openvas/openvasmd/global_report_formats/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

If you have multiple directories, check the time stamps and use the most recent one. Depending on the selected file format, the directory will contain:

• A bash script called “generate“
• A report stylesheet called “latext.xsl” (for PDF reports) or “TXT.xsl” (for plain text reports-

Once openvasmd has successfully generated the XML output file, it uses another tool called “xsltproc” via a shell script created in the builtin task manager. This tool applyes XSL stylesheets (found in the directory above) to the generated XML file. The process tree looks like:

init-+-...
     +-openvasad
     +-2*[openvasmd───openvasmd───openvasmd───sh───sh───xsltproc]
     +-...

In case of PDF, a Latex file is procuded. The next step will be to convert the Latex file to PDF using “pdflatex“. The problem is the following: When you have a very big XML file to process, the xsltproc tools takes a very long time (in my case anyway) and PDF file is not returned to the browser! The XML output generated by openvasmd is stored in another temporary directory file:

/tmp/openvasmd_xxxxxx/report.xml

The problem is that this directory is deleted when the report generation tasks is stopped. You need to make a copy of it before or generate first a XML report via the web console. While xsltproc is running:

# cd /tmp/openvasmd_*
# cp report.xml ..

Once killed or terminated, re-execute the script which is not deleted by the task scheduler (replace the directory name with the one corresponding to your environment):

# cd /usr/share/openvas/openvasmd/global_report_formats/c402cc3e-b531-11e1-9163-406186ea4fc5
# ./generate /tmp/report.xml >/tmp/report.pdf

I did not investigate further what caused the timeout (I did not have time) but at least, I was able to extract useful reports from my OpenVAS server!