Tag Archives: openvas-commander

GSM Community Edition and lagging OpenVAS Plugin Feed

As I already wrote in “Installing OpenVAS 9 from the sources“, since May 2017 OpenVAS 9 is available in a form of free virtual appliance. It is called GSM Community Edition (GCE) and is based on Greenbone commercial product GSM ONE.

What’s the difference between GSM ONE and free GCE? GSM Community Edition uses different Community Feed of NASL plugins, it can’t be updated automatically and does not have some management features. The most important, in my opinion, is that it does not support OpenVAS Management Protocol (OMP), API for managing scanners. Only HTTPS for WebGUI and SSH are available.

GSM start screen

Talking about different NASL plugin feeds, I need to mention recent message by Jan-Oliver Wagner in Openvas-announce list.

That seems like Greenbone is rather tired of developing OpenVAS by themselves and watching how other companies use theirs engine and feeds, positioning themselves as an “alternative to Greenbone’s product at a better price”. So, they decided:

  1. “OpenVAS NVT Feed” will be renamed to “Greenbone Community Feed”
  2. Public access to the “openvas-nvts” SVN repository will be forbidden, but the license of nasl plugins won’t be changed.
  3. Now Community Feed lags 14 days from commercial feed, but Greenbone would like to make an actual feed, but without some features for enterprise customers.

I really care about Greenbone and they, of course, do as they think is better for the company and OpenVAS community, but at the same time it reminds me situation with Tenable and Nessus. Maybe not so radical. But definitely in the same direction.

Feed delayed for 2 week can’t be used effectively for obvious reasons. If you see exploitation of critical vulnerability like WannaCry in the wild and will need to wait 2 weeks to check your infrastructure, it’s a nonsense! 🙂 That’s mean that you just can’t rely on OpenVAS anymore. And if you use it, you should think about migration on commercial solution, for example on Greenbone’s GSM, or think about getting actual plugin feed somewhere else.

The good thing, it might show customers once again that knowledge base of Vulnerability Management solution is important and stimulate other security content developers to make own nasl scripts and feeds.

But let’s go back to GSM Community Edition. Detailed description of installation process you can find on official site. I will just describe my own experience.

Continue reading

Installing OpenVAS 9 from the sources

upd. 29.09.2018 Unfortunately, the script does not work after Greenbone moved the sources from their internal repository to GitHub. It’s necessary to edit the script. Stay tuned.

In last month Greenbone Networks and OpenVAS development team have finally presented new OpenVAS 9 with new GUI, improved multi-scanner support, improved asset management, etc. We have been waiting for this release for 2 years!

Upd. Please note, that entire procedure for separating scanners onto separate hardware/distributed hardware in different datacenters has changed completely – and that it’s a good idea to get familiar with this new procedure prior to upgrading to OpenVAS 9. 😉

For installing OpenVAS 9 from the sources I used the same script as for OpenVAS 8 installation last year. More details about this script and why you may need it you can read in the post “openvas_commander for OpenVAS installation and management“.

OpenVAS 9 Dashboards

I fixed the script a bit because of these changes in OpenVAS9:

  • openvas-nvt-syncwas renamed to greenbone-nvt-sync
  • openvas-mkcert and openvas-mkcert-client were replaced by openvas-manage-certs

Continue reading

openvas_commander for OpenVAS installation and management

upd. 29.09.2018 Unfortunately, the script does not work after Greenbone moved the sources from their internal repository to GitHub. It’s necessary to edit the script. Stay tuned.

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.

OpenVAS commander

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.

Cons:

  • 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.

Upd 10.04.2017 Read how to use this script to install OpenVAS 9 on Debian in the post “Installing OpenVAS 9 from the sources“.

wget https://raw.githubusercontent.com/leonov-av/openvas-commander/master/openvas_commander.sh
chmod +x openvas_commander.sh

What are its advantages over other similar scripts?

Continue reading