AWS WAF is the foundation for most of the native security capabilities within Amazon Web Services. In this article series, we’re taking a deep dive into this important tool.
- Explore AWS WAF in terms of its traffic filtering, monitoring and reporting, bot management, ATO prevention, API protection, and cost structure
- Highlight its limitations, some of which are significant
- Discuss how to effectively protect sites, applications, and APIs running on Amazon Web Services
AWS WAF Traffic Filtering
Modern web traffic is dense and complex, and attackers have a wide variety of potential attack vectors to exploit. A web application firewall must be able to inspect this traffic and immediately make accurate filtering decisions. A good WAF doesn’t just block traffic, however; it needs to be equally flexible in letting valid traffic pass.
AWS WAF uses rule statements to define specific filtering criteria and behavior. These rules are aggregated in a web access control list (web ACL). ACLs are then applied to specific resources that the end user wishes to protect.
Part 1 of this series briefly covered the high-level traffic filtering features offered by AWS WAF:
- IP address origin of the request
- Country of origin of the request
- String match or regular expression (regex) match in a part of the request
- Size of a particular part of the request
- Detection of malicious SQL code or scripting
These features give users a fairly capable toolkit to start developing their own rules. For instance, string/regex match can be used to look for arbitrary headers or values present in request metadata. Request size could be used to filter out malicious payloads or unexpected content.
However, this feature set also highlights one of AWS WAF’s most significant problems; the fact that users need to develop their own rules.
Limitation: Rule Administration
Although AWS WAF includes some prebuilt policies, they have limited scope. Admins can create additional policies, but to create correct, effective, and comprehensive rulesets, admins need deep expertise in both web security and the AWS ecosystem. The price of failure is high; an incorrect or incomplete configuration can leave security gaps in the system. Further, the rules must be constantly updated in response to new threats, even during the stress of an attack. To offset this, AWS provides automation templates, and vendors offer some add-ons in the Marketplace; however, these do not fully solve these problems, nor do they cover all threats.
Because admins are responsible for creating their own rules, they also must maintain them. Thus, admins must stay up-to-date with today’s constantly evolving threat environment; this involves monitoring CVE databases, following security professionals on social media, attending live events, checking risk-advisory feeds, and more. All of these tasks are very time-consuming, and again, have a high cost of failure when not done consistently and correctly.
Limitation: Rate Limiting Granularity
This is a potential dealbreaker for any large-scale or highly visible resource.
Rate limiting is an important security feature, and is the basis for blocking credential stuffing, dictionary attacks, fuzzing, scraping, enumeration, payment card fraud, and many other types of malicious activities.
AWS WAF includes rudimentary rate limiting; it can count and block web requests that meet certain conditions and exceed a specified number. However, its capabilities are inadequate in today’s threat environment.
For counting requests, AWS WAF requires a minimum period of five minutes. This period is too long; a lot of harmful/malicious traffic can be passed within this time.
Also, AWS WAF counts requests based on their IP addresses. Thus, attackers can evade rate limiting merely by rotating IPs.
Limitation: No Ordering Logic or Evaluation Automation
The ability to craft ACLs around collections of specific, custom rules is a powerful abstraction. Unfortunately, that abstraction does not scale well if hundreds of rules and rule-ordering workflows are needed. Security teams that need to create complex rule filtering across a large fleet of resources are left to do it on their own; any automation will have to be developed and provided in a bespoke fashion.
Monitoring and Reporting
Informative monitoring and observability tools are necessary for any serious software engineering platform. It is even more crucial for security solutions to provide the same. Unfortunately, AWS’s security tools have a number of important gaps.
Limitation: Traffic Visibility
AWS WAF does not include prebuilt traffic monitoring. Users must manually create their own dashboards using a variety of additional products such as Lambda, Kinesis Data Firehose, and OpenSearch. This can be difficult and time-consuming.
Even then, data is not available in real time (only “near” real time). This makes it difficult to fully understand or react to attacks as they occur.
Limitation: Traffic Logging, Reporting, and Alarms
Like most AWS services, AWS WAF integrates with Amazon CloudWatch. CloudWatch alarms can be used to alert when thresholds are triggered, and events can be logged in CloudWatch logs or CloudTrail. Automation is also possible; events can be delivered to CloudWatch Events, triggering additional actions if an event fires that matches a rule defined in the WAF. Customers can also go directly to the AWS WAF service page to view information about request counts and matches.
An example automated security operation might be built as follows using CloudWatch: Security engineers configure an AWS WAF rule to block requests from a CIDR range. They create a BlockedRequests metric for the rule, generating a CloudWatch alarm if the number of blocked requests for this rule exceeds a certain threshold. If the alarm fires, it triggers CloudWatch Events to fire another event in SNS, broadcasting to ops channels like Slack and PagerDuty.
As we’ve seen before, admins must plan, design, and build out these systems on their own. Organizations will need to have staff with experience in AWS, security operations, and overall cloud infrastructure to take full advantage. For leaner engineering groups, this can mean tying up valuable engineering resources that could be working on customer-facing, revenue-generating infrastructure.
Lastly, timely access to traffic data is important for trend analysis, fine-tuning security policies, and so on, but it can be awkward. AWS WAF does not include inherent reporting capabilities; instead, data must be sent into CloudWatch. Again, this data is not available in real time. Further, data retrieval can be very slow (many AWS services send logs into CloudWatch, and as applications scale, data can scale exponentially), and must be done manually (admins must write filters, create queries using a special Logs Insight language, etc.).
Automated scripts and bots make up a large percentage of web traffic today. While some of this traffic is legitimate (such as search engine crawlers), a lot of it is malicious. This includes attack bots, spammers, and scrapers. Organizations need to be able to detect and block this automated traffic while still allowing legitimate traffic through.
For this purpose, Amazon offers AWS WAF Bot Control. It’s meant to block a variety of common bot traffic, while allowing more benign bots (like search indexers) to continue with their requests.
Limitation: Ability to Detect Bots
To identify automated traffic, AWS WAF Bot Control relies upon request metadata and (especially) on blacklists of IP addresses. Thus, AWS WAF has difficulty identifying many of the bots sent by competent attackers, because hackers evade blacklisting by switching IPs frequently. (Reblaze often sees attacks where each request comes in on a unique IP address.)
Limitation: Manual Configuration
Users still need to construct their own automation. In the case of bot management, a common issue is false positives that can lower site traffic and potentially break internal monitoring and analysis tooling. With AWS WAF Bot Control, the user needs to perform a manual loop of deploying, testing, and evaluating to potentially discover and remediate false positives. This is in contrast to other WAF solutions that offer constant updates driven by data and machine learning to the rulesets and mitigations provided to customers.
Limitation: Reliance on CAPTCHAs
Along with IP blacklisting, AWS WAF also detects bots by serving CAPTCHAs in user-facing components of the application, like login and search. However, threat actors can easily bypass them. (There are dozens of automated services available for this, e.g. 2Captcha charges $2.99 per 1,000 CAPTCHAs solved.)
ATO (Account Takeover) Prevention
Attackers have a variety of techniques for attempting to compromise customer accounts. Therefore, organizations need reliable defenses to prevent them from succeeding. AWS WAF includes some capabilities for this, but there are several issues.
Limitation: Not Inherent to AWS WAF
Although most ATO attacks are waged by bots, AWS WAF Bot Control does not address them. Nor are they covered by AWS WAF’s rate limiting capabilities, as discussed earlier. Instead, Amazon offers AWS WAF Fraud Control, which is a separate service that must be purchased. Users must pay both fixed costs and variable fees to use it.
Limitation: Detection of ATO Attempts
AWS WAF Fraud Control relies upon a database of stolen credentials, to block login attempts that submit any of these credentials. This can detect many ATO attempts, but it can create problems when actual users are among those who have (unfortunately) re-used their credentials across different sites, and have had their credentials stolen from one of the others.
The move to microservices and distributed systems means that APIs feature heavily in modern infrastructure. Organizations need to protect this critical element of most public-facing software systems.
Amazon does not offer a specific product for defending APIs; AWS WAF can be used, but it’s not ideal for this purpose.
Limitation: No Universal API Security
AWS WAF users can only protect APIs through the AWS API Gateway managed service. Users that want to use their own configurations and infrastructure for API deployment need a different solution.
Limitation: Fewer Capabilities
All the other limitations of AWS WAF’s feature set also apply to APIs; rudimentary rate limiting, IP blacklisting won’t detect attackers who rotate IPs, and so on.
Further, some capabilities are worse for APIs. For example, as mentioned earlier, AWS WAF Bot Control relies on CAPTCHAs to distinguish bots from humans— but CAPTCHAs can’t be applied to API traffic.
AWS provides a fairly simple pricing structure for AWS WAF. Cost is generally broken down by web ACL, rule, and request count. Customers pay additional fees for “intelligent threat mitigation,” which describes features like Bot Control, CAPTCHA, and Account Takeover Prevention.
At first glance, AWS’ native security tools can seem inexpensive. However, customers with a significant web presence typically need the granularity of a larger number of web ACLs and rules, and they can find their bills growing significantly.
For example: a customer that deploys 100 Web ACLs, with 100 rules, 10 rule groups, and two Managed Rule groups, with 10 million requests per month would pay approximately $21,706.00 per month. The cost associated with defining rules scales much more quickly versus the number of requests served. Note that this also does not include any network transit costs associated with this traffic, which can also drive significant expenses.
Is AWS WAF Enough?
There are many situations outside of the scope of AWS WAF. Examples:
- Production services using non-managed services, such as running proxies on EC2 instances.
- Multiple types of traffic with diverse metadata that needs to be logged and evaluated before a block decision.
- Software architecture patterns that are not common to typical front-end infrastructure.
- A microservice architecture supporting a web frontend, but the organization doesn’t have the staff resources to build internal cloud platforms.
What about situations where AWS WAF would seem to be a great fit? For example, an organization that serves all its production traffic through supported AWS Managed Services, has only one or two primary types of frontend application traffic, and uses an architecture that doesn’t require an exotic or novel network configuration—would AWS WAF be enough for them?
No, probably not. As we saw above, AWS WAF is a “good, but not great” security tool that includes a number of significant limitations, which is why AWS WAF and AWS Shield are not enough to provide comprehensive security. Organizations with a significant Internet presence will need to look elsewhere for robust defenses against today’s Internet threats.
Getting Effective Security for AWS Workloads
Reblaze is a cloud native web security platform that is fully integrated with Amazon Web Services.
Reblaze is a fully managed solution, maintained for you by a team of security professionals. No manual configuration or fine-tuning is required, and it is always up-to-date. As new threats arise, updates are deployed immediately and automatically.
If your organization is using or considering AWS WAF, you should first consider getting a demo of Reblaze to see all the options available to you.