Balance between recording and blocking in WAF

Informatec Digital » Resources » Balance between recording and blocking in WAF

Find the balance between registering and locking in a WAF It has become one of the most common headaches for security and operations teams. A web application firewall can stop very serious attacks, but if configured too aggressively, it can block legitimate purchases, access, or API calls. If configured too loosely, it ends up being almost purely decorative. The key is to carefully adjust when to log, when to count, when to allow, and when to block.

In this article we will delve into how to achieve this balance using modern WAF capabilities (allow lists, frequency-based rules, learning modes, SIEM integration, machine learning, etc.), supported by concrete examples of AWS WAF, ModSecurity, cloud WAF and on-premise solutionsYou'll see how to limit false positives without lowering the level of protection, how to organize policies by application, and how to use the registry as an ally, not as a constant, unmanageable noise.

What is a WAF and why is registration so important?

A web application firewall acts as a intelligent layer between the user and the serverAnalyzing HTTP/HTTPS traffic in real time. Unlike a traditional network firewall, which only looks at ports and IPs, a WAF goes into detail: URLs, parameters, request bodies, headers, cookies, HTTP methods, etc.

Your mission is detect and stop typical layer 7 attacksSQL injection, XSS, LFI/RFI, access control attacks, API abuse, aggressive scraping, brute force, and even certain application-level DDoS patterns are all protected against these attacks. This is achieved through constantly updated sets of rules, signatures, and security policies.

Logging is the other side of the coin. Every WAF decision—allow, block, or only count—can be accompanied by a detailed event in the logsThese records allow:

• Investigate incidents: reconstruct what happened and how an attempt was made to exploit a vulnerability.
• Adjust rules: detect false positives by seeing which legitimate requests the WAF is blocking.
• Compliance with regulations: demonstrate that active controls exist (PCI DSS, GDPR, internal audits, etc.).
• Feeding a SIEM: correlate application attacks with network, system, identity, etc. events.

The problem is that a poorly tuned WAF can fill up the logs with thousands of irrelevant eventsmaking it impossible to find what's important and, on top of that, causing unjustified rejections of legitimate traffic. That's where the art of manipulating registration, counting, and blocking methods comes in.

Security models in WAF: blocklists, allowlists, and a hybrid approach

Most modern WAFs combine several filtering approaches, which has a direct impact on how requests are logged and blockedBroadly speaking, we can talk about two classical philosophies, plus a very common mixed model.

A WAF based on block list It follows a negative security model. Its idea is: “I allow everything except what I know is bad.” It works based on signatures of known attacks (SQL injection, XSS, bot patterns, etc.) and rules that define what is considered suspicious. It is easier to deploy initially, but if you rely solely on this model, you run the risk of new vectors or variants of attacks slip in undetected.

A WAF of allowed list It's the exact opposite: "block everything except what's explicitly permitted." It's based on a positive security model. Only traffic that fits the defined legitimate behavior—routes, methods, parameters, formats, sizes, etc.—is accepted. It's much more secure, but requires significant fine-tuning and can generate false positives at the beginning if it is not prepared properly.

Due to the advantages and disadvantages of each approach, a single model is becoming increasingly common. hybrid of allowlist + blocklistIn this scenario, expected traffic profiles are defined (for example, what constitutes a normal login or payment request), and simultaneously, signatures and heuristics are applied to detect typical malicious patterns. For logging purposes, the hybrid approach allows:

• Mark as high-risk event that which violates the list of permitted items.
• Treat as medium/low priority alerts general blocklist patterns.
• Use the "count" mode to see what would break a rule before activating the block.

WAF in network, on-host, and in the cloud: impact on logging and locking

The WAF deployment model greatly influences how traffic logging and blocking are handled. Logging requests on a network device is not the same as logging them on an agent within the server or on a managed cloud service.

A WAF network-based It is typically deployed as a physical or virtual appliance within the infrastructure, between the internet and applications. This is the classic approach of manufacturers like F5. It has the advantage of offering high performance and granular controlHowever, configuration and management can be complex. Logs are typically sent to syslog or a central SIEM, and it's important to carefully filter what is saved to avoid overloading storage, analysis tools, and diagnostics. IP and DNS network problems.

The WAF host-based It runs on the same servers (or containers) where the application resides, usually as a module or agent (for example, ModSecurity integrated into Nginx or Apache; combining it with Linux hardening with SELinux (improves safety posture). This model allows you to have More application context and very specific rules per service, at the cost of consuming local resources and requiring more distributed log management. They can be stored in local files and then forwarded, or integrated with centralized logging services.

The WAF in the cloud (Cloudflare, Akamai, Imperva Cloud, AWS WAF, etc.) integrates with load balancers, CDNs, or virtual networks. Here, the provider typically offers panels, dashboards and log export to S3, BigQuery, remote syslog, or SIEM. It's usually easier to activate, but you must adapt your logging policies to the provider's model: event types, retention, severity filters, etc.

Choosing one model over another isn't just a technical decision; it also depends on how you want to balance logging and blocking. A cloud-managed service simplifies many aspects, but you might want to... absolute control over where the logs are stored due to compliance or confidentiality policies, which pushes towards on-premise or hybrid models.

Terms, rules and web ACLs: how the WAF decides whether to block, allow or only register

Regardless of the manufacturer, all modern WAFs are based on the idea of conditions, rules and access policiesUnderstanding this is key to playing with count, logging, and locking modes without messing things up in production.

The terms They describe which part of the request is inspected: source IP, specific HTTP headers (Host, User-Agent, Accept, Content-Type…), query parameters, request body, cookies, HTTP method, country of origin, etc. For example, in AWS WAF Classic you can define an IP condition with up to 10.000 addresses or ranges, or a string match condition on a portion of the URL.

The rules They combine one or more conditions and assign an intent: allow, block, or count. When a rule has multiple conditions, they are usually evaluated with a logical ANDAll conditions must be met for the rule to activate. A normal rule without conditions, in practice, doesn't match anything and its action is never triggered.

Many WAFs, including AWS WAF, also have rate-based rulesThese rules count the requests arriving from an IP address (or set of IP addresses that meet certain conditions) during a time window, for example, five minutes. If a threshold is exceeded—say, 1.000 requests in five minutes—the rule takes effect: blocking or simply counting. This is very useful for:

• Control brute force on login forms.
• Limit aggressive scraping or rude bots.
• Mitigating certain types of DDoS attacks at the application level.

The next level is the Web ACL (Access Control List)Here, the rules are grouped, and an evaluation order and a default action (ALLOW or BLOCK) are defined. A request passes through the rules in order; if it matches one, its action is applied, and the evaluation of the rest is stopped. If it doesn't match any, the default action defined in the ACL is applied.

In terms of the balance between logging and locking, the ACL is where you decide if you want the system to default to logging. be permissive (ALLOW and block only by specific rules) or very restrictive (BLOCK except in certain cases). Furthermore, many solutions allow you to set rules in "count" mode within the ACL, so they record matches but don't block traffic, ideal for the tuning phase.

Whitelists and noise reduction in logs

Allowlists are a fundamental tool for reduce false positives and noise in the recordThe idea is simple: in certain contexts, you tell the WAF not to apply a directive or set of rules to certain specific traffic that you have already categorized as trusted or that you know is outside the norm but is legitimate.

For example, in AWS WAF you can create allowlist rules so that, if the request comes from a IP address or specific rangeOr, if it matches a known URL pattern and HTTP method, certain signature inspections are not applied. This helps to:

• Prevent internal APIs that use "weird" patterns generate constant false positives.
• Reduce the latency introduced by deep inspection in traffic you already consider trustworthy.
• Reduce the volume of unnecessary records in the WAF logs.

On platforms like ModSecurity, the recommended approach is not to modify the standard rules (e.g., OWASP Core Rule Set), but to create specific exclusions by rule ID for specific parameters, routes, or users. This allows for maintaining overall protection without creating huge vulnerabilities by disabling entire site-wide rules.

The key is that the allowed lists are surgicalNot a drastic measure. It's much better to exclude a specific combination (rule X + parameter Y in URL Z) than to disable rule X globally. That way, the logging remains useful and you don't create unnecessary blind spots.

Protocol rules and limits: when to block, when to warn

Many WAFs incorporate a set of HTTP protocol sanitization rules that function as first malformed or suspicious traffic filterThese rules review mandatory headers, methods, argument sizes, etc., and are a frequent source of both good protection and false positives if not well understood.

Some very common examples:

• Missing Accept Header (Missing Accept header): This isn't strictly an RFC violation, but many requests without this header come from automated tools or poorly written scripts. It can affect custom APIs or clients that don't send it. In many environments, logging and counting is preferred over outright blocking.
• Missing Host HeaderAccording to HTTP/1.1 standards, the Host header is mandatory. WAFs also need it to determine which policy to apply. Blocking here is usually reasonable, but it can generate false positives during testing or due to misconfigured internal traffic; it's advisable to monitor the logs before enabling strict blocking.
• Missing User-Agent HeaderThis rule attempts to curb rudimentary bots and unidentified traffic. The problem is that many legitimate APIs may not send a User-Agent. The most sensible approach is usually to log and, if a consistent and legitimate API is detected, add their IP or pattern to an allow list.
• GET/HEAD validation with bodyAlthough the RFC doesn't strictly prohibit sending the body with GET or HEAD requests, it's not common practice and may indicate evasion attempts. In many cases, a first step is to log all these requests and, if they are found to be suspicious anomalies, proceed to block them.
• Missing Content-Type with bodyIf there is a body but no Content-Type, it's a clear indication of improper protocol usage or an attempt to evade analysis. In these cases, a more aggressive blocking approach usually makes sense, especially in internet-facing environments.

In addition to these protocol rules, it is common to find limits of arguments To protect against application-level floods and DoS attacks. For example:

• Maximum number of arguments per request (by default, 255 in some WAFs).
• Maximum length of an individual argument (for example, 400 characters).
• Total combined size of all arguments (for example, 64.000 bytes).

These values ​​are reasonable for many applications, but there are cases—complex form uploads, advanced filters, large JSON loads—where false positives occur. In those scenarios, the most prudent approach is start by recording and countingReview which endpoints are breaking the limits and adjust only for those routes, instead of lifting all limits for the entire site.

False positives: how to detect them and not die trying

A false positive is a legitimate request that the WAF identifies as malicious and blocks or marks as an attack. They are unavoidable, especially when you activate broad rule sets like OWASP CRS, but they can be professionally managed so they don't become a daily headache.

The detection of false positives begins with a careful observation of the logsReview which requests are being blocked, which rule triggers them, and in what context (URL, parameters, user, origin, etc.). Visual tools and dashboards help identify spikes in 403 errors or unusual patterns.

A highly recommended approach, both by cloud providers and the ModSecurity community, is to use a simulation mode or count modeIn this mode, the rules you want to test log each match, but don't block. This allows you to see, for example, how many legitimate requests a new SQLi rule would have blocked before you dared to activate it in production.

It's also a good idea to test the rules in a staging or pre-production environment that receives real or simulated traffic. Tools like OWASP ZAP or traffic replay scripts can help you simulate legitimate patterns and known attacks to test the WAF's behavior.

Furthermore, it's crucial to consider the operational and reputational impact of false positives: payment interruptions, user registration failures, critical API calls that fail without explanation—all of which can have a direct cost in revenue and brand image. An excess of false positives also overwhelms the security team with alerts that don't add value, making it difficult to identify genuine incidents.

Strategies for adjusting rules and intelligent use of the registry

Managing false positives is not about turning off rules until "everything works", but about fine-tune the WAF with a scalpelThis is where good practices such as the following come into play:

First, avoid disabling rules globally. It's preferable to create very specific exceptionsExclude the rule ID only for a specific route, for certain parameters, or for internal traffic. This way, you remain protected in the rest of the application and maintain useful logs.

Second, take advantage of the counting mode Before blocking, activating new rules initially only in logging mode allows you to measure how many legitimate requests would be affected. You can complement this with SIEM alerts to quickly detect if a rule is generating an abnormal volume of matches.

Third, integrate the WAF with a SIEM or centralized logging platformThis makes it easier to correlate WAF events with other indicators: unusual system activity, mass authentication failures, suspicious configuration changes, etc. It also helps prioritize which rules to adjust first based on the severity and frequency of the events.

Fourth, document each change: which rule has been refined, for which endpoint, under what justification, and with what evidence. For this, consult the server manuals guide This documentation can be useful. It not only helps maintain internal control, but it's also invaluable in audits and security reviews, where you want to demonstrate that... Controls are not disabled lightly.

Automation, machine learning, and adaptive rules in WAF

As applications grow and traffic becomes more complex, managing the WAF manually becomes unrealistic. This is where the Automation, advanced log analysis, and, in some cases, the use of machine learning.

First, integration with SIEM allows building correlation rules and automated responsesFor example, if a set of IPs repeatedly triggers injection or XSS rules, an automated action can be generated to add those IPs to a temporary blocklist or strengthen the inspection level.

Secondly, some WAFs incorporate machine learning modes (learning mode) that observes legitimate traffic over a defined period. Based on this data, it proposes or adjusts thresholds, patterns, and profiles of normal behavior. This helps reduce false positives when rules are switched to blocking mode, and detect subsequent traffic deviations.

In research and laboratory settings, supervised learning techniques have been used to train models to distinguish between legitimate and malicious traffic, refining policies that are then used in production. While not a magic bullet, this approach can help discover subtle patterns that classic signature-based rules do not easily detect.

Finally, the continuous automated testing (Using tools like OWASP ZAP, custom scripts, or CI/CD pipelines) allows you to validate that changes to the WAF don't break critical functionality or leave obvious vulnerabilities. Integrating these tests into the deployment cycle makes security a natural part of the development flow, rather than a last-minute patch.

Policy design per application and blacklists per service

In complex environments—for example, a hosting provider or an ISP—a single, one-size-fits-all WAF policy is not sufficient, especially when there is IT in the shadowsIt is common to have multiple domains or applications behind the same load balancer, each with different security needs and traffic profilesThis is where designing service-specific policies and lists makes sense.

An illustrative case is that of an HTTP/S load balancer acting as reverse proxy for multiple sites (for example, www.company1.com and www.company2.com) behind a single virtual IP. In this scenario, it is possible to configure the WAF so that, as soon as the request arrives, the Host header and the source IP are evaluated even before entering the load balancing module.

The logic would be something like this: the WAF checks if the combination of SERVER_NAME (Host) and client IP It matches a site-specific blacklist. If the IP address is listed as blocked for www.company2.com but not for www.company1.com, a 403 Forbidden response is returned only in the first case. "Clean" traffic is then passed to the load balancing module, which decides which backend serves the request.

This allows you to maintain, for example, blacklists by domainInstead of a global list for the entire access point, each rejection is logged in syslog with details such as the rule ID, the matched condition, the URL, the host, and the client IP address, facilitating subsequent analysis and the expansion or debugging of these lists.

The moral of the story is that the more segmented your policies are (by application, by environment, by user type), the finer you can strike the balance between logging and blocking: you can be very strict on administrative portals and somewhat more flexible on informational websites, for example, always with evidence in the logs of why each decision was made.

Beyond the classic WAF: WAAP and API protection

The threat landscape has not remained static. Today, many applications are cloud-native, use microservices architectures, and expose Public and private APIs which become the primary target of attackers. The traditional WAF has evolved into broader platforms known as WAAP (Web Application and API Protection) or WAAS (Web Application & API Security).

These solutions not only automatically discover web applications, but also identify API endpointsThey accept specifications like OpenAPI or Swagger and use that definition to check the compliance of requests: expected data types, allowed parameters, size limits, etc. Depending on the endpoint (for example, one that handles very sensitive data), a much higher level of scrutiny and blocking can be applied.

At the logging level, WAAP tends to generate events richer in contextThis allows for more precise blocking decisions, rather than relying solely on generic payload patterns. This information can be used to determine the exact API endpoint that was attacked, the specific operation involved (GET, POST, PUT, etc.), the user or token involved, the part of the specification violated, and so on.

Furthermore, many WAAP tools include application- and API-specific DoS protection, geolocation filtering, IP reputation management, bot and scraping detection, and options to customize alert levels per service. Again, it's about having the flexibility to decide. where you want a firm hand and where you want to prioritize fluiditywithout sacrificing a good record base to investigate any incident.

Taken together, a well-tuned WAF—whether classic, WAAP-based, or integrated into a cloud ecosystem—becomes an essential component of modern application and API defense, capable of combining Detailed recording, intelligent locking, and continuous adaptation to the changing threat landscape.