The Importance of WAF Rules
Web Application Firewall (WAF) rules allow you to dig deep into packet information, and take corresponding actions, depending on their risk. A WAF tool sits at the very edge of the network: acting as a reverse proxy, it allows administrators to allow or block traffic based on criteria such as IP addresses, geolocation, and distinct traffic patterns. For example, if a business detects unusual activity from a certain IP range, it can configure the WAF to block those requests while ensuring access for legitimate users. Other rulesets may assess the previous activity of an IP address, or compare a device’s login activity against the resources requested. With each rule comes another parameter, against which a request’s risk can be measured.
With these in place, internal applications only handle legitimate requests – as long as the WAF rules are correctly maintained. This is why pre-configured rulesets are now the industry norm.
Common Attacks Prevented by Pre-Configured WAF Rules
To save time, most WAF tools include a default set of rules when deployed. These rules can incorporate a database of known attack signatures and poor IP addresses, which the WAF can block as soon as it’s set up. A simple example could be a rule allowing traffic from one IP address, like ‘A’, to a specific port, like ‘B’. When inbound traffic reaches the firewall, it performs a simple check on the packet’s source and destination—if the source is A and the destination is B, the packet is allowed.
But enterprise networks are far more complex than that – and many threats are essentially public domain by now. To mitigate this, many of the best WAFs rely on managed OWASP Core Rulesets (CRS), which are specially designed to detect common web vulnerabilities like SQL injection and cross-site scripting (XSS).
Let’s look at how some common threats are handled.
Scripting tra siti
The WAF analyzes incoming traffic for potentially harmful payloads. If the WAF detects suspicious scripts in form inputs or URLs, it blocks the request before the malicious code can execute in a user’s browser.
Attacchi DDoS
CRS helps mitigate distributed denial-of-service (DDoS) attacks by setting rate-limiting rules, and potentially blocking IP addresses that exceed a certain number of requests within a defined period. This helps maintain service availability during traffic spikes that may indicate an attack.
SQL injection protection
Similar to XSS prevention, modern WAFs can detect patterns in incoming requests that resemble SQL injection attempts, such as malformed SQL queries embedded in URLs or form fields. These requests are blocked to prevent attackers from gaining unauthorized access to databases. This layer of protection allows for attacks to be prevented on otherwise insecure databases that would otherwise need significant overhauls.
Best Practices for WAF Rules
WAF configurations are typically stored in a firewall configuration file, which contains all adjacent settings for the collections of individual rules it is following. This file is accessible to network administrators, making a vital part of your security policies’ continuous improvement and adaptation as new apps and threats emerge.
This architecture lends itself to endless customization and tweaking – which is a vital part of maintaining your WAF’s long-term success.
Make the Most of Custom Rulesets
While the pre-configured rulesets make full use of your provider’s industry intelligence, they aren’t tailored toward any single industry or client. This is where your own security resources should be focused. Initial custom configuration should focus on specific applications and business logic that your organization relies on.
To investigate how rules are created and executed, let’s break down the process into its three core components: inspection, rule criteria, and action. Inspection components are the individual pieces of data that make up a web request. Headers include information on the host and request itself; HTTP methods and URIs identify precisely which protocol and resource the request is asking for; and post data contains any data that’s being sent via POST. Modern WAFs can also take cookies into account when a user is accessing the network via web browser.
With data sources established, it’s possible to put rules in place that determine how the data is used. The specific types of rule can again take multiple forms, but the focus of each remains the same: to identify and prevent patterns of unusual activity. Whether it’s the number of requests per second, or the presence or absence of different headers – all of this data can be correlated into rules that control the ways each application handles individual requests. Advanced WAFs take individual data points into consideration to create an anomaly score for a request – if the score goes beyond a threshold, it is then considered malicious.
Finally, it’s important to define the action a rule needs to take when it’s triggered by a set of actions: these can be allow, block, count, or log. “Allow” and “block” are self-explanatory: “count” can be useful for tallying the number of matches over a timespan, and therefore useful for testing, while “log” makes a record of the request.
Tune Those Rules
An enterprise’s traffic changes over time: your WAF’s ruleset needs to adapt. Alongside keeping an eye on how often your provider updates the pre-configured rule lists, it’s important that your custom rules change as well.
The first step to rule tuning often starts with removing outdated ones. Keeping rulesets tightly pruned also works wonders for minimizing WAF latency and reducing false positives. In keeping with this goal, it’s also good to consolidate rules with similar packet identifiers.
Choosing the correct risk threshold for your organization is an ongoing process: if your WAF relies on anomaly scores, make sure to communicate and collaborate on the risk profile with technical teams that may be affected by any changes.
Utilize WAF Logs
The purpose of WAF logs is to show every request that’s identified as malicious and blocked. It’s a collection of all evaluated requests that are matched or blocked. These give you a view into the results of every rule, and are perfect for identifying and stopping false positives.
From there, false positives can be prevented by using exclusion lists. A Web Application Firewall (WAF) exclusion list allows specific request attributes to be excluded from WAF evaluation, while the rest of the request is still assessed as usual. One key advantage of exclusion lists is that only the chosen match variable is omitted from inspection for a particular request. For example, you can exclude specific request headers, cookies, query string parameters, or request body arguments based on certain conditions, rather than excluding the entire request. The remaining parts of the request will continue to be evaluated as normal.
Choose Minimal Rule Tuning with CloudGuard WAF
CloudGuard WAF offers a comprehensive solution to safeguard your cloud environment, with Machine Learning-focused protection at its core. Boasting proactive defenses specifically focused on real-world, cutting-edge threats, CloudGuard makes the most of risk scores to prevent even zero-day attacks. CloudGuard aims to secure the entire attack surface with proactive API and endpoint identification. Identifying each API and even deprecated endpoints allows for full visibility and control over the entire attack surface and reducing breach risks.
Simultaneously, WAF as a Service delivers robust, non-agent protection within minutes—requiring only a one-time DNS configuration to securely route traffic to your cloud applications. CloudGuard also strengthens defenses with advanced DDoS and Bot Prevention using CDN delivery: this ensures uninterrupted service, stops automated attacks, and prevents denial-of-service threats before they impact performance or security. See how with a demo – or delve deeper into how CloudGuard delivers API and application security with the 2024 Gigaom radar report.
Feedback