OpenVAS(8)

📦
version 23.45.5 · 6 versions
, in alpine 3.24, ubuntu stonking

💖 OpenVAS(8) — User Manuals 💖

okay bestie, sit down, hydrate, because we're about to talk about the OpenVAS Scanner 💅✨ this one's a whole manual page, a real main character, so lock in.

🌸 NAME 🌸

openvas — the Scanner of the Greenbone Vulnerability Management. yes, the scanner. the one doing the actual work while everyone else takes credit. periodt.

🎀 SYNOPSIS 🎀

openvas [-V] [-h]  [-c config-file] [--scan-start scan-uuid]  [-u] [-s]
[-y]

look at her. compact. iconic. (and yes, -s and -y really are up there, iykyk 🫶)

🦋 DESCRIPTION 🦋

okay so. Greenbone Vulnerability Management (GVM) is a vulnerability auditing and management framework, and it's built out of several modules. The OpenVAS Scanner, openvas, is the one in charge of executing many security tests against many target hosts in a highly optimized way. she's efficient. she's booked and busy. 💅

openvas inspects the remote hosts to list all the vulnerabilities and common misconfigurations that affect them. like a vibe check but for your whole network, except the vibe check has receipts. 😭

It's a command line tool with parameters to update the feed of vulnerability tests and to start a scan. The second part of the interface is the redis store, where the parameters about a scan task need to be placed, and from where the results can be retrieved. so: command line on one side, redis on the other. two halves of one slay. ✨

✨ OPTIONS ✨

  • -c <config-file>, --config-file=<config-file> — use the alternate configuration file instead of /etc/openvas/openvas.conf. basically "i don't want the default config, give me the other one." 🎀
  • -V, --version — prints the version number and exits. short, sweet, done. 👑
  • -h, --help — shows a summary of the commands. your little map when you're lost. 🗺️
  • --scan-start=<scan-uuid> — ID for a single scan task. The scanner will start the scan with the data already loaded in a redis KB, which will be found using the given scan-id. so the redis KB is already prepped, you just hand her the id and she goes. 🔥
  • --scan-stop=<scan-uuid> — ID for a single scan task. The scanner will search the redis kb associated to the given scan_id. It takes the pid from the kb and sends the SIGUSR1 kill signal to stop the scan. yeah. she gets the pid, she sends the signal, scan's over. 💀
  • -u, --update-vt-info — updates VT info into redis store from VT files. feeding the redis store, one VT file at a time. 🍓

🌈 THE CONFIGURATION FILE 🌈

The default openvas configuration file, /etc/openvas/openvas.conf, contains these options. strap in, there's a lot, and they're all important, no skips:

  • plugins_folder — contains the location of the plugins folder. This is usually /var/lib/openvas/plugins, but you may change this. 💖
  • include_folders — contains the location of the include file folder. This is usually /var/lib/openvas/plugins, but you may change this too. (yes, same default path. no, that's not a typo. 🫶)
  • max_hosts — is the maximum number of hosts to test at the same time, which should be given to the client (which can override it). This value must be computed given your bandwidth, the number of hosts you want to test, your amount of memory and the horsepower of your processor(s). math girlies rise up, this one is your problem. 🧮
  • max_checks — is the number of plugins that will run against each host being tested. Note that the total number of processes will be max_checks x max_hosts, so you need to find a balance between these two options. Also, launching too many plugins at the same time may disable the remote host, either temporarily (i.e.: inetd closes its ports) or definitely (the remote host crashes because it's being asked to do too many things at the same time). so be careful. fr fr. ⚠️
  • log_whole_attack — if this option is set to 'yes', openvas will store the name, pid, date and target of each plugin launched. This is helpful for monitoring and debugging purposes, however this option might make openvas fill your disk rather quickly. amazing for debugging, terrible for your disk situation. 😭
  • db_address — path to the redis socket where the plugins cache and knowledge bases are stored. that's the address, bestie, don't lose it. 📍
  • report_scripts — stores in a file the script run duration in json format. This option expects a valid path to store a file with scripts stats. Script run durations are collected only if the log_whole_attack setting is set to 'yes'. This is helpful for monitoring and debugging purposes, however this option might make openvas fill your disk rather quickly. same warning, same energy. 🍓
  • debug_tls — this is a scanner-only option which allows you to set the TLS log level. The level is an integer between 0 and 9. Higher values mean more verbosity and might make openvas fill your disk rather quickly. The default value is 0 (disabled).

Larger values should only be used with care, since they may reveal sensitive information in the scanner logs. 🙈

Use a debug level over 10 to enable all debugging options.

  • log_plugins_name_at_load — if this option is set to 'yes', openvas will log the name of each plugin being loaded at startup, or each time it receives the HUP signal. she's logging the roster. 📋
  • cgi_path — by default, openvas looks for default CGIs in /cgi-bin and /scripts. You may change these to something else to reflect the policy of your site. The syntax of this option is the same as the shell $PATH variable: path1:path2:.... colon gang, we love you. 🫶
  • port_range — this is the default range of ports that the scanner plugins will probe. The syntax of this option is flexible: it can be a single range ("1-1500"), several ports ("21,23,80"), several ranges of ports ("1-1500,32000-33000"). Note that you can specify UDP and TCP ports by prefixing each range by T or U. For instance, the following range will make openvas scan UDP ports 1 to 1024 and TCP ports 1 to 65535:
"T:1-65535,U:1-1024"
  • test_alive_hosts_only — if this option is set to 'yes', openvas will scan the target list for alive hosts in a separate process while only testing those hosts which are identified as alive. This boosts the scan speed of target ranges with a high amount of dead hosts significantly. skipping the ghosts, only testing the living. ✨
  • alive_test_ports — preference to set the port list for the TCP SYN and TCP ACK alive test methods. This setting overwrites the default port list:
"21-23,25,53,80,110-111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080"
  • test_alive_wait_timeout — this option is to set how long (in sec) Boreas (alive test) waits for replies after the last packet was sent. Default: 3 seconds. ⏱️
  • icmp_retries — this is the default amount of icmp packets that will be sent to the host target during an alive test. Defaults to 1.
  • icmp_grace_period — wait time between icmp packets during alive tests. Useful for sensitive targets. It can slow down the alive test. being gentle with the delicate ones. 🌸
  • optimize_test — by default, optimize_test is enabled, which means openvas does trust the remote host banners and is only launching plugins against the services they have been designed to check. For example, it will check a web server claiming to be IIS only for IIS related flaws, but will skip plugins testing for Apache flaws, and so on. This default behavior is used to optimize the scanning performance and to avoid false positives. If you are not sure that the banners of the remote host have been tampered with, you can disable this option. (yes — trusting banners is the default. if the banners are lying, that's on you. 🙈)
  • optimization_level — level of test optimization. It checks if plugin requirements are met. Level=1 checks only that required ports are open, level=2 checks open ports and keys requirements are met, else checks also if excluded keys are present or not. Default: no optimization, check everything. 👑
  • test_empty_vhost — if set to yes, the scanner will also test the target by using empty vhost value in addition to the target's associated vhost values. double dipping, but make it intentional. 🎀
  • checks_read_timeout — number of seconds that the security checks will wait for when doing a recv(). You should increase this value if you are running openvas across a slow network link (testing a host via a dialup connection for instance). slow net? bigger number. 🐌
  • timeout_retry — number of retries when a socket connection attempt times out. 🔁
  • open_sock_max_attempts — when a port is found as opened at the beginning of the scan, and for some reason the status changes to filtered/closed, it will not be possible to open a socket. This is the number of unsuccessful retries to open the socket before setting the port as closed. This avoids launching plugins which need the opened port as a mandatory key, therefore it avoids an overlong scan duration. If the set value is 0 or a negative value, this option is disabled. It should be taken into account that one unsuccessful attempt needs the number of retries set in "timeout_retry". 💅
  • time_between_request — some devices do not appreciate quick connection establishment and termination, neither quick requests. This option allows you to set a wait time between two actions, like opening a tcp socket, sending a request through the open tcp socket, and closing the tcp socket. This value should be given in milliseconds. If the set value is 0 (default value), this option is disabled and there is no wait time between requests. personal space for your devices. 🫶
  • expand_vhosts — whether to expand the target host's list of vhosts with values gathered from sources such as reverse-lookup queries and VT checks for SSL/TLS certificates. 🔍
  • non_simult_ports — some services (in particular SMB) do not appreciate multiple connections at the same time coming from the same host. This option allows you to prevent openvas from making two connections on the same given ports at the same time. The syntax of this option is "port1[, port2....]". Note that you can use the KB notation of openvas to designate a service formally. Ex:
"139, Services/www"

will prevent openvas from making two connections at the same time on port 139 and on every port which hosts a web server.

  • allow_simultaneous_ips — if set to no, this option prevents openvas from scanning more than one different IPs (e.g. the IPv4 and IPv6 addresses) which belong to the same host at the same time. Default, yes. 💖
  • plugins_timeout — this is the maximum lifetime, in seconds, of a plugin. It may happen that some plugins are slow because of the way they are written or the way the remote server behaves. This option allows you to make sure your scan is never caught in an endless loop because of a non-finishing plugin. Doesn't affect ACT_SCANNER plugins. ⏳
  • scanner_plugins_timeout — like plugins_timeout, but for ACT_SCANNER plugins. (the sequel, the special edition, the director's cut. 🎬)
  • max_vts_timeouts — okay so sometimes during a scan a host just dies mid-conversation 😭 (it shut down, a firewall blocked the traffic, some network device broke the connection, etc.) and you end up with a pile of NVT timeouts and a scan that takes forever. What this option does: once you've hit your configured amount of max NVT timeouts, openvas goes back and re-checks whether that host is even alive. If it's considered dead, the scan for that host gets stopped. If it's still alive? Scan keeps going, bestie. 🫶 Heads up though: this option requires the Boreas alive test to be enabled. Default: option not set, disabled.
  • safe_checks — so most of the time, openvas will straight-up try to reproduce a weird condition to figure out if a remote service is vulnerable to something. Which is great detective work, but it includes reproducing buffer overflows and format strings… and that can crash the remote server 💀. Set this to 'yes' and openvas will disable all the plugins that could crash the remote services, and it'll also make a bunch of checks rely on the service's banner instead of how it behaves when you poke it with a certain input. Upsides? Fewer false positives and openvas is way nicer to your network ✨. Downside? You might miss important vulnerabilities, because a vuln affecting one service can totally affect another one too. 🙈
  • auto_enable_dependencies — OpenVAS plugins live in each other's business, fr fr — they use each other's results to do their job. Like, a plugin that logs into the remote SMB registry needs the results from the plugin that found the remote host's SMB name, and the results from the plugin that actually logs into the remote host. If you only want to select a subset of the available plugins, tracking all those dependencies by hand gets tiresome SO fast. Set this to 'yes' and openvas will automatically enable the plugins that are depended on. Slay. 💅
  • hosts_allow — comma-separated list of the only targets that are authorized to be scanned. Same syntax as the list targets. Both the target hostnames and the address they resolve to get checked. But — plot twist — hostnames in the hosts_allow list are not resolved.
  • hosts_deny — comma-separated list of targets that are not authorized to be scanned. Same syntax as the list targets. Both target hostnames and the address they resolve to get checked. And same as above: hostnames in the hosts_deny list are not resolved. ✨
  • sys_hosts_allow — same energy as hosts_allow. But this one can't be overridden by the client. 👑
  • sys_hosts_deny — like hosts_deny. Also can't be overridden by the client. 👑
  • max_sysload — maximum load on the system. Once you hit this load, no further VTs get started until the load drops below this value again.
  • min_free_mem — minimum available memory, in MB, that should be kept free on the system. Once you hit this limit, no further VTs are started until there's enough memory available again.
  • max_mem_kb — maximum amount of memory (in MB) allowed for a single script. If you set this, the amount of memory put into redis is tracked for every Script. If it exceeds this limit, the script can't set any more kb items. Important caveat: the tracked value written into redis is only an estimate, since it doesn't check whether a value was replaced or appended. And the size of the key isn't tracked either. If this value isn't set or is <= 0, the maximum amount is unlimited — that's the default.
  • unscanned_closed — this defines whether TCP ports that were not scanned should be treated like closed ports. Defaults to "yes".
  • unscanned_closed_udp — this defines whether UDP ports that were not scanned should be treated as closed ports. Defaults to "yes". (See what they did there, matching names and everything 🎀)
  • table_driven_lsc — turns on table driven local security Checks, aka LSC. Meaning: gathered packages get sent off to a specialized scanner. This is way more efficient than doing checks via NASL. Defaults to true. 🔥
  • mqtt_server_uri — URI to the MQTT server used for internal communication with Notus (that's the table driven LSC). Heads up: this implementation of Notus is in python and it is deprecated, because it's being replaced with a Rust implementation of Notus.
  • mqtt_user — username for authenticated MQTT communication.
  • mqtt_pass — password for authenticated MQTT communication.
  • openvasd_server — Openvasd server URI to the Rust implementation of Notus. It has priority over the MQTT settings. 👑
  • x-apikey — API Key to authenticate against openvasd when the Notus Rust implementation is enabled.
  • nasl_no_signature_check — enable/disable the Feed signacture check. And pay attention, bestie: this setting has negative logic. 🙈

The other options in this file can usually be redefined by the client.

🌐 NETWORK USAGE 🌐

Buckle up, because OpenVAS can be quite network intensive. Even though the OpenVAS developers have taken every effort to avoid packet loss — transparently resending UDP packets, waiting for data to be received in TCP connections, etc. — bandwidth use should always be closely monitored. With current server hardware, bandwidth is usually the bottleneck in an OpenVAS scan. And it might not even be that obvious in the final reports: scanners will still run, holes might get detected, but you risk running into false negatives — meaning OpenVAS will not report a security hole that's actually present in a remote host. 😭

If you're running the scanner in low bandwidth conditions (low = less bandwidth than the one your hardware system can produce), you might need to tune the OpenVAS configuration, or otherwise you'll get erratic results. There are several parameters you can modify to reduce network load:

  • checks_read_timeout — the default value is set to 5 seconds. You can (and should) increase it if network bandwidth is low, in the openvas.conf or openvasrc configuration files. Also, it's recommended to bump this value over 10 seconds if you're running a test outside your LAN (like against Internet hosts through an Internet connection).
  • max_hosts — number of hosts to test at the same time. It can be as low as you want (obviously 1 is the minimum).
  • max_checks — number of checks to test at the same time. It can be as low as you want, and lowering it will also reduce network load and improve performance (obviously 1 is the minimum). Notice that OpenVAS will spawn max_hosts * max_checks processes. 👀
  • drop_privileges — if this preference is set to 'yes', OpenVAS will attempt to drop its root privilege before launching any VT, and the new process owner is 'nobody'. The default value of this preference is 'no', meaning no change in behaviour.
  • nasl_drop_privileges_user — if a user is set, NASL functions can use this user to drop its root privilege. The new process owner is set only for those process calling a NASL function which supports a drop privileges action. This preference must not be mixed with 'drop_privileges'. If 'drop_privileges' is enabled, this option should not be used, as 'drop_privileges' sets the owner to
  • vendor_version — use the alternate vendor instead of the default one during scans.

Other options might be using the QoS features offered by your server operating system or your network to improve the bandwidth use.

It's not easy to give a bandwidth estimate for an OpenVAS run — you'll probably need to make your own counts. But say you test 65536 TCP ports. That requires at least a single packet per port, at least 40 bytes large. Add 14 bytes for the ethernet header and you'll send 65536 * (40 + 14) = 3670016 bytes. So just probing all TCP ports may need a multitude of that, since nmap will try to resend the packets twice if no response is received.

A very rough estimate: a full scan for UDP, TCP and RPC as well as all NASL scripts may result in 8 to 32 MB worth of traffic per scanned host. Reducing the amount of tested part and such will reduce the amount of data to be transferred significantly. 💅

👀 SEE ALSO 👀

gvmd(8), gsad(8), ospd-openvas(8), openvas-nasl(1), openvas-nasl-lint(1),

🌈 MORE INFORMATION 🌈

The canonical places where you'll find more information about OpenVAS are:

  • Community Portal
  • Development Platform
  • Traditional home site

💖 AUTHORS 💖

openvas was forked from nessusd in 2005. Nessusd was written by Renaud Deraison <deraison@cvs.nessus.org>. Most new code since 2005 developed by Greenbone AG.

And that's the whole page, bestie, we made it 🫶✨ This one's from Greenbone Vulnerability Manag… (the source line, they ran out of room, iconic honestly), and it's dated February 2021, and it lives in section OpenVAS(8). Go forth and scan responsibly. 💅🎀

📦 where this page comes from