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.

Hi. I was battling this same issue for hours on Friday. I gave up and came back fresh at it today. This led me to this topic where joebeasley clued me into Linux blocking port binding below 1024. Up until this point I thought is was something up with my GVM/GSAD setup…

I googled ‘debian allow use of port 80’, which presented me with this this link: https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443

I ended up using Option1 under Jason C’s answer.

The solution for me, at least until I learn more, was executing the following command:

sudo setcap CAP_NET_BIND_SERVICE=+eip /usr/local/sbin/gsad

This allowed for binding the gsad binary to ports below 1024.

Please let me know if there is something inherently more risky using the setcap method.

…Rob

edit service gsad to this content
after that web interface will be available on port 80

[Unit]

Description=Greenbone Security Assistant daemon (gsad)

Documentation=man:gsad(8) https://www.greenbone.net

After=network.target gvmd.service

Wants=gvmd.service

[Service]

Type=forking

RuntimeDirectory=gsad

RuntimeDirectoryMode=2775

PIDFile=/run/gsad/gsad.pid

ExecStart=/usr/local/sbin/gsad --drop-privileges=gvm

Restart=always

TimeoutStopSec=10

[Install]

WantedBy=multi-user.target

Alias=greenbone-security-assistant.service