In today's interconnected digital world, automation is everywhere. From internal monitoring tools to third-party partners integrating with your APIs, "bots" aren't always the bad guys. However, distinguishing between beneficial automation and malicious actors can be a significant challenge for web application firewalls (WAFs). Fastly's Next-Gen WAF offers a sophisticated solution: signal exclusion rules, allowing you to keep your trusted automation running smoothly without compromising your security posture.
The Signals We're Taming
Fastly's Next-Gen WAF is adept at identifying various types of automated traffic. For your trusted internal tools and partner integrations, you might find them inadvertently triggering signals such as:
SUSPECTED-BOT.HEADLESS
SUSPECTED-BOT
SUSPECTED-BAD-BOT
SUSPECTED-BAD-BOT.HEADLESS
These signals are crucial for identifying genuine threats, but when applied to your own legitimate automation, they can lead to false positives and disrupt essential operations.
Why Exclude? The Case for Precision
The goal isn't to ignore bot activity entirely, but to apply intelligence. Your internal systems and trusted partners are vital for your business. Blocking or flagging their legitimate requests as malicious bots can cause service interruptions, data discrepancies, and operational headaches. Signal exclusion rules provide the precision needed to differentiate between unwanted bot activity and necessary automation.
The Fastly Solution: Signal Exclusion Rules
A signal exclusion rule is a powerful feature within Fastly's Next-Gen WAF that prevents requests matching a specific pattern from being tagged with a particular system signal. This is a key distinction: instead of bypassing the WAF entirely, you're simply telling the WAF, "Do not apply a specific bot signal to requests that match this condition."
Identifying Your Trusted Automation
The effectiveness of your signal exclusion rules hinges on accurately identifying your trusted automation. Here are the most effective methods:
The Preferred Method: HTTP Headers (e.g., API Keys)
The most robust and flexible way to identify your trusted automation is by requiring them to send a unique HTTP header with their requests. This could be:
A custom API key: For example,
X-API-Key: your-secret-automation-key.A specific User-Agent string: While
User-Agentcan be spoofed, a unique and complex string known only to your trusted automation can be effective when combined with other factors.
How it works: You configure a signal exclusion rule to look for a specific HTTP header field and value. If a request contains this header, the specified bot signals will not be applied. This method is highly recommended because it's difficult for malicious actors to guess or replicate, and it's not tied to potentially dynamic network characteristics.
The Alternative: IP Addresses (with a word of caution)
You can also identify trusted automation by their source IP addresses.
How it works: You create a list of known IP addresses or CIDR ranges belonging to your internal tools or partners. The signal exclusion rule then prevents bot signals from being applied to requests originating from these IPs.
Crucial Caveat: While straightforward, relying solely on IP addresses can be risky. If your partners or internal tools use shared hosting environments, their IP addresses might also be used by other, untrusted entities. This could inadvertently exclude malicious traffic originating from the same IP range. Always exercise caution and regularly review IP-based exclusions.
Beyond "Allow": Maintaining Robust Protection
One of the significant advantages of using signal exclusion rules instead of a simple ALLOW action in a request rule is the continued protection against other threats.
If you were to create a request rule with an ALLOW action for your trusted automation, those requests would bypass all WAF inspection. This means that if a trusted partner's system were compromised, or if an internal tool had a vulnerability, attacks like SQL Injection or Command Execution originating from them would go undetected by your WAF.
Signal exclusion rules, however, are more granular. They only prevent the tagging of specific bot signals. All other WAF rules – designed to detect and mitigate common web exploits – remain active. This ensures that even if a trusted source were to become a vector for an attack, your Fastly Next-Gen WAF would still be on guard, providing comprehensive protection.
How to Implement (High-Level Steps)
Implementing a signal exclusion rule is typically done within your Fastly Next-Gen WAF configuration:
1. Navigate to your Next-Gen WAF settings.
2. Create a new signal exclusion rule.
3. Define the conditions for exclusion. (As a note, this example is not an exact representation for how the rule is constructed in the UI). For example:
request_headers.nameequalsx-api-keyANDrequest_headers.valueequalsyour-secret-keyOR request.ipis inyour-trusted-ip-list
4. Select the specific signals you wish to exclude, such as SUSPECTED-BOT.HEADLESS, SUSPECTED-BOT, SUSPECTED-BAD-BOT, and SUSPECTED-BAD-BOT.HEADLESS. Multiple rules may be needed for each Signal.
5. Save and deploy your changes.
Conclusion
Fastly's Next-Gen WAF signal exclusion rules offer an intelligent and secure way to manage your automated traffic. By precisely identifying and excluding your trusted internal tooling and third-party partners from bot detection signals, you can ensure smooth operations while maintaining a robust defence against genuine threats. This approach minimizes false positives, enhances your security posture, and allows your business to leverage automation without unnecessary friction.
Ready to fine-tune your bot management strategy? Explore Fastly's Next-Gen WAF documentation to implement smart signal exclusion rules today.