OpenVAS
Siehe auch
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
- Links:
Homepage: http://www.openvas.org
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
:
4 Errors.
8 Critical situation.
16 Warnings.
32 Messages.
64 Information.
128 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 demgvm-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:
[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):
<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 inrsync: 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 ZeileCOMMUNITY_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:
[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
Built on 2024-09-30