Waf Charm

Blog

AWS WAF

AWS WAF supports IP match based on HTTP header fields like X-Forwarded-For

This post was originally published in Japanese in the past.

Table of Contents

  1. 1. Introduction
  2. 2. What is X-Forwarded-For
  3. 3. Headers other than X-Forwarded-For
  4. 4. How to use the feature
  5. 5. Limitations on WafCharm
  6. 6. Conclusion

1. Introduction

On July 9th, 2020 (US local time), support for originating IP addresses in the HTTP header field such as X-Forwarded-For was added to AWS WAF.

This is good news for users who applied WAF to CloudFront and ALB individually since they reduce the cost of WAF by combining and attaching WAF just to ALB.

Let’s check the details of the update.

Support for X-Forwarded-For (XFF) header is now available for AWS WAF

2. What is X-Forwarded-For

X-Forwarded-For is one of the HTTP header fields and is the de facto standard for determining the originating IP address of the client when the request goes through load balancers or proxies.

When a request goes through proxies or load balancers, the web server will recognize the IP address of the last proxy as the IP address of the request and cannot analyze or control the originating IP address. However, you can obtain the client’s IP address by using X-Forwarded-For.

For example, in terms of an ALB under a CDN, the requester’s IP address will be the CDN’s IP address from the ALB’s point of view. If the IP address were to be regulated, the access from CDN could be blocked.

Previously you could only regulate IP addresses from CDN, but by using X-Forwarded-For header content to regulate requests, ALB can also regulate IP addresses.

Keep in mind that X-Forwarded-For relies on the fact that the proxy the requests go through in between provides correct information, so you must utilize information from a trustworthy proxy.

3. Headers other than X-Forwarded-For

There are examples other than X-Forwarded-For to accomplish the same function.

For example, a CDN provider could apply an original header to pass client IP addresses when the requests go through a CDN.

Typical headers used for CDN include True-Client-IP, CF-Connecting-IP, and Fastly-Client-IP.
The format of the information listed in the header is provided by vendors, so check their official information for which header field to check.

As mentioned above, it is critical to only utilize information provided by a reliable proxy.
It is necessary to see if the requester’s IP address is from the IP range provided by the CDN and uses their original header field, in which case that information can be trusted.

4. How to use the feature

Let’s take a look at the actual setting page for the IP address rule.

The setting has been updated to select between “Source IP address” or “IP address in header” options.

Specify the header name to the [Header field name] field. The default value is “X-Forwarded-For.”

You can specify the position of the value in the IP address list of X-Forwarded-For to check for.

In X-Forwarded-For, an IP address is added for every single proxy that the request goes through.
It is structured like a list (client1, proxy1, proxy2) starting with a client IP address on the left, followed by the IP addresses of proxies the request went through.

You can configure the rule to check the actual client IP address or check if the request is coming from the correct proxy as expected depending on the structure of your environment.

You could also use this feature for Geo match and rate-based rules, but the position of the IP address is fixed.


Refer to the blog posts below for procedures to create rules.


AWS WAF Classic

new AWS WAF

Rate-based rules


5. Limitations on WafCharm

There is an XFF header option in the WafCharm Dashboard. If your environment uses CloudFront before ALB or other similar structures, consider using the option. Refer to the “XFF header options” section of the Help page of WafCharm Dashboard.

You can also create your own rule.

6. Conclusion

For users using CDN such as CloudFront who wanted to attach AWS WAF only to ALB, this is a much-needed feature.

In order to lessen unnecessary requests, it is desirable to consider regulating both CDN and ALB individually, but if you want to avoid maintaining two WAFs or reduce the cost, this feature could be worth considering.