All web applications are subject to various vulnerabilities that may be exploited by hackers. Prevalent attacks today include denial-of-service, cross-site scripting and SQL injection. Symptoms may include a reduction in availability, a spike in resource usage or breaches in host or user security. There are various approaches to minimize the effects of or provide alerts to such exploits. One of the most effective is a Web Application Firewall (WAF).
Differences between IDS, IPS and WAF
An Intrusion Detection System (IDS), like an Intrusion Prevention System (IPS), sits within your network examining packets for anomalous behavior. Unlike an IDS, which passively observes traffic, an IPS typically sits inline, with traffic passing through it before being forwarded on to its destination. Here you can configure it to dynamically react and block traffic it detects as being potentially harmful.
However, due mainly to the diverse logic used in web applications, the inherent variety of vulnerabilities presents a rather large attack surface, which often cause IPSs to produce a large number of false positives. This can have a negative effect on security analyst efficiency.
Unlike an IDS or IPS, a WAF completely understands the application layer protocol that web applications themselves communicate directly over, The Hypertext Transfer Protocol (HTTP). Like an IPS, a WAF sits in front of web application servers and provides active, constant monitoring against threats via sophisticated analysis of communications between the outside world and your servers. It is more effective than an IPS since rather than examining all network traffic, it audits application traffic directly. Furthermore, once in place, a WAFs behaviour can be modified on-the-fly to respond to new threats.
Amazon’s WAF Service
AWS WAF is Amazon’s managed WAF service, and is currently available to users of Amazon CloudFront, their global content delivery network (CDN) service. Users who do not wish to use a CDN but are still interested in a WAF must still unfortunately use CloudFront in front of their web applications, but can configure it with the the most permissive caching rules so it’s effectively just a passthrough. You can also opt to use the smallest subset of CloudFront’s 56 edge locations to further minimize the cost overhead. Amazon is aware customers would like to see AWS WAF be directly supported by other AWS resource types, such as Elastic Load Balancers (ELBs), and we’re looking forward to its expansion to support other services in the near future.
The fact that the WAF service is tightly-coupled with CloudFront has its benefits. It means that the WAF processing actually takes place at these edge locations versus running within your Virtual Private Cloud (VPC).
This positions the WAF where it is most effective, which is as close as possible to the outside world, and furthest away from your application instances. Every request to your application is examined by AWS WAF and a decision is made to pass through the request or drop it based on the rules you’ve created takes place before the traffic ever reaches your VPC, or even region. This is a feature unique to AWS WAF, as users typically have no ability of placing computer resources at edge locations, so no user-managed or third-party WAF solutions will enjoy this benefit.
Setting up Your WAF
AWS WAF rules are defined in a web access control list (WACL). You set up the conditions on inbound HTTP requests within a WACL via the AWS WAF console, AWS CLI, or the AWS SDK of your choosing. A WACL may contain multiple rules, which are evaluated by AWS WAF in order, and each rule may contain multiple conditions. If all conditions are met within a rule, AWS WAF takes the specified action to allow, block or count the request without further rule evaluation. If no rule matches, the default action specified for the WACL is taken. Once created, you can associate the WACL with one or more CloudFront distributions.
AWS WAF Conditions and Rules
WAF conditions have various abilities for comparing specific HTTP request parts such as the URI, query string, request method, header or first 8192 bytes of the body against a specific string, or AWS-provided algorithms for detecting common exploits such as cross-site scripting and SQL injection. You can also specify transformations to the request parts such as normalizing whitespace, converting to lowercase, or HTML decoding before evaluating the condition. Conditions can also be specified for IP address ranges, but currently only on octet borders (i.e. /8, /16, /24, and /32 IP address ranges).
All the conditions in a rule must be satisfied in order for the rule’s action to be triggered. There are three possible actions: allow, block or count. The count action can be used for evaluating the potential of new rules, or for monitoring and performing dynamic actions based on the frequency of occurrence (e.g. blocking an IP address that makes too many attempts at a given URL). Metrics for count, as well as allowed and blocked, are recorded in CloudWatch for each rule, in addition to the number of times the default action for a WACL is performed.
Extending AWS WAF
AWS WAF includes functionality to programmatically download a sample of the actual HTTP requests that were captured for triggering a specific rule (or the the WACL default action) during a requested time period. This will return a random sample of up to 100 requests out of the first 5,000 requests received during that time period (if less than 100 requests were received during the specified time period, all of the requests received will actually be returned).
Combined with the metrics available in CloudWatch, this allows powerful ways to extend WAF functionality. For example, creating an alarm when a WAF metric breaches a certain threshold can trigger an AWS Lambda function to download the sample requests for that rule during that time period. WAF rules can then be dynamically amended through the WAF’s API based on insights learned from analyzing this data (e.g. an abusive IP address can be extracted from the sample request data, and then added to a new IP match condition in a black list rule of the application’s WACL).
Deepening Security at Other Layers
The use of IDSs, IPSs and WAFs are not mutually exclusive. Two or more can be implemented to deepen web application security by monitoring traffic within other layers of the Open Systems Interconnection (OSI) model. The additional security of AWS WAF also complements that already available in your VPC for layers 3 and 4 by network access control lists (NACLs) and security groups.
In order to ensure that AWS WAF is protecting your web application fully, ensure only CloudFront has access to your application to avoid the WAF from being bypassed. If your origin is an Elastic Load Balancer or an Amazon EC2 instance, you can use a security group that only allows IP ranges associated with CloudFront.
A WAF is generally superior to an IPS in efficiency and its ability to be used to detect not only known attack patterns but also to reveal and prevent new patterns from harming a web application. The ability to quickly define complex rules also makes them a more agile way to respond to anomalous conditions in near real-time while reducing the number of distracting false positives. This doesn’t necessarily mean that introducing a WAF in your environment removes the need for implementing IPS. If you have high security standards or want to further improve your ability to detect and prevent attacks and abuse inside your environment, implementing both WAF and IPS is generally a good idea.
If any of this sounds applicable to your business but overwhelming, TriNimbus offers deep experience in protecting web applications using services such as AWS WAF or implementing third-party IDS and IPS products like Alert Logic Threat Manager or Trend Micro Deep Security. We are able to assist your team in developing and deploying application-specific rules best suited to your environment and to continue to maintain and optimize the them based on the increased visibility provided by AWS WAF and Amazon CloudWatch metrics.