Apache Guacamole behind nginx reverse proxy strange headers - eviltoast

Hello, I installed Apache Guacamole using this script: https://github.com/MysticRyuujin/guac-install

I am using nginx as a reverse proxy to forward to the guacamole host… Nginx conf (redirect to 443 is set in default conf):

server { listen 443 ssl; server_name vm.domain.com;

ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;

location / {
proxy_pass http://IP-ADDRESS:8080/guacamole;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
access_log off;

} }

If I open “vm.domain.com” it shows me the nginx welcome page. If I open “vm.domain.com/guacamole” it shows me the guacamole page, but strange field-names (never seen this before…). When I open it by using the local IP, everything is fine.

So how do I change the tomcat9 default path, that I don’t have to use “vm.domain.com/guacamole” just “vm.domain.com” (also with local ip)? And how do I get it shown right?

  • latkde@alien.topBEnglish
    2·
    1 year ago

    So how do I change the tomcat9 default path, that I don’t have to use “vm.domain.com/guacamole” just “vm.domain.com”

    Unfortunately, you don’t. Not even the Guacamole Docker container does this.

    I would configure Nginx to redirect from / to /guacamole/. You could also try reconfiguring Tomcat. Perhaps renaming the guacamole.war to ROOT.war is enough, but I vaguely remember that Tomcat is more tricky than that.

    Looks like the Guacamole web frontend doesn’t know it is being proxied, and generates some links to translation resources using an absolute path.

    Also, a security note: absolutely do not run guacd (the guacamole-server component) as unconfined root or on a publicly accessible port. Guacd has no authentication, and could thus be used as an open proxy by attackers (also to look into your network). Guacd is also written in C, and not in an overly security-conscious manner. It is likely that the code contains quite some vulnerabilities.

    The easiest way to harden guacd is to run it in a Docker container and to “bind” it to localhost (not 0.0.0.0). So instead of docker run --rm -p 4822:4822 my-guacd-image you might specify the port as -p 127.0.0.1:4822:4822, which only allows incoming connections from within the server. (But you might not want a separate network namespace at all, especially since this affects the destination IP address for your VNC connections. Then, use --net=host for Docker and set localhost in the guacd config file).

    Instead of running in a container, it may be acceptable to use Systemd options for hardening, in particular running as a separate user. Use systemd-analyze security to get suggestions about Systemd features that might be beneficial.