OpenVAS¶

Siehe auch

Verwandte Artikel

OpenVAS als ehemaliger Fork von Nessus ist heute Teil des Greenbone Vulnerability Management Frameworks. Es arbeitet unter der Haube mit PostgreSQL und Redis. Angriffs-Skripte werden in NASL geschrieben.

An der OpenVAS-Maschine sollte man nicht sparen: 4 CPU-Cores und 4 GB RAM sollten es mindestens sein. Je mehr, desto besser, da die Scans parallelisiert werden können.

Container-Tasks können selbst nicht laufen, sondern werden verwendet, um Reports zu importieren.

Tipp

Es sollten maximal soviele NVTs parallel gegen einen Host zu testen, wie CPU-Cores zur Verfügung stehen.

Begriffe

GMP: Greenbone Management Protocol - Protokoll zur Steuerung und Konfiguration von OpenVAS
gsa: Greenbone Security Assistant
gsad: Greenbone Security Assistant Daemon
gsd: Greenbone Security Desktop
GSM: Greenbone Security Manager
GVM: Greenbone Vulnerability Management - Framework, in dem OpenVAS als ein Teil integriert ist
gvmd: GVM Manager
NASL: Nessus Attack Scripting Language
NVT: Network Vulnerability Test
OMP: OpenVAS Management Protocol
OpenVAS: Open Vulnerability Assessment Scanner
openvasmd: OpenVAS Manager Daemon
openvassd: OpenVAS Scanner Daemon (ab GVM-11 zum Kommandozeilentool „openvas“ mutiert, kontrolliert von „ospd-openvas“)
OSP: Open Scanner Protocol - durch OpenVAS für Scanner-Management und -Kontrolle verwendet

Installation¶

Siehe unbedingt auch https://github.com/greenbone/gvmd/blob/main/INSTALL.md.

Installation OpenVAS 20 (von 2021-03) auf CentOS 8.

Vorarbeiten:

SELinux muss leider abgeschaltet werden („disabled“; „permissive“ genügt nicht, dann beschwert sich das OpenVAS-Setup).
EPEL-Repo aktivieren.
Atomicorp-Repo aktivieren.
PowerTools-Repo aktivieren: dnf -y install yum-utils; yum config-manager --set-enabled PowerTools

dnf -y install gvm

# This takes time - feed sync runs with max 400 KB/sec.
gvm-setup

Wichtig: die Maschine braucht auf der zentralen Firewall die Erlaubnis, Daten aus dem Internet per rsync zu beziehen. Ein lokal laufendes firewalld wird automatisch konfiguriert.

gvm-setup übernimmt auch Konfigurationen per sysctl, Optimierungen für Redis etc.

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl -p
systemctl restart redis

# little bugfix
chmod g-w /var/log/gvm

Aufruf des OpenVAS Admin-Interfaces über https://openvas.

Systemdienste prüfen:

systemctl status gsad
systemctl status gvmd
systemctl status ospd-openvas
systemctl status redis

Um OpenVAS auf einem aktuellen Stand zu halten, genügt:

yum -y update

su - gvm -c "/usr/bin/greenbone-nvt-sync"
su - gvm -c "/usr/sbin/greenbone-feed-sync --type GVMD_DATA"
su - gvm -c "/usr/sbin/greenbone-feed-sync --type SCAP"
su - gvm -c "/usr/sbin/greenbone-feed-sync --type CERT"
su - gvm -c "openvas --update-vt-info"

Bemerkung

Der letzte Befehl benötigt 30 Minuten und länger, um den globalen DB-Index in Redis neu aufzubauen. Abgeschlossen ist der Rebuild mit update_scap_end: Updating SCAP info succeeded in /var/log/gvm/gvmd.log (INFO).

Die dazu passenden crontab-Einträge legt sich OpenVAS unter /etc/cron.daily/gvm gleich selbst an.

OpenVAS beobachtet man bei der Arbeit mit:

tail -f /var/log/messages /var/log/redis/redis.log /var/log/gvm/*log

Log-Level in /etc/gvm/gvmd_log.conf und /etc/openvas/openvas_log.conf:

Errors.
Critical situation.
Warnings.
Messages.
Information.
Debug.  (Lots of output.)

Konfiguration¶

Overrides

Beispiel: „TCP timestamps“-Findings werden mit 2.0 bewertet. Im Result auf das Finding klicken, oben rechts bei Actions > Add new Override:

New Severity: Log
Text: This is not an issue.

Kommandozeilentool und API¶

Vormals: omp
Spätestens seit Version 20: gvm-cli aus dem gvm-tools-Paket

Die rudimentäre API-Doku findet sich hier:

Installation:

dnf -y install python3-defusedxml python3-lxml python3-paramiko
dnf -y install gvm-tools

Der Client liegt anschliessend in /usr/lib/python3.6/site-packages/gmp/clients/gvm_cli.py

Einfachste Verwendungsbeispiele:

gvm-cli --help
gvm-cli socket --help
gvm-cli socket --sockpath /run/gvm/gvmd.sock --xml '<get_version/>'
gvm-cli socket --sockpath /run/gvm/gvmd.sock --gmp-username admin --gmp-password password --xml '<get_tasks/>'
gvm-cli socket --sockpath /run/gvm/gvmd.sock --gmp-username admin --gmp-password password --xml '<get_assets type="host"/>'
gvm-cli socket --sockpath /run/gvm/gvmd.sock --gmp-username admin --gmp-password password < file

Um die Credentials nicht auf der Kommandozeile angeben zu müssen:

~/.config/gvm-tools.conf¶

[Auth]
gmp_username=admin
gmp_password=password

Danach:

gvm-cli socket --sockpath /run/gvm/gvmd.sock --config ~/.config/gvm-tools.conf --xml "<get_tasks/>"

Ausführlichere Verwendungsbeispiele (in ein XML-File packen und per < myfile.xml an gvm-cli senden):

Target erzeugen¶

<create_target>
    <name>Test Test</name>
    <comment></comment>
    <hosts>10.80.32.228</hosts>
    <exclude_hosts></exclude_hosts>
    <port_list id="33d0cd82-57c6-11e1-8ed1-406186ea4fc5"></port_list>
    <reverse_lookup_only>0</reverse_lookup_only>
    <reverse_lookup_unify>0</reverse_lookup_unify>
    <alive_tests>Consider Alive</alive_tests>
</create_target>

Tipp

Eine XML-Datei kann beliebig viele create-Definitionen enthalten.

Troubleshooting¶

Host dead

Ziel wird nicht gescannt? Im Log findet sich „Host is dead“? Das Ziel hat Pings gesperrt, OpenVAS gibt dann per Default auf. Abhilfe: Unter „Configuration > Targets > Edit Target > Alive Test: Consider Alive“ setzen.

gmp.gvm_connection.GMPError: Only command GET_VERSION is allowed before AUTHENTICATE

GVM-Tools: man ist nicht authentifiziert.

OSError: Connection was closed by remote server

GVM-Tools: Invalides XML.

Redis: „Opening Unix socket: bind: Address already in use“

In dem Fall liegt vor dem Start des Redis-Caches eine /tmp/redis.sock rum. Diese löschen.

Der Aufruf von /usr/sbin/greenbone-scapdata-sync, /usr/sbin/greenbone-nvt-sync oder /usr/sbin/greenbone-certdata-sync endet in rsync: failed to connect to feed.openvas.org (89.146.224.58): Connection timed out (110)

Die URL-Angaben zur Feed-Location sind veraltet und müssen umkonfiguriert werden. Nur zahlende Kunden dürfen per SSH (24/tcp - kein Tippfehler) und HTTPS auf feed.openvas.org zugreifen. Community-Server müssen feed.community.greenbone.net (rsync 873/tcp) verwenden, was man direkt in den Shell-Scripten (also in /usr/sbin/greenbone-scapdata-sync usw.) in der Zeile COMMUNITY_SCAP_RSYNC_FEED= ändert.

gvmd: database is wrong version

su gvm
gvmd --migrate

Could not connect to Scanner at /var/run/ospd/ospd.sock, OSP start_scan: Could not connect to Scanner (/var/log/gvm/gvmd.log)

OSPD muss seine Socket-Datei woanders ablegen, damit gvmd darauf zugreifen kann:

/etc/systemd/system/ospd-openvas.service¶

[Unit]
Description=Job that runs the ospd-openvas daemon
Documentation=man:gvm
After=postgresql.service

[Service]
Type=simple
User=gvm
Group=gvm
WorkingDirectory=/var/lib/gvm/
Environment=PYTHONPATH=/opt/atomicorp/lib/python3.8/site-packages
PIDFile=/var/run/ospd/ospd-openvas.pid
ExecStart=/opt/atomicorp/bin/ospd-openvas --pid-file /var/run/ospd/ospd-openvas.pid --unix-socket=/var/run/ospd/ospd.sock --log-file /var/log/gvm/ospd-scanner.log --lock-file-dir /var/run/gvm/
Restart=on-failure
RestartSec=2min
KillMode=process
KillSignal=SIGINT
GuessMainPID=no
PrivateTmp=true

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl restart ospd-openvas