Start here

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 site.
• (optional) test and adjust the protection of your staging site at increasing blocking levels.
• add the Next-Gen WAF to your production site.
• test and adjust the protection of your production site at increasing blocking levels.
• monitor your production traffic and address issues.

1. Plan the implementation

To get started with Next-Gen WAF, contact our Sales team. They will help you select the platform tier that's right for your business needs. Platform tiers determine which Next-Gen WAF features are available for you to use. The higher the tier, the more features you can access.

Our Solutions Engineering team will also help you figure out how to integrate the Next-Gen WAF product into your request flow. The Next-Gen WAF can be deployed in the following ways:

• On Fastly’s Edge Cloud platform (Edge). The Edge deployment method is hosted on Fastly’s Edge Cloud platform via our global network of POPs. To use this method, you must have a Fastly delivery account. You'll also need to update your DNS records to point to Fastly and add your Next-Gen WAF instance as an edge security service to your Fastly services.
• Directly on your web servers within your infrastructure (Core). The Core deployment method is hosted directly on your web servers within your infrastructure and consists of two components: the agent and the module. The agent is a small process that provides an interface between your web server and our cloud engine. The module can exist as a plugin to your web server or as a language- or framework-specific implementation. You can also use the Core deployment method without a module by running the agent in reverse proxy mode.
• On Fastly’s cloud-hosted infrastructure (Cloud WAF). The Cloud WAF deployment method is hosted on Fastly’s cloud infrastructure and consists of several Cloud WAF instances. Each instance is made up of a load balancer along with a minimum of three Next-Gen WAF agents, each operating in reverse proxy mode. Each agent is installed on separate redundant machines. To use the Cloud WAF deployment method, you must upload a TLS certificate, add an origin server using the Next-Gen WAF hosted dashboard, and update your DNS records to point to the appropriate servers.

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

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

Once you have a Next-Gen WAF account, you can set up your deployment method for your staging or production site and verify the Next-Gen WAF is monitoring site traffic.

Set up your deployment method

To set up your deployment method for your site, 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 site, 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 setting.

Temporarily create a request rule to log legitimate traffic

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 site:

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 site, make a handful of requests to your site. 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 site at increasing blocking levels

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

Since your site is new, the Next-Gen WAF will monitor your site and allow all traffic. It doesn't block it yet. Blocking behavior is controlled by the Agent mode setting. The Agent mode 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: enables request logging. This option provides visibility into your web traffic but doesn’t actively protect your site.
• Off: disables request processing. The agent doesn’t block or log requests.

By default, the Agent mode for your site will be set to Not Blocking.

Test (and understand) attack detection

In Not Blocking 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 define flagging parameters. Specifically, when the number of requests from an IP address meets the signal count threshold for a site alert, the IP address is flagged and select, subsequent requests from the IP address are blocked or logged for a set period of time.

As your site 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 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 site 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, set the Immediate blocking setting on the Attack Thresholds page.

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.

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).

If you're on the Essentials platform, create a request rule for each individual attack signal. Each rule should be based on one attack signal 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 site and make sure the Next-Gen WAF blocks and allows the correct traffic:

• Custom site alerts. Raise or lower system site alert thresholds by creating custom site alerts. Thresholds for the system site 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 site.
• Templated rules. You can 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. You can 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 site, you can monitor site traffic and any blocking actions the WAF takes via the Next-Gen WAF console (e.g., Corp Overview page, Site Overview page, and Events page). If you notice any concerning behavior, you can address the issue by creating a rule or custom site 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.