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:
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:
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!