AWS Security practices demystified

We come across a lot of instances of Cloud based applications being hit by DDoS attacks. We must accept the fact that most of us are unaware of risks and protection methods available for DDoS protection in the cloud. This blog post emphasizes on understanding DDos attack and providing an approach to prevent unauthorized access and usage in Amazon Web Services (AWS).

Understanding DDoS attack

Source: wedebugyou.com

The steep increase in costs as in Github’s case, shot up to USD $30,000 per day.

Auto-scaling is a way to grow infrastructure as per business needs. If we leverage auto-scaling during DDoS, we will notice our bills increasing exponentially. Thus, we act as a host to the DDOS attackers as they have the control over bandwidth and duration of the attack, and hence they will be controlling our budget.

Understanding the difference between Application-Layer DDoS and Network-Layer attacks.

The attack patterns are different and their means of mitigation as well.

Network-Layer DDoS attacks use high bandwidth to saturate network components and bring them down by excessive use. An example of network layer attack is a SYN Flood attack which impregnates the web server connections.

Application-Layer DDoS attacks try to occupy high processing power, memory space, and disk space. It mostly attacks the login module by using bots to do it repeatedly. This type of DDoS attacks uses lesser bandwidth and can only be detected if system’s CPU or memory resources utilization increases significantly. Most of the security solutions will identify this type of DDoS as legitimate traffic, and the attack can go unnoticed. It is comparatively easy to execute. Also, this type of DDoS remains the only way for an attacker to bring down cloud hosted applications, as the network layer is mostly well protected by the Cloud Service Provider.

The Cloud Service Provider does not protect from Application-Layer DDoS

The Cloud Service Provider ensures protection against Network-Layer attacks including IPS(Intrusion prevention system) and anomaly detection solutions. We can trust on the cloud provider’s network components to be well- configured and hardened.

Source: blogs.aws.amazon.com/

As in Shared Responsibility model, we are responsible for protecting the Application Layer. The Cloud Service Provider as in our case, AWS has no insights into our application. Therefore, a larger number of requests to the login module is a legitimate activity to it. To have a deeper knowledge of AWS Best Practices for DDoS Resiliency, one can go through this document.

Best practices to protect AWS account from unauthorized access and usage:

• Disable root access key and secret key.
• Enable MFA tokens for each IAM user.
• Have minimum IAM users with Admin rights.
• Use Roles for EC2 instances for access permissions wherever possible.
• Provide least privileges and limit IAM entities actions with strong/explicit policies.
• Rotate all the keys on a regular basis (say 60 days).
• Use IAM roles with STS AssumeRole wherever possible.
• Do not allow 0.0.0.0/0 for any EC2/ELB security group.
• Apply proper S3 bucket policies with public access to only files instead of sharing a bucket/folder.
• Create all resources within a VPC.
• Make sure only required ports are open.
• Ensure all Back-end servers i.e. database servers are accessible via web servers only.
• Having separate IAM user for each team member.
• Attach all policies on groups and include users in a group as per access requirement.
• Avoid making server_Status page accessible publicly.



• Ensure all SSL certificates follow SHA2 encryption.
  For details about migrating to SHA2, click here.
• Make sure bash terminal on all servers are ShellShock proof.
  Following is a command test to check if our Bash is vulnerable to ShellShock:

  [js]env var='() { ignore this;}; echo vulnerable’ bash -c /bin/true[/js]

  An vulnerable version of bash will give a output “vulnerable”.

  If any patch has been applied, the same command test will return:

  [js]bash: warning: var: ignoring function definition attempt
  bash: error importing function definition for ‘var'[/js]

  Source: community.qualys.com

• Set alarms on billing using Amazon CloudWatch.
  This practice can be very useful to detect DDoS attacks and high data transfer occurrences. For steps to
  set alerts on billing, click here.