Quarantine Web Interface Via Nginx Proxy

From Proxmox Mail Gateway
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Introduction

Proxmox Mail Gateway can be configured to quarantine mail, instead of delivering potentially dangerous content to users directly. If a mail is detected as spam users themselves can decide whether they want to keep or delete it in the user quarantine interface. (for dangerous content, as mail containing viruses, or potentially dangerous attachments, the administrator needs to decide whether to pass the mail on or delete it).

In certain environments it is desired to provide the user quarantine interface at a specific host and port, e.g. in order to only allow access to the interface from outside on port 443, or to provide a different and trusted certificate to your users.

The following Howto describes a small nginx configuration, which only exposes the paths necessary for user quarantine interface access, while preventing access to other parts of the API.

Keep in mind that this provides mostly cosmetic protection, since all paths in the Proxmox Mail Gateway API, apart from the login path are only available to authenticated users anyways. The unprotected login path needs to be forwarded for the quarantine access as well.

For creating a general reverse proxy for the complete web interface refer to the Howto in the Proxmox VE wiki.

Installing nginx

The Howto creates a configuration suitable for nginx. You can install nginx on your Proxmox Mail Gateway using apt

apt install nginx

Creating a site to proxy requests for quarantine

The following configuration is a minimal working nginx-site to proxy all requests necessary for accessing the quarantine interface for users. You should adapt it to your site's requirements. This includes:

  • changing the path to the used certificates
  • setting the proper server_name
  • adapting the ssl-configuration parameters to current best practices
  • if the proxy server is running on another host adapting the url for the proxy_pass directives


To get the site running write the config to /etc/nginx/sites-available/pmg-quarantine.conf and symlink it to /etc/nginx/sites-enabled:

ln -rs /etc/nginx/sites-available/pmg-quarantine.conf /etc/nginx/sites-enabled/


server {
    listen 80 default_server;
    rewrite ^(.*) https://$host$1 permanent;
}
 
server {
    listen 443;
    server_name _;
    ssl on;
    ssl_certificate /etc/pmg/pmg-api.pem;
    ssl_certificate_key /etc/pmg/pmg-api.pem;
    proxy_redirect off;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade"; 
    proxy_set_header PVEClientIP $remote_addr; 
    proxy_buffering off;
    client_max_body_size 0;
    proxy_connect_timeout  3600s;
    proxy_read_timeout  3600s;
    proxy_send_timeout  3600s;
    send_timeout  3600s;
    
    # proxy requests for static components
    location ~ /proxmoxlib.js$|/favicon.ico$|/pve2/|/fontawesome/|/framework7/|/pwt/ {
        proxy_pass https://localhost:8006;
    }
    location /quarantine {
        proxy_pass https://localhost:8006;
    }

    location /api2 {
        location ~ /api2/(extjs|json|htmlmail)/(access/ticket$|version$) {
            proxy_pass https://localhost:8006;
        }
        location ~ /api2/(extjs|json|htmlmail)/nodes/.+/subscription$ {
            proxy_pass https://localhost:8006;
        }
        location ~ /api2/(extjs|json|htmlmail)/quarantine {
            proxy_pass https://localhost:8006;
        }
        return 403;
    }

    location / {
        return 403;
    }
}
 

NOTE: if you're using the integrated ACME implementation with the standalone plugin you need to remove the server on port 80 above, since the ACME implementation needs to bind to it during certificate renewal