DDoS protection and AWS
Distributed Denial of Service (DDoS) and web application attacks are on the rise. Whilst I’m a firm believer that the ‘Cloud’ does simplify Infrastructure and Application builds and deployments, it unfortunately can make it easier to leave key application endpoints open to attack and security being compromised.
Last year, one of the largest DDoS incidents was recorded when GitHub was hit with a 1.35 Terabit per second, Memcached based reflection attack. It’s not just individual services which can be targeted; a single service provider can be targeted to cause it’s supported services to become unreachable. Take for instance DNS flood attacks and the 2016 Dyn attack.
What both of these attacks had in common is that the affected platforms had the ability to detect and deflect the malicious network packets in a very short space of time. This is especially the case with the GitHub incident, where the stability of the service was restored within 10 minutes of the DDoS attack being discovered.
Ok, so obviously these examples are based on two high profile public services with the drivers for attackers to cause wide spread disruption. However, as an application’s visibility and popularity grows, this can increase its risk of becoming a target for attacks. This is especially relevant if the application offers a service for a lucrative product, yields high turnover or profit, or for public good.
Earlier I said that Cloud can make it easier to be compromised through lack of security. However, many public Cloud providers such as AWS can help here. AWS offer by default DDoS protection at networking layers 3 and 4, AKA ‘Shield Standard’. Where this helps is if you use Route 53 (for public DNS DDoS protection) and Cloudfront (Content Delivery Network).
By publishing a web application through Cloudfront, this allows for application content to be cached at AWS’ edge network locations. DDoS traffic can be then be prevented from being routed further down infrastructure stacks, to where backend resources are hosted and therefore, reduces the risk application instability through resource exhaustion. In addition to this, AWS also has the ability to automatically scale underlying network resources and instance interfaces during a DDoS attack, in order to absorb this excess traffic.
This is all great, but dependent on how severe the DDoS attack is in terms of the amount of data processed and how much the networking infrastructure is scaled out by, the costs around this could be phenomenal and AWS (like a number of other public Cloud providers) expect the customer to foot this bill.
This can be a bitter pill to swallow, after the efforts to keep the victim application stable during an attack and deflect the offending traffic. Plus, the ‘out of the box’ DDoS protection which a number of public cloud providers offer, don’t offer the full coverage of protection which is required to fend off a DDoS attack.
However, this is where Shield Advanced can help. Two of the big features of Shield Advanced are those of cost protection and access to DRT (AWS’ DDoS Response Team).
The cost protection side of things ensurs that when AWS auto-scale networking to provide additional capacity during a DDoS attack, the customer is first off not charged for this (as you are with Shield Standard). DRT are the team who will be deployed during the DDoS incident to analyse the incoming offending traffic as well as the source of these requests. The result of this will ultimately help to determine the measures which are put in place to fend off the source traffic and prevent this from penetrating the target application.
The way which this is achieved is by implementing AWS WAF (Web Application Firewall), where WAF rules can be implemented to deflect traffic from the originating DDoS attack, based on the type of requests which the origin is sending. One early recommendation is that whilst Shield Advanced is being implemented, deploy on-going rate based rules which will automatically block origin IP addresses which hit a limit of the volume of requests in a set time period. WAF is also included in the price of a Shield Advanced subscription.
Aside from the DDoS protection side of things, WAF should be used to add further protection to web applications. It works on the concept that integral application protection can be promoted to the firewall layer, ensuring that the application remains protected even if this is not integrated into the build of the application itself. WAF also works heavily on promoting the implementation of the OWASP Top 10 vulnerabilities in web applications and protection against these. AWS have also published a whitepaper here, which talks about how the associated protection can be implemented into WAF.
As far as automation goes and Infrastructure as Code; WAF resources are available for both AWS’ Cloudformation and the ever popular Terraform https://github.com/traveloka/terraform-aws-waf-owasp-top-10-rules or https://docs.aws.amazon.com/solutions/latest/aws-waf-security-automations/template.html
However, at the time of writing, neither Cloudformation nor Terraform offers resources to automate the deployment of Shield Advanced. But we’ve already put a Bash script together based on AWS CLI to make this a repeatable task across all environments you may have, ensuring consistency.
AWS DRT can be engaged when there is a suspected DDoS attack. Shield Advanced also fully integrates with Cloudwatch, so when Shield detects abnormal traffic, a Cloudwatch alarm can be triggered to alert your preferred comms path (typically a SNS topic going to a Webhook subscription). Again, Cloudwatch configuration is already available in Cloudformation and Terraform.
There are then several ways which this Cloudwatch alarm can be handled:
• Carry out in house diagnosis to further determine the nature of the DDoS attack and determine the required actions to mitigate the attack.
• Have a Cloudwatch Event automatically trigger a ‘shield-engagement’ Lambda to alert the DRT directly that a DDoS incident is occurring.
• Alternatively, the ‘shield-engagement’ can be manually invoked and engage the DRT, once they are genuinely required.
AWS have a Node.js Lambda function available which can be deployed in advance to be used to engage the DRT. We’ve already extended this Lambda function here, to automatically grant the DRT read and write access to WAF and Shield Advanced resources. This gives them the ability to apply DDoS mitigations on your behalf. In a number of scenarios, this may be preferable as it may allow mitigations to be generated and applied faster, compared to in house technical teams.
The final Lambda available is that to then revoke DRT access when this is no longer required. This will be invoked when the DDoS incident is confirmed as resolved.
The thought of giving access to a third party to your resources may be unsavoury to some customers. The decision on whether to do this or not, should be based on how your technical teams will be able to deal with a real-life DDoS incident. Besides, the DRT are a specialised team within AWS who have a wealth of experience of mitigating security incidents. Mitigations which the DRT have generated will only be implemented once discussed with the customer and subject to their approval.
Finally, Shield Advanced extends DDoS protection directly to AWS Load Balancers and EC2 instance (if using Elastic IP Addresses). So even if you’re not using Cloudfront, but these other commonly used AWS resources, you can still benefit.
It isn't for everyone
Shield Advanced does come with a price tag. It’s subject to a 12 month commitment at $3,000 per month. So the decision on whether to deploy this is very much based on the opening comments of this blog; how vulnerable is your application to attacks and how big is the risk if a DDoS attack occurs. It won’t be cost efficient for everyone.
If we compare Shield Advanced to other DDoS protections solution such as Akamai Prolexic which was used during the GitHub DDoS attack last year, Shield is a half way house in terms of pricing between using nothing and a larger enterprise solution like Akamai Prolexic. Shield is also more intune to AWS native deployments, whereas Akamai solutions appear to be more for distributed deployment (think hybrid cloud).