Load balancers are one of the most trusted components in your infrastructure. They receive all inbound traffic, terminate TLS connections, make routing decisions, and forward requests to backend services. A misconfigured load balancer is not a localized problem. It affects every service behind it.
Despite their critical role, load balancers receive less security scrutiny than applications or databases. Their configuration is often treated as a networking concern rather than a security concern. This guide addresses the security considerations that matter for modern load balancer deployments.
TLS Termination Security
Configure Modern TLS
Load balancers that terminate TLS must be configured with appropriate protocol versions and cipher suites. Allow only TLS 1.2 and 1.3. Disable all versions of SSL and TLS 1.0/1.1.
For AWS Application Load Balancer:
Use the ELBSecurityPolicy-TLS13-1-2-2021-06 policy
For cloud load balancers, the provider manages the TLS implementation, but you choose the policy. Default policies often include legacy protocols for backward compatibility. Explicitly select a modern policy.
Certificate Management
Load balancer certificates should be managed through automated systems: AWS Certificate Manager, GCP-managed certificates, or cert-manager for Kubernetes Ingress load balancers. Manual certificate management leads to expired certificates.
Monitor certificate expiration dates. Alert at least 30 days before expiration. Automated renewal should handle most cases, but alert on any certificate approaching expiration as a failsafe.
Backend Encryption
TLS termination at the load balancer means traffic between the load balancer and backend services is unencrypted by default. This is acceptable if the load balancer and backends are in the same trusted network, but it means an attacker who gains access to the internal network can sniff traffic.
For sensitive workloads, re-encrypt traffic between the load balancer and backends. AWS ALB supports this with HTTPS target groups. This adds latency but ensures end-to-end encryption.
Health Check Security
Protect Health Check Endpoints
Load balancers perform health checks against backend services to determine routing. If the health check endpoint is accessible from the internet, attackers can enumerate your backend infrastructure and potentially identify the software and version running on each backend.
Restrict health check endpoints to the load balancer's source IP range. Use network security groups or firewall rules to ensure only the load balancer can reach health check endpoints.
Do Not Expose Sensitive Data in Health Checks
Health check responses should return a simple status indicator, not detailed system information. A health check that returns database connection status, memory usage, and software versions provides valuable reconnaissance data to attackers.
Monitor Health Check Patterns
Unusual health check failures can indicate a DDoS attack targeting specific backends, a backend compromise causing instability, or network issues between the load balancer and backends. Correlate health check failures with other security signals.
Access Control
Restrict Source IPs
If your service serves a known set of clients, restrict load balancer ingress to those IP ranges. For internal services, allow only corporate network ranges. For partner APIs, allow only partner IP ranges.
Implement Web Application Firewall
Most cloud load balancers integrate with WAF services. Deploy WAF rules that protect against common attacks: SQL injection, XSS, and known vulnerability exploitation patterns.
Rate Limiting
Implement rate limiting at the load balancer to protect backends from abuse. Cloud load balancers support rate-based rules that automatically block clients exceeding defined request rates.
Client Authentication
For service-to-service communication, implement mutual TLS at the load balancer. Only clients presenting valid certificates can connect. This is stronger than IP-based restrictions because certificates verify identity, not just network location.
Routing Security
Prevent Host Header Manipulation
Attackers can send requests with manipulated Host headers to confuse routing logic. Ensure your load balancer validates the Host header against a known list of expected values. Reject requests with unknown Host headers.
Restrict HTTP Methods
If your application only uses GET and POST, configure the load balancer to reject other methods. DELETE, PUT, TRACE, and OPTIONS requests to unexpected endpoints can reveal information or trigger unintended behavior.
Path-Based Routing Security
When using path-based routing to direct traffic to different backend services, ensure that path matching is precise. A rule routing /api might inadvertently also match /api-internal or /api/../admin. Use exact path matching or anchored regex patterns.
Logging and Monitoring
Enable Access Logging
All cloud load balancers support access logging. Enable it. Log every request with client IP, request method, path, response code, latency, and backend target.
For AWS ALB, enable access logs to S3. For GCP, enable HTTP(S) load balancing logging. For Azure, enable diagnostic logging.
Monitor for Anomalies
Watch for traffic pattern changes that indicate attacks: sudden spikes in requests from single IPs, unusual geographic distribution of requests, high rates of 4xx or 5xx errors, and requests with unusually large headers or bodies.
Alert on Configuration Changes
Monitor your load balancer configuration for unauthorized changes. A modified routing rule, added listener, or changed security group could be an attacker establishing persistent access or redirecting traffic.
High Availability Security
Cross-Zone Load Balancing
Enable cross-zone load balancing to distribute traffic across availability zones. This prevents an attacker from targeting a single zone and taking down the service.
Connection Draining
Configure connection draining to handle backend deregistration gracefully. This prevents dropped connections during deployments and ensures that security patches can be rolled out without service interruption.
DDoS Protection
Cloud providers offer DDoS protection services that integrate with load balancers. AWS Shield, GCP Cloud Armor, and Azure DDoS Protection provide automatic detection and mitigation of volumetric and application-layer DDoS attacks.
Enable these services for internet-facing load balancers. The cost of DDoS protection is minimal compared to the cost of a successful DDoS attack.
How Safeguard.sh Helps
Safeguard.sh provides visibility into the software supply chain of the services behind your load balancers. It generates SBOMs for every backend service, identifies vulnerable components, and tracks the security posture of your entire application fleet. When a vulnerability affects a service behind your load balancer, Safeguard.sh identifies it immediately, helping you prioritize patching for internet-facing services that carry the highest risk.