Elastic Load Balancers are not as easy to secure compared to other foundational cloud services, such as Amazon EC2, S3, and SQS. In this article, we’ll outline common cloud security pitfalls and best practices to protect your cloud infrastructure from cloud security risks in Elastic Load Balancing.
Elastic Load Balancing is one of the foundational cloud services in the AWS ecosystem. It works in union with compute services like EC2 and Lambda to build scalable and fault-tolerant applications. Despite being ubiquitous in almost every well-architected application built on AWS, Elastic Load Balancers are not as easy to secure compared to other foundational services, such as Amazon EC2, S3, and SQS, that have simple interfaces and functional default settings.
Fortunately, CloudHealth Secure State includes built-in rules that help detect cloud security risks in Elastic Load Balancers deployed in your AWS infrastructure. In this article, we’ll use CloudHealth Secure State’s Explore feature, a powerful DSL, and built-in rules to detect interconnected threats caused by incorrectly configured Elastic Load Balancers.
Risk due to internet-facing Elastic Load Balancers
Let’s take an example of a default setting on Elastic Load Balancers that can cause you to unintentionally increase the attack surface of your cloud infrastructure. By default, Elastic Load Balancers are created as “internet-facing” for clients on the public internet to connect to your load balancer and backend infrastructure.
However, this opens the application hosted behind the load balancer to attacks from malicious entities on the internet. If attackers get access to the backend EC2 instances connected to your public load balancers, they can significantly compromise your cloud resources by abusing the permissions assigned to the instances.
There are still plenty of legitimate use cases for having an internet-facing load balancer (and we will discuss in a later section how CloudHealth Secure State can help you secure your public load balancers), but first, let’s see how you can find internet-facing load balancers in your cloud account.
- Click on the “Explore” tab in your CloudHealth Secure State console
- Select your AWS cloud account from the drop-down
- Paste the following Explore query and click “Run” : AWS.ELBv2.LoadBalancer HAS Scheme = “internet-facing”
EC2 instances with administrative access attached to internet-facing load balancers significantly increase your attack surface by exposing all your cloud resources to an attacker if the load balancer is compromised.
You can use the following Explore query to find threats like this in your AWS account:
AWS.ELBv2.LoadBalancer -> AWS.ELBv2.TargetGroup -> AWS.ELBv2.Target -> AWS.EC2.Instance -> AWS.IAM.InstanceProfile -> AWS.IAM.Role -> AWS.IAM.ManagedPolicy HAS PolicyName = “AdministratorAccess”
Additionally, you can convert this query into a rule and set alerts to get real-time notifications whenever a public internet-facing load balancer is created in your cloud account.
Secure your internet-facing load balancers
If you have a legitimate use-case for an internet-facing load balancer, it’s strongly advised that the load balancer uses a secure listener—HTTPS listener for layer 7 or SSL listener for layer 4 traffic. This ensures that communication between your clients and your application is encrypted and not susceptible to eavesdropping or man-in-the-middle attacks. The ease with which you can enable SSL termination at your load balancer and perform periodic rotation of your certificates without touching your backend infrastructure makes it a no-brainer to have this feature enabled.
CloudHealth Secure State offers native rules that can be used to detect internet-facing load balancers that don’t have secure listeners. Just make sure that these rules are enabled in your service console and set real-time alerts to be notified whenever these rules are violated.
To access the rules:
-
Click on the “Rules” tab in your CloudHealth Secure State console
-
Filter rules by service “ELB” and “ELBv2”
-
Click on rules titled: Internet facing Elastic Load Balancer has an insecure listener and Internet facing Elastic Load Balancer can be accessed insecurely using HTTP protocol
Final thoughts
Building applications on top of foundational cloud services eliminates complexity and allows application developers to focus on the core business logic of their applications. However, developers shouldn’t have to let go of security controls to take advantage of running applications in the cloud.
With CloudHealth Secure State, you can leverage security findings API to proactively monitor the posture of your Elastic Load Balancers and other critical cloud services during the deployment process. If there’s a violation, you can fail the build, fix the issue, and re-deploy.
To learn more about cloud security best practices and continuous security verification with CloudHealth Secure State, see our technical report or request a free demo today.
