21.4.4 url only reachable through 9392

Hi,
i am running gvm version 21.4.4.
After the setup i added ssl certificates in order to communicate gvm over https.
But gvm is only reachable if i give the whole URL + port e.g. “https://gvm.subdomain.de:9392
So it speaks https over 9392, but is there a way to reach the url without giving the portnumber?

best regards

Hi @alessio,

if you are running it on a Linux machine, you can achieve it by managing incoming traffic to port 443 through Nginx proxy to default port 9392.

More info like NGINX Reverse Proxy | NGINX Plus

1 Like

Hi,
ah okay thanks, can do that. I just thought since gvm is running on nginx, there already may be a config which i can modify?

Found this old configuration I used for OpenVAS 9 or whatever it was. You may use this and re-configure to set up the reverse proxy to work with GVM 21.04 you probably have to adjust it some tho.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name openvas.example.com;

    allow 127.0.0.1;
    allow VPN_IP;
    deny all;

    ssl_certificate /etc/nginx/ssl/openvas.example.com/500232/server.crt;
    ssl_certificate_key /etc/nginx/ssl/openvas.example.com/500232/server.key;

    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/dhparams.pem;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options "nosniff";

    index index.html index.htm index.php;

    charset utf-8;

    include conf/openvas.example.com/server/*;

    location / {
        proxy_set_header   Host             $http_host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   REMOTE_HOST      $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_set_header   X-FORWARDED-PROTOCOL $scheme;  
        proxy_pass https://127.0.0.1:9392;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/openvas.example.com-error.log error;

    location ~ /\.(?!well-known).* {
        deny all;
    }
}
3 Likes

Hi,

seems to be a good option, in config is missing a forced rewrite when you call port 80, but basically, it should work.

2 Likes

Modify /lib/systemd/system/greenbone-security-assistant.service.

Change --port=9392 to --port=443.

Run systemctl daemon-reload.

Restart the gvmd service.

1 Like

I don’t think that works in 21.4.4… well, at least not for me. If I change the port, gsad just doesn’t start

/usr/bin/gvm-start is a bash script. It has a setting for the port that must be changed to 443 also.

Near the bottom…
image

I verified this on a new install running 21.4.4.

1 Like

Thank you, JoeBeasley.

Unfortunately, there is no /gvm-start under /usr/bin or anywhere else in the system.

I built this system based on the instructions at https://greenbone.github.io/docs/gvm-21.04/index.html#setting-the-version

Near the bottom, you created a file called gsad.service. That file was copied to /etc/systemd/system. You must modify it and change the port to 443. After saving, run “systemctl daemon-reload” and restart the service.

Morning Joe,
As I indicated before, I have done that.
Anytime I change the port for gsad on the configuration file under /etc/systemd/system/gsad.service (from 9392 to 443 or even 80), the service just doesn’t come back.

systemctl daemon-reload

service gsad restart

Job for gsad.service failed because a timeout was exceeded.
See “systemctl status gsad.service” and “journalctl -xe” for details.

systemctl status gsad.service

gsad.service - Greenbone Security Assistant daemon (gsad)
Loaded: loaded (/etc/systemd/system/gsad.service; enabled; vendor preset: enabled)
Active: activating (start) since Mon 2022-05-02 13:19:55 UTC; 1min 5s ago
Docs: man:gsad(8)
https://www.greenbone.net
Process: 233582 ExecStart=/usr/local/sbin/gsad --listen=server ip address --port=443 --http-only (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 1065)
Memory: 216.0K
CGroup: /system.slice/gsad.service

It never changes from “Activating - start”

Thanks

What is in /var/log/gvm/gsad.log ?

Before the change:
gsad main:WARNING:2022-05-02 13h04.15 utc:232457: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h05.45 utc:232539: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h05.45 utc:232540: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h05.45 utc:232541: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h07.16 utc:232621: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h07.16 utc:232622: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h07.16 utc:232623: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h08.46 utc:232703: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h08.46 utc:232704: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h08.46 utc:232705: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h10.17 utc:232938: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h10.17 utc:232939: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h10.17 utc:232940: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h10.17 utc:232941: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h10.17 utc:232942: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h10.17 utc:232943: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h11.47 utc:233036: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h11.47 utc:233037: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h11.47 utc:233038: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h13.18 utc:233140: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h13.18 utc:233141: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory
gsad main:WARNING:2022-05-02 13h13.18 utc:233142: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h14.48 utc:233223: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h14.48 utc:233224: main: Could not load private SSL key from /var/lib/gvm/private/CA/serverkey.pem: Failed to open file “/var/lib/gvm/private/CA/serverkey.pem”: No such file or directory

After the change:
gsad main:WARNING:2022-05-02 13h14.48 utc:233225: main: start_http_daemon redirect failed !
gsad main:MESSAGE:2022-05-02 13h15.24 utc:233329: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h15.24 utc:233340: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h16.54 utc:233418: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h16.54 utc:233419: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h18.24 utc:233503: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h18.24 utc:233504: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h19.55 utc:233582: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h19.55 utc:233583: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h21.26 utc:233667: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h21.26 utc:233668: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h22.56 utc:233746: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h22.56 utc:233747: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h24.26 utc:233829: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h24.26 utc:233830: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h25.57 utc:233911: Starting GSAD version 21.4.4
gsad main:CRITICAL:2022-05-02 13h25.57 utc:233912: main: start_https_daemon failed!
gsad main:MESSAGE:2022-05-02 13h27.27 utc:233994: Starting GSAD version 21.4.4

I’m testing this on Debian 11 Bullseye. Kernel 5.10.0-13. Here is what I found.

Debian is not allowing the service to start on ports below 1024. I thought the User= and Group= lines in gsad.service took care of that, but apparently not.

I could only get the service to start with port 443 if I changed the gsad.service lines to…
User=root
Group=root

I also added the --drop-privileges=gvm option to the end of the ExecStart line. This leaves the gsad process running as user gvm.

The service wants ssl certificates, so I had to run …
sudo gvm-manage-certs -a

Give gvm user ownership to the certificates with …
sudo chown -R gvm:gvm /var/lib/gvm

The ExecStart line looks like this…
ExecStart=/usr/local/sbin/gsad --port=443 --no-redirect --drop-privileges=gvm

I am not a developer, so I don’t know why the gsad.service file is not starting the process as root, and then dropping privileges the way it should.

Hope this helps.

Thank you. That allowed the service to start. I am also curious about the issue. Hopefully one of the developers chime in here and let us know. Thanks again for all your help.

1 Like

Looks like if you remove the User= and Group= lines it runs as root. Adding the --drop-privileges=gvm leaves the gsad process running as user gvm.