21.4.4 url only reachable through 9392

alessio · November 22, 2021, 10:42am

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

heewey · November 22, 2021, 11:46am

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

alessio · November 22, 2021, 12:00pm

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?

libellux · November 23, 2021, 5:47pm

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;
    }
}

heewey · November 24, 2021, 7:45am

Hi,

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

joebeasley · December 13, 2021, 3:05pm

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

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

Run systemctl daemon-reload.

Restart the gvmd service.

juanmachado · April 28, 2022, 3:44pm

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

joebeasley · April 28, 2022, 9:32pm

/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…

I verified this on a new install running 21.4.4.

juanmachado · April 29, 2022, 12:40pm

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

joebeasley · April 30, 2022, 5:08am

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.

juanmachado · May 2, 2022, 1:24pm

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

joebeasley · May 2, 2022, 2:13pm

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

juanmachado · May 2, 2022, 2:52pm

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

joebeasley · May 2, 2022, 7:35pm

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.

juanmachado · May 2, 2022, 8:15pm

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.

joebeasley · May 3, 2022, 6:31pm

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.

RobbieRob · August 1, 2022, 1:32pm

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

sedi · August 3, 2022, 4:11pm

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