Implementing AWS WAF in a High Scale Enterprise Environment

Hashedin

Ashish Swarnkar, Manish Dave, Rishabh Bagrecha and Judelyn Gomes

07 Feb 2020

Background

 

Amazon released AWS WAF (Amazon Web Services Web Application Firewall) at AWS re Invent in 2015, Later, the introduction of managed rules in 2017 made it more popular.

 

Overview

 

WAF (Web Application Firewall)  protects your AWS Powered Web Applications from the common web exploits such as SQL Injection, cross-site scripting, file inclusion vulnerability, and security misconfigurations (attempt to gain unauthorized access or knowledge of the system and access default accounts, unused pages, unprotected files, and directories, etc.)

 

WAF provides us access control lists (ACLs), rules, and conditions that define acceptable or unacceptable requests or IP addresses. You can selectively allow or deny access to specific parts of your web application and you can also guard against various SQL injection attacks & XSS.

 

You can use WAF by attaching it to API Gateway, Cloudfront, Application Load Balancer (ALB)

 

Web ACL

 

A web access control list (web ACL) gives you impenetrable control over the web requests that your Amazon API Gateway, Amazon CloudFront distribution, or Application Load Balancer responds to.

You can use the following criteria to allow or block requests:

 

Rules

 

In every web ACL, rules are used to inspect web requests and decide the action when a web request matches the inspection criteria. Each rule requires one high-priority statement, which might have multiple statements, depending on the rule and statement type.

Based on the criteria ACL can be used to block or allow web requests like the following:

Rules Configured

 

Manual IP lists (A and B): This component has two specific AWS WAF rules, you have to manually add IP addresses to these rules:

SQL Injection (C) and XSS (D): The solution has two native AWS WAF rules that are designed to protect against malicious SQL injection or cross-site scripting (XSS) patterns in the query-string, URI or body of a request.

HTTP flood (E): This rule protects against attacks that exploit seemingly legitimate GET or POST requests to a server from a particular IP address, such as a web-layer DDoS (Distributed Denial of Service) attack.

Scanners and Probes (F): This component parses application access logs scans for unwanted behavior, such as the unwanted amounts of errors generated from a source. It identifies the suspicious source IP addresses & blocks them.

IP Reputation Lists (G): This component checks & blocks new ranges of IP addresses, with the help of IP Lists Parser AWS Lambda function for regularly checking third-party IP reputation lists and block them.

Bad Bots (H): This component relies on a honeypot URL, It is a security mechanism intended to lure and deflect an attempted attack.

Monitoring

 

CloudWatch: By Default Cloudwatch is integrated with WAF, the Cloudwatch Graph shows the request count for each rule in this web ACL and the default action.

But Cloudwatch Alarms doesn’t give the detailed monitoring & alerts on the 10-sec granularity for the blocked requests. As the alarm switch from Insufficient to Ok & vice versa, and state switching takes around 2-3 mins, which can miss the request being blocked during that interval.

 

Logging

 

By Default WAF doesn’t have logs enabled, We have to set up Kinesis Data Firehose for detailed logging, which is fully managed service for delivering real-time streaming data to the S3 bucket

 

Kinesis Data Firehose stores all logs in the S3 bucket, logs help us identifying why certain rules triggered & why certain rules blocked with our specific ALC rules.

Kinesis Delivery Stream is set on a buffer size of 5 MB and a buffer of 60 sec.

AWS CloudTrail Logs: CloudTrail provides a log of actions taken by a user, role, or an AWS service in AWS WAF. Using the information collected by CloudTrail, you can determine the requestor to AWS WAF, the origin IP address, time of the request, and additional details.

 

Best Scenario To Use WAF

 

WAF is still in a transition stage. As per Gartner’s 2019 report, the adoption of WAF is still catching up and is increasing at a promising rate of 20% year on year. We see the future of WAF is automation and monitoring rather than being a layer in front of the web tier. With the emergence of DevSecOps, WAF will play a crucial role in early-stage testing and security scanning.

 

Further, automation of WAF can be done with managed & custom Web ACL’s, Rules with CloudFormation Template. It can be integrated with any automation toolchain that you may already be using. WAF can be implemented in your QA environment where the team can perform intensive penetration testing. Each team’s test cases can be run against the WAF Enabled Environment. 

 

Thus, WAF is not just a reactive measure to implement security, it can also serve as a proactive measure to implement security through DevSecOps, which can be used in conjunction with CI/CD. With solid monitoring and logging integration, WAF can be a security center for your applications.

 


Have a question?

Need Technology advice?

Connect

+1 669 253 9011

contact@hashedin.com

linkedIn youtube