Cloud Security: Sample Web Firewall rule base
Sample scenario:
Your company’s voting application is currently being sold exclusively over the website that you have set up. Currently, your system is approved in most counties, but not in China or India. The governments of those countries have threatened to sue your company if anyone uses your application.
In addition, due to false information released by your major competitor, your company has been targeted by many hacker groups, claiming your organization is in league with corrupt politicians and organized crime. As a result, your website is often a target for denial of service attacks as well as other hacking attempts.
Finally, your company is planning to separate the website you currently have set up to include a back-end database service.
Technical Write-Up
In 5 to 10 pages, describe your setup, as well as your plan to deal with each of the three problems outlined above. Describe how your security framework will work, what steps you will take to eliminate or mitigate the problems, and what the final architectural design will look like. Include specific examples where needed. You may (but are not required to) include third-party applications and solutions along with those provided by Amazon, but if you do, be sure to well document their use along with the Amazon solution.
—-
Overview
This document describes the setup as well as the plan to deal with three major security related threats to the company’s voting application hosted in AWS
Main areas of concern
Three main areas of concern were highlighted to be eliminated or mitigate:
Prohibition in China and India
While most countries are allowing access to this application, access from China and India need to be blocked to prevent litigation and incurred cost from damages.
Protection from DDoS attacks,
Coordinated hacker groups are known not only for employing Denial of Service attacks, but also Distributed Denial of Service Attacks which can be more difficult to eliminate or mitigate. The solution needs to be prepared for this.
Public APIs to Database
Proposed plans include exposing a database API publicly. This can become a new attack point and needs to be designed to avoid the same risks outlined in points 1 and 2 above, as well as special considerations to protect the internal database from direct access over the internet incurring further possible exploits.
Best Practices
Geo Restriction
Amazon provides a Geo Restriction feature as part of Amazon CloudFront to allow either whitelisting or blacklisting of access based on location:
“Restricting the Geographic Distribution of Your Content.” Amazon, Amazon, docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html.
“When a user requests your content, CloudFront typically serves the requested content regardless of where the user is located. If you need to prevent users in specific countries from accessing your content, you can use the CloudFront geo restriction feature to do one of the following:
Allow your users to access your content only if they're in one of the countries on a whitelist of approved countries.
Prevent your users from accessing your content if they're in one of the countries on a blacklist of banned countries.”
In this case a blacklisting of China and India would be required as no other locations require restrictions. So leveraging CloudFront with Geo Restrictions will address the concerns on problem 1 and (part of) 3 above.
Protection from Distributed Denial of Service
Amazon provides a whitepaper specifically for Distributed Denial of Service (DDoS) which is a concern to points 2 and (part of) 3 above.
DDoS attacks can come at multiple levels
“AWS Best Practices for DDoS Resiliency.” AWS Best Practices | Microsoft Azure, d1.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf .
While some mitigations exist automatically within AWS further architectural changes are typically recommended, especially for a large-scale international application:
“Some forms of DDoS mitigation are included automatically with AWS services. You can further improve your DDoS resilience by using an AWS architecture with specific services and by implementing additional best practices.”
The main services which provide the most direct assistance are AWS Shield Standard, CloudFront and Route53:
“You can use AWS Shield Standard as part of a DDoS resilient architecture to protect both web and non-web applications.”
“Additionally, you can leverage AWS services that operate from edge locations, like Amazon CloudFront and Amazon Route 53, to build comprehensive availability protection against all known infrastructure layer attacks. Using these services – part of the AWS Global Edge Network – can improve the DDoS resilience of your application when you serve web application traffic from edge locations distributed around the world”
This configuration provides a number of DOS related benefits:
“Several specific benefits of using Amazon CloudFront and Amazon Route 53 include the following:
• AWS Shield DDoS mitigation systems that are integrated with AWS edge services, reducing time-to-mitigate from minutes to sub-second.
• Stateless SYN Flood mitigation techniques that proxy and verify incoming connections before passing them to the protected service.
• Automatic traffic engineering systems that can disperse or isolate the impact of large volumetric DDoS attacks.
• Application layer defense when combined with AWS WAF that does not require changing your current application architecture (for example, in an AWS Region or on-premises datacenter).”
Since DDoS can come from multiple network levels including application, the WAF integration (as mentioned above) is also highly recommended to prevent known application level attacks.
Further mitigation can be can be achieved by allowing elasticity in the architecture based on expected growth, and restricting impact to set instances (for example by region).
Amazon recommends (see whitepaper for details) selecting appropriate instance sizes, enabling autoscaling, setting up load balancing, scaling load balancing automatically, and configuring delivery and resolution at the edge to localize access. This will allow, for example, one region to be unavailable, while others remain available so that a DoS may impact one region without impacting another.
Protecting API Service internal resources
Finally, APIs can expose internal data-level resources externally. However ideally only the expected application calls ideally should be exposed without allowing any access directly to the internal servers or services. Amazon recommends the Amazon API Gateway for this purpose:
“By using Amazon API Gateway, you don’t need your own servers for the API frontend and you can obfuscate other components of your application. By making it harder to detect your application’s components, you can help prevent those AWS resources from being targeted by a DDoS attack.”
Proposal
The proposal here is to leverage Amazon’s DDoS-Resilient Reference Architecture listed in the AWS Best practices reference provided previously.
This involves setting up the EC2 server instances to autoscale (along with relevant data stores) in a private subnet; placing ELB Load Balancers infront of the servers requiring access (also configured to autoscale) on a public subnet; using Amazon Cloudfront with blacklisted geo restrictions for China and India to restrict access geographically and prevent a number of known DDoS attacks; Using the Amazon API Gateway to expose the set of acceptable API calls to the database in front of CloudFront; Using Amazon WAF in front of Cloud Front to prevent known web-based attacks; and using Amazon Route 53 to localize the web access based on region to restrict the impact of an attack. (See figure 5 in the AWS Best Practices reference previously mentioned for a diagram)