Hint: Redis setup / configuration for GSE/GVM/OpenVAS

cfi · 2019-05-01 06:52:53 UTC

Redis Setup

Note: If you have any questions on this topic please start a new thread for each question and link back to this topic so that it can be updated accordingly.

When running a GSE/GVM/OpenVAS setup build from source please pay special attention on the setup / configuration of Redis for a smooth operation of your whole setup. If you’re facing issues with your scans please see the “Common issues” section below.

The following documentation is guiding you through this setup:

github.com

greenbone/openvas-scanner/blob/v5.1.3/INSTALL#L100-L113


3) The scanner needs a running redis server to temporarily store information
   gathered on the scanned hosts. Redis 2.4 and newer is supported but 2.6
   is recommended. See doc/redis_config.txt to see how to setup and run a redis
   server.


   Two examples are installed which you may use directly for a quick start:


   $ redis-server /share/doc/openvas-scanner/example_redis_2_4.conf


   or


   $ redis-server /share/doc/openvas-scanner/example_redis_2_6.conf


   or copy the example to another location, edit and use the copy instead.

github.com

greenbone/openvas-scanner/blob/v5.1.3/doc/redis_config.txt

= Redis KB server =

== Presentation ==
Redis (http://redis.io) is used to store and access the KB. Scans won't run if
they cannot access the server and might be significantly slowed down if redis is
not properly configured.

The feature has been developed with neither cluster mode nor replication
enabled. Redis 2.4 and 2.6 are supported. Versions 2.6 and higher are
recommended.


== Connection ==
OpenVAS can currently only access redis via a unix socket. This choice has been
made for the sake of speed and security. No authentication is supported yet, we
rely on filesystem permissions to protect the KBs.

The path to the unix socket is '/tmp/redis.sock' by default, and can be changed
using the 'kb_location' parameter.

This file has been truncated. show original

Common issues

Scanning larger target ranges causing the scan to stuck at 1% for longer time

Note: There was a bug in the openvassd causing the same impact. Please make sure that you’re using the latest components announced in GVM-10 (stable, initial release 2019-04-05) and GVM-9 (old stable, initial release 2017-03-07).

This issue might show up if your databases number in your redis.conf is configured with a too low number. Please see the previously linked redis_config.txt how to calculate the database number.

Scanner / openvassd startup is timing out

If your scanner startup (example of systemd) is timing out with one of the following messages:

Redirecting to /bin/systemctl start  openvas-scanner.service.service
Job for openvas-scanner.service failed because a timeout was exceeded.
See "systemctl status openvas-scanner.service" and "journalctl -xe" for details.

systemd[1]: openvas-scanner.service: Start operation timed out. Terminating.
systemd[1]: Failed to start LSB: remote network security auditor - scanner.
systemd[1]: openvas-scanner.service: Unit entered failed state.
systemd[1]: openvas-scanner.service: Failed with result 'timeout'.

revisit your Redis setup with the resources mentioned above. The following steps are known to work and to solve this issue:

Delete the file dump.rdb (Located in e.g. /var/run/redis depending on your setup)
Comment out/remove all save xy z (e.g. save 900 1) from your redis.conf (Located in e.g. /etc/redis depending on your setup)
Optional: Flush your redis database (Depending on your setup, e.g. redis-cli -s /var/run/redis/redis.sock flushall)
Restart redis (Depending on your setup, e.g. service redis-server restart)
Restart the Scanner (openvassd) and try again

bricks · 2018-11-27 09:31:09 UTC

cfi · 2018-11-29 06:34:47 UTC