10 Pro Tips for Getting the Most out of your Next-Gen WAF

As Fastly’s Technical Account Management team, we guide our customers in using our Next-Gen WAF (powered by Signal Sciences) as effectively as possible. Every day, we work directly with customers across different verticals – answering questions and sharing guidance to ensure everything is running smoothly. 

Today, we want to share that knowledge with you. Here’s a list of recommended practices for all Fastly customers, so everyone can get the most out of our Next-Gen WAF. 

1. Prevent Client IP Spoofing

This is a very basic step, but it often gets overlooked. We need to be able to capture the true client IP – otherwise, an attacker can end up bypassing our WAF simply by changing the necessary headers to avoid being blocked. 

The Next-Gen WAF agent uses the X-Forwarded-For header to identify the client IP address-- for example, client-ip-header="Fastly-Client-IP". This header can be spoofed pretty easily by simply passing a different IP in the header. 

In our customer documentation, we address this concern. The proposed solution is to pass a different header, and then configure the agent to use that header to determine the true client IP. It also recommends configuring the agent to read the X-Forwarded-For IP address from right to left, instead of the default left to right, by setting the local-networks="private" configuration.

For on-premise (module/agent) deployments, we want to be sure we are validating the real IP address before the NGWAF agent receives the header. For example, NGINX has the ngx_http_realip_module that will validate the client IP address.

Customers who are using Fastly CDN in front of NGWAF, will benefit from being able to pass the IP address using custom VCL, as documented here. This will pass the true client IP to the Fastly-Client-IP header.

The configuration of the alternative headers can be performed in the UI. For non-Cloud WAF deployments, the steps are documented here.

10 Pro Tips Image 1

For Cloud WAF deployments, we can set this up on the Cloud WAF instance by selecting Advanced under Instance location, to specify the appropriate header that should be used:

10 Pro Tips Image 2

Now that we have identified which headers to use as your true client IP address, we can leverage thresholds to our advantage by keying off of IP and Signals.

2. Tune Attack Thresholds

We have the ability to see whether IPs are approaching thresholds, but not crossing them, by navigating to Observed Sources -> Suspicious IPs.

10 Pro Tips Image 3

Thresholding is an important feature of our NGWAF because it allows us to prevent blocking legitimate traffic in the event of a false positive. When IPs are not hitting the current thresholds for Attack Signals, it means the NGWAF can be missing potential attacks. 

The default threshold for all attack signals is 50 requests in one minute. But in the screenshot above, you can see that there are two IPs that are over the 75% threshold range. This means about 37 SQLi requests were allowed. In a lot of cases, reducing that threshold makes sense because we may not want to allow too many attacks. Testing and validation should be considered before modifying the threshold in order to ensure there is no production-impacting issue.

Using the SQLi attack from the above example, we would want to reduce the attack threshold for SQLi down to 25 in one minute.

Typically, you may want to lower this gradually – or, in some cases, you might want to block all Attack requests like SQLi outright. This can be done by creating a request rule to block that signal.

3. Block Attacks from Malicious IPs

This request rule allows you to use the Malicious IP signals and block attack requests immediately, without waiting for thresholds to kick in. 

The NGWAF pulls in IP information from multiple sources. One source is the SANS Malicious IP list, which is regularly imported from the SANS Internet Storm Center. IPs are added to this list for a variety of reasons such as port scanning, being identified as bot sources, or ransomware sources. IPs on this list are tagged with the signal Malicious IP. The NGWAF also regularly imports a list of TOR exit nodes from The Tor Project. These IPs are tagged with the signal Tor Traffic. Lastly, we have IP reputation capabilities built within the NGWAF platform, where we observe attack behavior across all NGWAF customers and add them to our internal threat reputation list. These IPs are tagged with a signal SigSci IP

These three signals may not guarantee the actor is behaving maliciously, which is why it is recommended to use these signals in coordination with the Attack system signals already defined in the NGWAF. As a result, the rule below will immediately block anyone trying to attack your application from a known threat reputation source.

10 Pro Tips Image 4

4. Block Requests from Countries on the OFAC List

We can build a rule that will block any request from countries in the Office of Foreign Assets Control (OFAC) Countries list. The screenshot below shows a Site List used to identify the country codes on the list.

10 Pro Tips Image 510 Pro Tips Image 6

You’ll notice, we aren’t specifying any regions in this list. That’s because we need more than just the country code to determine the geo-location of a source IP. 

One way to address this is to provision your Fastly CDN to pass the ASN information in a header. Use the ASN header to build a list of ASNs that shouldn’t be allowed to access your application by creating a similar list and request rule.

5. Block Requests from Known Bad User Agents

This is a straightforward action to take. We want to make sure a valid User Agent is being used to access the application. We can create a list of User Agents we don’t allow and block them immediately. Here is a list of User Agents I don’t expect to hit my application at all:

10 Pro Tips Image 7

Note: This list is case sensitive, so you may want to consider using Wildcards to consider all possibilities.

I can use this list in a request rule to block immediately:

10 Pro Tips Image 8

6. Block Requests with Invalid Host Header

This rule blocks anyone trying to access the application directly by IP address, or not even filling in the host header. We can create a list of valid domains that should be used to access the application, or you can list them out as seen below:

10 Pro Tips Image 9

I’m using this rule to identify when the host header matches the domain of my application, simply add a signal called Domain Request.

Next, create another request rule that will block anything that does not match the Domain Request signal. Then add a signal tagging that request as Invalid Request.

10 Pro Tips Image 10

7. Rate Limiting Access to Domain (Application DDoS)

Note: The Premier license is required to leverage this functionality.

Volumetric rate-limiting at the application layer to protect against DDoS attacks is a common ask. Using the previous rule set to identify domain requests, we can now create a rate limit rule to throttle the traffic.

10 Pro Tips Image 11

In this example, if we see 100 Domain Requests in a minute, we should block access to the domain and respond with a 429 response code.

8. Rate Limiting Enumeration Attempts

Note: The Premier license is required to leverage this functionality.

Oftentimes attackers will try to enumerate the application or API by trying various techniques. For example, if an attacker tries to brute-force access files and directories or carry out credential stuffing attacks, they will likely generate a lot of 4XX and 5XX errors

In order to prevent the enumeration attempt from getting too far, we can leverage rate limit rules to help protect the app or API. This rule will cover more broad use cases, but can be modified as needed depending on the situation.

10 Pro Tips Image 12

In this screenshot, we are looking for any requests that generate a 4XX or 5XX response. When we see that request, we are going to consider that to be an enumeration attempt. The counting signal (in this case, Suspected Attacker) will keep track of that attempt. The action signal, Domain Request (set up in a previous step) will identify the domain we are going to block access to (see the previous section). This is to block the subsequent request after the threshold of enumeration attempts has been met.

9. Notifications for New Features and Releases

Enable notifications for New Feature Announcements and Releases. New Feature Announcements provide information on product enhancements for Agent releases only. This will typically include bug fixes or enhancements to the agent that have been applied to the agent release version.

Set up notifications by navigating to Corp Manage > Corp Integration with the following events selected:

10 Pro Tips Image 13

New Feature Announcements are posted here: Announcements - Signal Sciences Help Center.

Release Created events are for Agent releases only, which are posted here: Agent - Signal Sciences Help Center.

10. Logging with APIs or Syslog

Capturing log data is important, especially when it comes to the observability of your security product. This could include taking the log data from the Next-Gen WAF and exporting it to your SIEM. There are a number of ways we can accomplish this, but it depends on the scenario. This blog post provides details on how to accomplish this.

If you’re comfortable with capturing sample/redacted data, then using the API to extract the data from the NGWAF dashboard will be the best solution. Here is an example of a Python script you can use to extract the data using the API. If you are using Splunk, they can leverage the Splunk App, which also uses the API.

If you’re more comfortable with unsampled/unredacted data, then the next option would be to leverage Syslog and capture agent logs to forward to a Syslog server. To do this, we need to enable debug logging on the agent. Add the following configurations to the agent.conf:

debug-log-web-inputs = 1
debug-log-web-outputs = 1
log-out = “/var/log/sigsci.log”

For customers using Cloud WAF, the option to enable this debug logging option is not available today.

Protect Your Apps with the Next-Gen WAF

We hope these tips will help you use Fastly’s Next-Gen WAF to its full extent – protecting your applications, wherever they live, better than ever before. And if you ever need further guidance, the Fastly TAM team is here to help.

To learn more about our Next-Gen WAF, visit the product page.


Published

7 min read

Want to continue the conversation?
Schedule time with an expert
Share this post

The Fastly Security Technical Account Management team is a security focused group that wants to make sure our customers are successful by leveraging Fastly Security products to their full potential. They partner with customers by understanding their application security requirements and making recommendations. The team consists of skilled security experts that have seen it all before and want to help you stay on top of what is seen in the field.


Meet the team:



  • Aneel Dadani, Manager, Security TAM

  • Orlando Barrera, Senior Security TAM

  • Farzam Ebadypour, Senior Security TAM

  • Ryan Miller, Senior Security TAM

  • Pratiksha Patil, Senior Security TAM

  • Siaka Doumbia, Senior Security TAM