cis-nginx-v300-3-4

CIS 3.4 — Ensure proxies pass source IP information

Profile Applicability

• Level 1 - Proxy
• Level 1 - Loadbalancer

Description

When NGINX acts as a reverse proxy or load balancer, it terminates the client connection and opens a new connection to the upstream application server. By default, the upstream server sees the NGINX server's internal IP address as the source, obscuring the original client IP. Standard HTTP headers like X-Forwarded-For and X-Real-IP must be explicitly configured to pass the original client's IP address and protocol information to the backend application.

Rationale

Visibility of the true client IP address is essential for security auditing, incident response, and access control within the backend application. Without forwarding this information:

1. Forensics: Application logs will show all traffic coming from the NGINX proxy IP, making it impossible to trace malicious activity to a specific attacker.
2. Access Control: Application-level IP allow/deny lists or rate limits will fail or mistakenly block the entire proxy.
3. Compliance: Accurate logging of the user origin is often a regulatory requirement.

Impact

Enabling these headers allows the backend application to see the original client IP. However, if NGINX simply appends to an existing X-Forwarded-For header sent by a malicious client, the backend might be tricked into trusting a spoofed IP at the beginning of the list.

Audit Procedure

1. Verify Configuration:

Check the active configuration for proxy header directives in proxied locations:

nginx -T 2>/dev/null | grep -E "proxy_set_header (X-Real-IP|X-Forwarded-For)"

Evaluation:

• Presence: Verify that proxy_set_header X-Forwarded-For and proxy_set_header X-Real-IP are present in location blocks that use proxy_pass (or grpc_pass, fastcgi_pass).
• Correctness:
  • X-Forwarded-For should typically use $proxy_add_x_forwarded_for (to preserve the chain) or $remote_addr (if NGINX is the first trusted hop).
  • X-Real-IP should use $remote_addr.
• Scope: Check that this is applied to all relevant proxied locations.

Remediation

Configure NGINX to forward client IP information in your server or location blocks where proxy_pass is used.

Configuration Example:

location / {
    # Use 'https' for Zero Trust environments (requires proxy_ssl_verify configuration)
    # Use 'http'  for standard TLS offloading (upstream traffic is unencrypted)
    proxy_pass <protocol>://example_backend_application;

    # Standard header: Appends the client IP to the list of proxies
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;

    # NGINX-specific header: Sets the direct client IP (useful for apps expecting a single value)
    proxy_set_header X-Real-IP         $remote_addr;

    # Recommended: Forward the protocol (http vs https)
    proxy_set_header X-Forwarded-Proto $scheme;
}

Default Value

By default, NGINX does not add these headers. The upstream server receives requests appearing to originate from the NGINX server's IP address.

References

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For
2. https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header

Additional Information

Privacy: Users' privacy should be considered when forwarding client IP addresses. Ensure your organization's privacy policy discloses the collection and processing of IP address information.

Security Trust: Any information in the X-Forwarded-For header supplied by the client (before reaching your trusted infrastructure) is untrusted and can be easily spoofed. Backend applications and security controls (like rate limiting) must be configured to trust only the IPs appended by your own NGINX instance or known trusted proxies, ignoring the client-supplied part of the chain.

CIS Controls

MITRE ATT&CK Mappings

Profile

• Level 1 - Proxy
• Level 1 - Loadbalancer