Harden GRR Frontend Behind Nginx with Client Cert Auth

This nginx configuration reverse-proxies the GRR frontend, terminates TLS, and enforces mutual TLS (mTLS) for admin access while allowing clients to connect with their own certificates. Internally, nginx listens on 443, validates the client certificate against the CA you configured during GRR installation, and passes the verified subject DN to GRR via a header. GRR's frontend then maps that DN to a user account or client record. The proxy also sets strict timeouts because GRR's long-poll client connections can idle for minutes, and a short proxy_read_timeout will cause constant reconnects and log spam.

Production use case: any internet-facing or cross-trust-zone GRR deployment. By requiring mTLS for the admin UI, you eliminate password-based attacks on the frontend entirely. Endpoints still authenticate with their own client certificates, so you get mutual authentication in both directions. This is the recommended pattern in the GRR deployment guide for multi-tenant or DMZ deployments.

Security implications: without mTLS, the GRR admin UI is a single password away from full estate read access. With mTLS plus an IP allowlist plus approval workflows, you have defense in depth. Performance impact is minimal: TLS handshake overhead is amortized over long-poll connections. Common pitfalls include forgetting to set proxy_buffering off, which breaks GRR's streaming responses; setting client_max_body_size too low, which rejects large flow result uploads; and not forwarding the X-Forwarded-For header, which makes all audit logs show the proxy IP. Always verify with openssl s_client that the client cert chain is presented.

> System.Execute()

server {
    listen 443 ssl http2;
    server_name grr.corp.local;

    ssl_certificate     /etc/nginx/tls/grr.crt;
    ssl_certificate_key /etc/nginx/tls/grr.key;
    ssl_client_certificate /etc/nginx/tls/grr-ca.crt;
    ssl_verify_client on;

    client_max_body_size 2048m;
    proxy_buffering off;
    proxy_read_timeout 900s;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-SSL-Client-DN $ssl_client_s_dn;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

> Architecture & Security Context

Verified for Valters IT Hub. When deploying this configuration in a production homelab or enterprise environment, ensure that you monitor system resources and implement strict access controls. Administrator privileges are required.

ID: VALTERSIT-7207531548D9