Start here (Next-Gen WAF)

Welcome! This guide provides a high-level overview of the steps needed to set up and configure the Next-Gen WAF product. Guided by our Sales and Solutions Engineering staff, you will:

  • select the platform tier and deployment method that is right for you.

  • (optional) add the Next-Gen WAF to your staging website.

    NOTE

    While optional, we recommend adding the Next-Gen WAF to a staging website before a production website. This helps ensure the Next-Gen WAF accounts for your business logic, performs the way you want it to, and allows all legitimate traffic.

  • (optional) test and adjust the protection of your staging website at increasing blocking levels.

  • add the Next-Gen WAF to your production website.

  • test and adjust the protection of your production website at increasing blocking levels.

  • monitor your production traffic and address issues.

IMPORTANT

We've created this page to help you get started with Fastly's Next-Gen WAF. If you're interested in learning about our Full-Site Delivery, check out our Full-Site Delivery Start here guide.

1. Plan the implementation

To get started with Next-Gen WAF, contact our Sales team. Based on your business needs, we will help you select a:

  • platform tier, which determines the Next-Gen WAF features that are available for you to use. The higher the tier, the more features you can access.
  • deployment method, which is how you integrate the Next-Gen WAF product into your request flow. The Next-Gen WAF can be deployed on Fastly’s Edge Cloud platform (Edge WAF), directly on the web servers within your infrastructure (Core WAF), and on Fastly’s cloud-hosted infrastructure (Cloud WAF).

After choosing a platform tier and deployment method, we will create a corp (also know as account) and at least one site (also known as workspace) for your use. A corp (account) is a company hub for managing all sites (workspaces), users, and corp-level (account-level) configurations that determine what type of requests should be allowed, logged, or blocked. A site (workspace) is a single web application, bundle of web applications, API, or microservice that the Next-Gen WAF can protect from attacks. Sites (workspaces) contain various site-level (workspace-level) configurations. Users are authenticated against a corp (account) and can be members of different sites (workspaces) in that corp (account).

We'll then give you access to the Next-Gen WAF product in either the Next-Gen WAF control panel or the Fastly control panel. From the control panel you have access to, you can manage your corp (account) and sites (workspaces).

2. Install Next-Gen WAF for your staging or production website

Once you have access to the Next-Gen WAF product, you can set up your deployment method for your staging or production website and verify the Next-Gen WAF is monitoring traffic.

Set up your deployment method

To set up your deployment method, follow the instructions on the appropriate installation guide.

Once your deployment method is in place, the Next-Gen WAF will immediately start monitoring traffic to your website, detecting malicious and anomalous requests, and populating request data to the web interface. To ensure legitimate traffic isn’t blocked, the Next-Gen WAF doesn’t block any requests initially. In step 3, you will enable blocking via the Agent mode (also known as Protection mode) setting.

Temporarily create a request rule to log legitimate traffic

NOTE

If you're on the Essentials platform, skip to the step where you test your staging or production website at increasing blocking levels. This step requires you to use custom signals, which the Essentials platform doesn't support.

By default and per our storage policy, the Next-Gen WAF only captures request data from malicious and anomalous traffic, not legitimate traffic. While this focused approach to storage can help limit the data in the web interface to attacks and suspicious behavior, you may want to temporarily log request data from a sample of your legitimate traffic to verify that the Next-Gen WAF is monitoring all traffic and to see which requests the Next-Gen WAF allows.

To do this, we’re going to leverage the power of signals. Signals are labels that identify an important request property. Depending on the payload, the Next-Gen WAF may tag a single request with multiple signals. The Next-Gen WAF relies on signals to help determine which requests to log and block.

To log request data from a sample of all traffic to your website:

  1. Create a custom signal for all traffic.
  2. Create a request rule that applies the signal to every request. Request rules are configurations that define when the Next-Gen WAF should allow, block, or tag certain requests on an individual basis.

We recommend disabling this rule once you are more familiar with the Next-Gen WAF’s attack detection capabilities.

Verify the Next-Gen WAF is working

To verify the Next-Gen WAF is monitoring your website, make a handful of requests to it. The Next-Gen WAF should log a sample of those requests and make the individual request data available on the Requests page of the web interface.

3. Test your staging or production website at increasing blocking levels

Once you’ve added the Next-Gen WAF to your website, you can begin testing and adjusting its protection.

Because it is new to your environment, the Next-Gen WAF will monitor your website and allow all traffic. It doesn't block it yet. Blocking behavior is controlled by the Agent mode (Protection mode) setting. This setting determines how request processing is handled. Options include:

  • Blocking: enables request blocking and logging. This option actively protects your web application and provides visibility into your web traffic. Legitimate traffic is still allowed.
  • Not Blocking (also known as Logging): enables request logging. This option provides visibility into your web traffic but doesn’t actively protect your website.
  • Off: disables request processing. The agent doesn’t block or log requests.

By default, the Agent mode (Protection mode) for your site (workspace) will be set to Not Blocking (Logging).

Test (and understand) attack detection

In Not Blocking (Logging) mode, the Next-Gen WAF detects and captures malicious and anomalous request data and allows all traffic. To verify the Next-Gen WAF is correctly identifying requests with attack payloads, you can use attack tooling to scan your website and simulate attacks. We like Nikto for testing because it can simulate a wide variety of vulnerabilities.

Once scanning is underway, you can use the web interface to see which requests contained attack payloads. Requests that contain attack payloads will be tagged with attack signals (e.g., Directory Traversal and XML Encoding Error).

Because the Nikto IP address sends a high volume of requests containing attacks over a short period of time, the Next-Gen WAF may flag the Nikto IP address. Site alerts (also known as workspace alerts) define flagging parameters. Specifically, when the number of requests from an IP address meets the signal count threshold for a site alert (workspace alert), the IP address is flagged and select, subsequent requests from the IP address are blocked or logged for a set period of time.

Because your website is in Not Blocking mode, subsequent requests from the Nikto IP address will be logged and allowed. In Blocking mode, the Next-Gen WAF would block requests that are from the Nikto IP addresses and that contain attack signals. Legitimate traffic from the Nikto IP address would still be allowed. After a set period of time, requests from Nikto IP addresses would no longer be blocked.

Implement threshold blocking

Once you have a better understanding of when IP addresses are flagged, you can change the Agent mode (Protection mode) to Blocking and run attack tooling to test the behavior. The Next-Gen WAF should block requests sent from flagged IP addresses and that have been tagged with an attack signal.

Implement instant blocking

Although threshold blocking handles attacks from bad actors who target your website with a high volume of attacks, it does not immediately block requests with attack payloads. To immediately block all requests that contain at least one attack signal, enable the Immediate blocking setting.

Alternatively, you can immediately block attacks that are from known bad actors and that have been tagged with an attack signal. How you do this depends on the platform you're on.

  1. Professional or Premier
  2. Essentials

If you're on the Professional or Premier platform:

  1. Create a list with every attack signal.
  2. Create a request rule that is based on the attack signal list and anomaly signals that indicate known bad actors (e.g., Tor Traffic, SigSci IP, and Malicious IP).

Adjust the protection and data privacy

With Blocking mode in place, you can use the following features to adjust the protection of your website and make sure the Next-Gen WAF blocks and allows the correct traffic:

  • Custom site alerts (custom workspace alerts). Raise or lower system site alert (system workspace alert) thresholds by creating custom site alerts (custom workspace alerts). Thresholds for the system site alerts (system workspace alerts) are based on historical patterns that we’ve seen across all customers. However, these thresholds may be set too high or low for your website.
  • Templated rules. Enable templated rules to help protect against Common Vulnerabilities and Exposures (CVE) and provide visibility into registrations, logins, and API requests. These rules are disabled by default for Premier or Professional platform customers and enabled by default for Essentials customers.
  • Request rules. Create request rules to allow, block, or tag certain requests on an individual basis. For example, you could make a rule to block all requests with specific headers, requests to certain paths, or requests originating from specific IP addresses.
  • Advanced rate limiting rules. You can create advanced rate limiting rules to block or tag requests from individual clients when a specific threshold (e.g., 100 requests in 1 minute) is passed. For example, you could create an advanced rate limiting rule to block all requests from an individual client after the number of 404s the client receives exceeds the defined cap. This would help prevent scraping and vulnerability scanning.
  • Signal exclusion rules. You can create signal exclusion rules to prevent requests from being tagged with certain signals. You can use signal exclusion rules to avoid false positives. For example, you may want to prevent requests that are from internal IP addresses and that failed to access an admin page from being tagged with the FORCEFULBROWSING signal.

You can also adjust the privacy of your request data. By default, we redact sensitive data from requests before they reach the platform backend. In addition to what we redact by default, you can specify additional fields to redact from requests. For example, you can create a custom redaction for a password field that is named foobar instead of password. You can also anonymize IP addresses.

4. Monitor your production traffic and address issues

Once the Next-Gen WAF is actively protecting your production website, you can monitor website traffic and any blocking actions the WAF takes via the control panel that you use to access the Next-Gen WAF.

  1. Next-Gen WAF control panel
  2. Fastly control panel

In the Next-Gen WAF control panel, you can monitor website traffic using the following pages:

If you notice any concerning behavior, you can address the issue by creating a rule or custom site alert (custom workspace alert) or reaching out to our Support team for help.

What’s next

Learn more about Fastly's products and features by exploring our documentation on https://docs.fastly.com. If you have questions, contact our Support team.

Was this guide helpful?

Do not use this form to send sensitive information. If you need assistance, contact support. This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.