1. Home
2. Guides
3. Web Application Firewall

• [JA] 日本語

Fastly offers a web application firewall (WAF) security service that allows you to detect malicious request traffic and log or log and block that traffic before it reaches your web application. The Fastly WAF provides rules that detect and block potential attacks. The rules are collected into a policy and deployed within your Fastly service at the edge. To get started, email our sales team for product information.

How the Fastly WAF works

The Fastly WAF is designed to protect production web applications running over HTTP or HTTPS against known vulnerabilities and common attacks such as cross-site scripting (XSS) and SQL injection. The Fastly WAF can provide a layer of protection logically positioned at the client edge of your distributed application to detect and block malicious activity from exploiting vulnerabilities in web applications and APIs.

Like traditional network firewall appliances, Fastly WAF uses predetermined security rules to monitor and control incoming traffic to your web application. A network firewall works at the IP level and often blocks IP addresses from untrusted networks, preventing them from gaining access to a private network. Unlike firewalls at the network or transport layer level, the Fastly WAF works by analyzing web traffic primarily at the HTTP application layer. It reads all HTTP(S) headers and the post body of the HTTP(S) requests that it inspects and runs them through a rule set selected for your service environment.

Fastly provides a default WAF rule set to which you can add additional rule sets to help protect against application-specific attacks. Once the Fastly WAF is enabled for a version of your service, you can change the status of any individual rule to logging, blocking, or disabled mode. Rule changes are versionless and become effective immediately.

Enabling the Fastly WAF

Enabling Fastly WAF doesn't require modifications to your web application or origin servers. Contact our sales team to get started.

Refining the default WAF policy once it's enabled

Once you purchase the Fastly WAF, our customer support team will enable it with the default WAF policy for any service you've provided a service ID for. They will then work closely with you on additional configuration refinements, including:

• setting up a logging endpoint,
• selecting rule sets and a prefetch condition, and
• optionally customizing the request responses.

You can then begin monitoring logs to determine which requests to your origin are legitimate and which you should consider blocking to protect your origin.

Setting up a logging endpoint

To begin monitoring requests for potential malicious activity, set up remote logging so you can log WAF variables. You can use an existing logging endpoint or add a new endpoint specially for Fastly WAF. You'll use the information provided in the logs to monitor WAF events.

Selecting rule sets

Fastly provides a default WAF rule set based on Trustwave ModSecurity Rules and the OWASP Top Ten. The default rule set is designed to help you monitor web application traffic for a wide range of common attacks.

Fastly adds a default prefetch condition (!req.backend.is_shield) for the WAF policy. This ensures that the Fastly WAF inspects traffic to the origin and accounts for whether or not a service has shielding configured.

You can modify the prefetch condition. For example, you could update the prefetch statement to run the WAF rule set on origin traffic and requests from IP addresses that aren't allowlisted:

1
curl -v -X PUT https://api.fastly.com/service/<your Fastly service ID>/version/<version_id>/condition/Waf_Prefetch -H "Fastly-Key: FASTLY_API_TOKEN" -H "Content-Type: application/json" -d '{"statement":"!req.backend.is_shield && !(client.ip ~ allowlist)"}' -H "Accept: application/json"

Fastly can add additional rule sets for specific applications or technologies (e.g., WordPress, Drupal, PHP, .Net). Keep in mind that adding additional rule sets can increase latency for requests being evaluated against the published WAF policy.

Once you've selected rule sets, Fastly will maintain rules sourced by Fastly to keep them current. However, you'll need to notify us if you modify the applications or technologies that are present at the origin.

Customizing the response

Fastly's customer support team creates a custom response and assigns an HTTP status code for all requests that Fastly WAF blocks. If you've configured Fastly WAF to block requests, that response will be served directly from the cache when a request matches a rule. If you would like to customize the response, use the web interface to change the following:

• MIME Type: The content type of the response.
• Response: The content served when delivering the response.

Monitoring the Fastly WAF

You can use the Fastly WAF dashboard to monitor the Fastly WAF deployed within your Fastly service.

Disabling Fastly WAF for your service

Contact our customer support team at support@fastly.com to disable the Fastly WAF for your service.

Limitations

All WAF products that exist today have several limitations:

• False positives: Any WAF can mistake good traffic for bad. This is why we strongly recommend that you monitor your logs for a minimum of two weeks before blocking traffic. You don't want start blocking traffic with rules that are generating false positives.
• DNS configuration: A WAF only works when traffic is directed through it. It cannot protect against malicious requests that are sent to domain names or IP addresses that are not specified in your WAF configuration.
• Effective rule sets: A WAF is only as effective as its rule sets. You should add rule sets as necessary to protect your specific web application.
• Custom application vulnerabilities: If attackers discover a vulnerability unique to your application or the technologies you use, and your WAF configuration does not have a rule to protect against exploits for that particular vulnerability, it will not be able to protect your application in that instance. Customer support can work with you to add additional rule sets to help protect against these types of attacks. If you need more protection than the rule sets provide, customer support can work with you to create custom VCL to help block malicious requests.
• Inspection of HTTP and HTTPS traffic only: A WAF only inspects HTTP or HTTPS requests. It will not process any TCP, UDP, or ICMP requests.

LA limitations

The Fastly WAF is part of a limited availability release and it has the following limitations:

• Inspecting the WAF rule set is challenging due to formatting issues with cURL.
• Changes are managed via the API.

Security products note

No security product, such as a WAF or DDoS mitigation product, including those security services offered by Fastly, will detect or prevent all possible attacks or threats. Subscribers should maintain appropriate security controls on all web applications and origins, and the use of Fastly's security products do not relieve subscribers of this obligation. Subscribers should test and validate the effectiveness of Fastly's security services to the extent possible prior to deploying these services in production, and continuously monitor their performance and adjust these services as appropriate to address changes in the Subscriber's web applications, origin services, and configurations of the other aspects of the Subscriber's Fastly services.

Additional resources:

• API documentation for the Fastly WAF
• OWASP Best Practices: Use of Web Application Firewalls