Protecting Applications Using AWS WAF

-

 


Amazon's Web Application Firewall (WAF) allows for seamless integration with existing AWS resources and easy configuration. It may have its limitations, but it provides many common protections for web applications and can be spun up very quickly.

Everything I've included below can be found in Amazon's documentation. However, I've highlighted parts that I found particularly important and left other details out.

AWS WAF Classic vs AWS WAF

If you're still on WAF Classic, you should try to migrate to AWS WAF. The "new" version has been out several years (though rules do not automatically convert and Amazon's conversion tool does not work in all scenarios). There are a number of new capabilities and features, notably managed rules. And if you have version control and infrastructure as code (IaC) implemented widely throughout your environment, rules are now JSON objects.

I will leave it at that as I suspect most people are on the current AWS WAF.

Resources AWS WAF Protects

AWS WAF protects the following types of resources:

  • CloudFront distributions
  • Amazon API Gateways
  • Application Load Balancers
  • AppSync GraphQL API
  • Cognito user pool
  • App Runner service
  • Verified Access instance
The WAF Web ACL must be in the same region as the resource it's protecting. A special case worth noting is CloudFront distributions -- you must use the US East Region when creating a WAF to apply to a CloudFront distribution.

AWS WAF Components

The AWS WAF consists of the following
  • Web ACLs
  • Rules
  • Rule Groups
Web ACLs

Web ACLs are the AWS WAF resource you assign to protect another AWS Resource -- for example, an Application Load Balancer. Rules, and optionally Rule Groups, that you make comprise the Web ACL are ultimately what provide the protection against resources.

Rules

There are two types of rules that can be added to AWS WAF -- Managed and Custom. Custom rules allow you to add IP sets, a previously create Rule Group, or use Amazon's rule builder.

Managed rules allow you to add a pre-defined rule(s) created by Amazon or a third-party company. This functionality along with the ease of configuration on your Web ACL are definitely the biggest takeaway from AWS WAF. 


Some examples of AWS Managed rules are:
  • Core rule set - contains rules that protect against general vulnerabilities in web applications including those in OWASP publications.
  • Anonymous IP list - blocks requests from services that obfuscate IP addresses. Tor, VPNs, etc.
  • Amazon IP Reputation List - blocks requests based on IP address from those sources determined by Amazon Threat Intelligence.
  • Known Bad Inputs - Contains rules that allow you to block request patterns that are known to be invalid and are associated with exploitation or discovery of vulnerabilities.
Others, including those created by third parties, explicitly block OWASP Top 10 vulnerabilities, high profile CVE vulnerabilities, and more. 

Rule Groups are exactly what the name implies. If you want to manage / add multiple rules together, Rule Groups help organize them and allow you to apply all the associated rules to a Web ACL.

Managing WAF Resources - Web ACL Capacity Units (WCUs)

Web ACL Capacity Units (WCUs) are used to manage operating resources used in the AWS WAF. Each task that is performed by the AWS WAF is weighted differently depending on the amount of processing power it takes to perform that task. WCUs are the unit of measurement for this and are reflected in the various rules, rule groups, and web ACLs as well. For example, a rule that checks for specified source IP addresses will use fewer WCUs than a rule that checks requests for a regex pattern.


Notice the "Capacity" column available in the list of AWS Managed Rules. This reflects the number of WCUs for each rule / rule set. This will need to be kept in mind as you add rules to your web ACL as AWS enforces a maximum of 5,000 per web ACL.

A summary of important WCU rules to note:
  • The maximum capacity of a Rule Group is 5,000 WCU.
    • Note that the capacity is set at rule group creation and it cannot be changed after!
  • The maximum capacity of a Web ACL is 5,000 WCU.
  • Different Rules have different WCU requirements. Note these as you add rules to your Web ACL.

AWS WAF Pricing

AWS has a pricing page for AWS WAF that will update over time. This blog post likely won't, but it is current for the time it's being written. 


This is straight-forward enough, but one thing to note is that asterisk at the end of the "Request" pricing explanation.

* You will be charged an additional $0.20 per million requests for each 500 WCUs the Web ACL uses beyond the default allocation of 1500. In addition, you will be charged $0.30 per million requests for each additional 16KB analyzed beyond the default body inspection limit. For more information about default limits, see Developer Guide.

AWS Managed Rules have additional charges in addition to these basic charges provided here.

Body Inspection Limits

A long-time criticism of the AWS WAF has been its 8KB body inspection limit. Thankfully, this has been increased by AWS to 64KB under most circumstances. Additional details on AWS WAF's managing body inspection limits.

By default, AWS will forward any request that exceeds the maximum request body size to the underlying resource. This has obvious security repercussions and has been blogged and PoC'd before (I won't link anything here, but feel free to Google it).

Thankfully, AWS has written a guide on blocking requests that exceed the maximum request body. This applies to the new maximum as well.

Conclusion

The AWS WAF is easy to setup and apply to resources, but details become noteworthy when managing rules in ACLs and their associated WCUs, keeping track of pricing assuming you don't have an infinite budget, and we never even covered logging. 

Comments

Post a Comment

Popular Posts

Hashcat - Cracking MD5 and NTLM Hashes

-
Image
Today we'll be exploring Hashcat -- "the world’s fastest and most advanced password recovery utility". This, along with similar tools, should be used only for password recovery, pentest engagements, CTFs, etc and never for illegal purposes. I could write an entire series about the capabilities Hashcat provides, but we will cover a few basic examples for now ( besides, Hashcat does a pretty good job of that themselves ): Crack MD5 hashes using the rockyou.txt wordlist. Crack NTLM hashes using the rockyou.txt wordlist. Crack NTLM hashes using a mask attack (modified brute force). I'll be using Kali Linux as Hashcat comes pre-installed, but Hashcat can run on Windows, macOS, and other Linux distributions as well. As you'll see, I'll be using some lists of hashes I made previously. Tools to generate hashes using dozens of algorithms are available online -- just save the output as a text file if you want to follow along. Cracking MD5 Hashes Using rockyou.txt Wordl
Read more

Configuring Secure Ciphers Suites and TLS

-
Image
Hey everyone, today we're back on cipher suites. If you want a refresher of TLS and secure cipher suites overall, check out my previous post . There are many instances in which you'll need to edit cipher suites on a system -- compliance efforts, CIS benchmarks, or simply ensuring your system doesn't use insecure suites. There are a few ways to go about this and I'll detail two of them now: IIS Crypto and the Windows registry. IIS Crypto My favorite way of editing TLS versions and cipher suites is using IIS Crypto . IIS Crypto allows you to select your desired TLS/SSL version, cipher suites, and backup the registry, all with a few mouse clicks. Only downside is that it's Windows only (even the command line version). This is what IIS Crypto will look like on an unmodified Windows 10 system. Note the separate  Server Protocols  and  Client Protocols  sections. These are important to keep straight depending on what system is listening for connections and what system is
Read more

Configuring SSH Key Based Authentication

-
Image
Overview Most personal computers and many organizations running Linux servers utilize password-based authentication. This is what most of us are used to -- you enter a username and password in order to authenticate your account and gain access to a system. While straightforward and commonplace, this isn't the best solution in most cases. Today I'll be explaining why key based authentication is more convenient, more secure, and allows for automation of tasks without saving credentials in plain-text in a text file. Key based authentication involves the use of private and public keys ( public-key cryptography ). The private key is stored on the client and the public key is stored on the server in a special file ( ~/.ssh/authorized_keys ). This allows any system with the corresponding private key to login to the server where we just stored the public key. Our steps are: Generate key pair (public / private key). Transfer public key and add it to the authorized_keys file on the remot
Read more