Load Balancer Security Guide: TLS, Headers and Management Plane Hardening

Load balancers terminate TLS, rewrite headers and hold the keys to every application behind them, yet they are often configured once at launch and never reviewed again. Hardware application delivery controllers, software balancers such as HAProxy and NGINX, Kubernetes ingress controllers and cloud services such as AWS Application Load Balancer and Azure Application Gateway all share three security surfaces: the TLS edge, the request and header handling on the data plane, and the management plane that controls them. Several of the most exploited vulnerabilities of recent years sit in this tier. This guide covers each surface with concrete settings, a rollout approach, detection and metrics, and is written for network, platform and cloud engineers who run or review load balancers.

Key takeaways

• The management plane is the crown jewel. F5 BIG-IP CVE-2022-1388 (missing authentication) and CVE-2023-46747 (Configuration Utility authentication bypass) are both in CISA KEV with known ransomware use; management interfaces must never be reachable from the internet.
• Defaults are not always safe. AWS documents that listeners created through the CLI or CloudFormation default to ELBSecurityPolicy-2016-08, which still allows TLS 1.0 and 1.1, while the console default allows only TLS 1.2 and 1.3.
• Header handling decides what backends believe. X-Forwarded-For processing, Host header preservation and invalid header handling are explicit settings on modern balancers; choose them deliberately.
• Sessions issued at the edge are credentials. CitrixBleed showed that patching a gateway does not revoke stolen session tokens; persistence and authentication sessions must be cleared.
• Logs and deletion protection are off by default on some platforms. AWS ALB access logs and deletion protection both default to false, so turn them on in your templates.

Load balancer types and their security surface

A layer 7 balancer is a reverse proxy, so the header trust and routing rules in the Proxies and Forward vs Reverse Proxy Security Guide apply; this guide focuses on what is specific to balancers and their management.

TLS termination, policies and certificates

NIST SP 800-52 Rev. 2 requires TLS 1.2 with approved cipher suites for government servers and set 1 January 2024 for TLS 1.3 support; the publication is currently under review, so check for a revision. Cloud balancers express this as named policies.

• End-to-end or re-encrypt: terminating TLS at the balancer and sending plaintext to targets leaves credentials readable on the internal network (T1557). Re-encrypt to targets and, on self-managed balancers, verify the backend certificate (verify required with a ca-file in HAProxy, proxy_ssl_verify on in NGINX). For workloads that must hold their own keys, use layer 4 TLS passthrough.
• Keys in managed stores: import certificates into the cloud certificate service or a key vault reference, or an HSM on ADCs, rather than files on disk. Restrict who can export them.
• Automate renewal: balancers are where expired certificates cause outages. With public TLS certificate lifetimes falling towards 47 days, renewal must be automated. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
• HSTS and redirects: redirect port 80 to 443 at the balancer and set Strict-Transport-Security there if applications do not. See the How TLS Works Guide for the handshake background.

Header handling and request hygiene

AWS exposes the header decisions as named ALB attributes, which makes a useful checklist for any platform.

• Self-managed equivalents: in HAProxy, set option forwardfor with http-request del-header X-Forwarded-For before it at the edge so client values are replaced; in NGINX use proxy_set_header X-Forwarded-For $remote_addr at the first hop rather than $proxy_add_x_forwarded_for.
• PROXY protocol trust: accept PROXY protocol only on listeners reachable solely from the layer 4 balancer (accept-proxy in HAProxy, listen ... proxy_protocol with set_real_ip_from in NGINX), otherwise clients can forge their source address.
• Timeouts and limits: ALB defaults to a 60 second idle timeout and 3,600 second client keep-alive; on self-managed balancers set header, body and request timeouts (timeout http-request in HAProxy) to bound slow request attacks.
• Origin lock: targets should accept traffic only from the balancer (security groups referencing the balancer, private subnets, or a shared secret header from a CDN), otherwise attackers bypass the WAF and rate limits by hitting the origin directly.

Desync is covered in depth in the HTTP Request Smuggling Guide, and edge request filtering in the Web Application Firewall Guide.

Management plane hardening

Exploited ADC vulnerabilities cluster in management functions: F5 BIG-IP CVE-2020-5902 in the Traffic Management User Interface, CVE-2022-1388 (missing authentication, in the iControl REST interface) and CVE-2023-46747 in the Configuration Utility. All three are in the CISA Known Exploited Vulnerabilities catalogue.

• Isolate management: bind web UIs, REST APIs and SSH to a dedicated management interface on an isolated network reached through a jump host or privileged access workstation. Do not expose the configuration utility on self IPs or data plane listeners.
• Authenticate administrators centrally: use the directory or identity provider with MFA, role-based access (read-only, operator, administrator) and per-person accounts. Keep built-in root accounts such as nsroot or admin as vaulted break-glass credentials. See the Privileged Access Management Guide.
• Control cloud APIs: in the cloud, the management plane is the provider API. Restrict actions such as elasticloadbalancing:ModifyListener, certificate changes and attribute changes to deployment pipelines, enable deletion_protection.enabled, and alert on listener policy downgrades.
• Configuration as code and drift detection: keep balancer configuration in version control, review changes, and compare running configuration against it. On ingress controllers, restrict configuration snippet annotations, which can inject arbitrary proxy configuration.
• Patch to KEV deadlines: subscribe to vendor advisories, track internet-facing balancers separately, and plan maintenance windows using high availability pairs so patching is not deferred.
• Back up and protect configuration exports: ADC configuration archives contain private keys and secrets; encrypt and restrict them.

See the Edge Device Security Guide for the wider appliance programme.

Sessions, persistence and identity at the balancer

• Persistence cookies: sticky-session cookies should carry no user data, be set Secure and HttpOnly, and be scoped to the application host. They identify a backend, not a user, and must not be used for authorisation.
• Authentication offload: when the balancer authenticates users (OIDC actions on ALB, AAA virtual servers on NetScaler, Access Policy Manager on BIG-IP), its session cookie is a bearer credential. Set short lifetimes and plan for mass revocation. After CitrixBleed, Citrix advised commands such as kill aaa session -all and clear lb persistentSessions after patching, because stolen cookies stayed valid.
• Appliance administrator tokens: CitrixBleed 2 (CVE-2025-5777) leaked memory that, in researcher testing, included a session token for the nsroot administrator; rotate administrator credentials after any memory disclosure.
• Machine identities the balancer holds: TLS keys, client certificates for backend mTLS, ingress controller service accounts and cloud roles for certificate retrieval are non-human identities. Scope them and assign owners. See the Non-Human Identity (NHI) Guide.

Availability and DDoS resilience

• Health checks: use dedicated, unauthenticated health endpoints that reveal nothing sensitive, and do not let a health check path bypass authentication for real content.
• Connection limits and rate limiting: set per-client connection and request rate limits (stick tables in HAProxy, limit_req in NGINX, WAF rate rules on cloud balancers) to blunt T1499 endpoint DoS. See the Rate Limiting and API Abuse Guide.
• Volumetric attacks: a balancer is not a DDoS scrubbing service; network floods (T1498) need upstream protection. See the DDoS Protection Guide.
• Fail closed or open by design: decide per application whether WAF, authentication or backend failures should block or allow traffic, and document it.

Choosing an approach

• Managed cloud balancer vs self-managed ADC: managed services remove appliance patching and management interface exposure, leaving IAM and configuration as your surface; ADCs suit complex on-premises estates but need a dedicated patch and management network discipline.
• TLS termination vs passthrough: terminate when you need WAF, header controls or routing on paths; pass through when regulatory or trust requirements demand keys stay on the workload, accepting less edge visibility.
• Small organisations: prefer a managed balancer with the recommended TLS policy, access logs on, deletion protection on and targets reachable only from the balancer.
• Large organisations: publish a balancer baseline per platform, enforce it with policy as code (for example AWS Config rules or Azure Policy), and run a single inventory of every listener and certificate.

Implementation: a phased rollout

1. Discover: enumerate every balancer, listener, TLS policy, certificate, attribute set and management endpoint across clouds and data centres. Scan external ranges for exposed management ports and UIs.
2. Close management exposure first: move admin interfaces off public and data plane addresses, enforce MFA and central accounts, and vault built-in root credentials.
3. Turn on logs: enable access and connection logs and send them to the SIEM before changing TLS or header behaviour, to measure impact.
4. TLS policy uplift: use logs (on ALB the optional x-amzn-tls-version header or access log TLS fields) to find clients on old versions, notify owners, then move listeners to the target policy one application at a time.
5. Header and desync settings: set desync mitigation to monitor in staging to see classification, then defensive or strictest; enable dropping invalid headers after confirming no application depends on them.
6. Origin lock and backend TLS: restrict target security groups to the balancer and enable re-encryption with verification.
7. Rollback: apply changes through infrastructure as code with the previous version ready to re-apply, test on a canary listener or weighted target group, and define error-rate thresholds that trigger rollback.

Detection and measurement

Monitor management logins and configuration changes (failed logins, new admin accounts, iRule or policy changes outside change windows), cloud API events that change listeners, certificates or attributes, spikes in 4xx responses from desync or invalid header handling, unknown Host values, one session cookie seen from several source addresses, and traffic reaching targets directly rather than through the balancer.

Common failure patterns

• Management UI on the internet: configuration utilities and REST APIs exposed on public addresses turned F5 and Citrix flaws into mass exploitation events.
• Template defaults: listeners created through infrastructure as code without a policy argument silently get a legacy TLS policy.
• Patching without revoking: after gateway memory disclosures, stolen AAA and persistence sessions remained usable until killed.
• Preserving client headers: passing client-supplied X-Forwarded-For or Host values unchanged lets attackers spoof addresses or poison links.
• Origin bypass: targets with public addresses or open security groups let attackers skip the WAF and rate limits entirely.
• WAF fail open by default habit: enabling fail open for availability without deciding per application removes protection during the incidents when it matters.

Framework mapping

Practitioner checklist

• Inventory every balancer, listener, TLS policy, certificate and management endpoint with an owner.
• Ensure no management interface, configuration utility or REST API is reachable from the internet or data plane addresses.
• Enforce MFA, central accounts and role-based access for administrators, and vault built-in root accounts.
• Set an explicit TLS policy on every listener (TLS 1.2 minimum, 1.3 enabled) in templates, not only in the console.
• Re-encrypt to targets with certificate verification, and lock targets so they accept traffic only from the balancer.
• Review header settings: forwarding header processing, Host preservation, invalid header dropping and desync mitigation.
• Enable access logs, connection logs where available, and deletion protection; alert on listener and certificate changes.
• Patch internet-facing balancers within KEV deadlines and kill sessions after any memory disclosure.
• Automate certificate renewal and track keys and service accounts held by the balancer as non-human identities.

Standards and references

• NIST: SP 800-52 Rev. 2 Guidelines for the Selection, Configuration, and Use of TLS Implementations
• NIST: SP 800-53 Rev. 5
• CISA: Known Exploited Vulnerabilities Catalog
• IETF: RFC 7239 Forwarded HTTP Extension
• AWS: Application Load Balancers attributes
• AWS: Security policies for your Application Load Balancer
• Microsoft: Application Gateway TLS policy overview
• PortSwigger: HTTP Host header attacks

Related NHI Mgmt Group resources: Proxies and Forward vs Reverse Proxy Security Guide · Edge Device Security Guide · Network Security Guide · DDoS Protection Guide · Machine Identity, PKI and Certificate Lifecycle Guide