Insecure service configuration - ELB - Aws

Insecure service configuration - ELB - Aws

Need

Secure configuration of Elastic Load Balancers

Context

  • Usage of Terraform for Infrastructure as Code (IaC)
  • Usage of aws_elb for managing and configuring Amazon Web Services Elastic Load Balancer

Description

Non compliant code

        resource "aws_elb" "example" {
  name               = "example-elb"
  availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]

  listener {
    instance_port     = 80
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  security_groups = ["sg-0011223344"]
  subnets         = ["subnet-01234567"]

  instances = ["i-01234567", "i-76543210"]
}

The above Terraform code sets up an Elastic Load Balancer (ELB) in AWS. However, it contains a vulnerability due to insecure service configuration.

Here's a breakdown of the vulnerability:

1. Insecure Listener Configuration: The listener is set up to accept HTTP traffic on port 80. This is insecure because HTTP traffic is unencrypted, meaning that any data sent over this connection could be intercepted and read by an attacker. This could include sensitive information like user credentials or personal data.

2. Security Group Open to the World: The security group attached to the ELB ( sg-0011223344) is not defined in this code, but if it allows traffic from 0.0.0.0/0 (the entire internet), that would be a potential security issue. An open security group increases the attack surface by allowing any IP address to send traffic to the ELB.

3. No Access Logs: The configuration does not enable access logs. Access logs provide detailed records about requests sent to your load balancer, and are a crucial part of monitoring and securing your infrastructure.

4. No Connection Draining: Connection draining ensures that in-flight requests have time to complete when an instance is de-registered or becomes unhealthy. Without this, those requests may fail, impacting the user experience and potentially leading to data loss.

This insecure configuration can unintentionally increase the attack surface of the company's cloud infrastructure.

Steps

  • Update the ELB configuration to use HTTPS instead of HTTP for the instance protocol and load balancer protocol.
  • Create a custom SSL security policy for the ELB that contains secure ciphers.
  • Ensure that the load balancer is using a secure listener configuration.
  • Review and update the security groups associated with the ELB to ensure proper access controls.
  • Verify that the ELB is only accessible from the desired subnets.
  • Regularly monitor and update the ELB configuration to address any new security recommendations or best practices.

Compliant code

        resource "aws_elb" "example" {
  name               = "example-elb"
  availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]

  listener {
    instance_port     = 80
    instance_protocol = "https"
    lb_port           = 443
    lb_protocol       = "https"

    ssl_certificate_id = "arn:aws:iam::123456789012:server-certificate/certName"
  }

  security_groups = ["sg-0011223344"]
  subnets         = ["subnet-01234567"]

  instances = ["i-01234567", "i-76543210"]
}

The above code fixes the insecure service configuration vulnerability in the Elastic Load Balancer (ELB) by implementing the following changes:

1. HTTPS Protocol: The instance protocol and load balancer protocol have been updated to use HTTPS instead of HTTP. This ensures that all traffic between the load balancer and the backend instances is encrypted, reducing the risk of data being intercepted or manipulated.

2. SSL Certificate: An SSL certificate is specified for the load balancer. This certificate is used to establish a secure connection with the backend instances. The ssl_certificate_id parameter is set to the ARN of the SSL certificate stored in AWS IAM.

3. Secure Listener Configuration: The load balancer port ( lb_port) is set to 443, which is the standard port for HTTPS traffic. This ensures that the load balancer is using a secure listener configuration.

4. Security Groups: The security_groups parameter is set to a specific security group. This should be reviewed and updated as necessary to ensure that only the necessary inbound and outbound traffic is allowed.

5. Subnets: The subnets parameter is set to a specific subnet. This should be reviewed and updated as necessary to ensure that the load balancer is only accessible from the desired subnets.

6. Regular Monitoring and Updating: It is recommended to regularly monitor and update the ELB configuration to address any new security recommendations or best practices. This includes updating the SSL certificate as necessary and reviewing the security group and subnet configurations.

References