Table of Contents
1. Introduction
WafCharm provides the following three types of IP address control features:
- Allowlist: Allows requests from registered IP addresses. Think of it like an employee ID card—if you have one, you’re allowed to enter the office. Similarly, if your IP address is on the Allowlist, your requests are allowed.
- Denylist: Blocks requests from registered IP addresses. This is like a security guard stopping suspicious individuals at the entrance. If an IP address is on the Denylist, its requests are rejected.
- Deny exceptions list: Requests from registered IP addresses will not be blocked by the Denylist. This works like a special visitor pass—if you have one, and you pass the standard entry check, the security guard will not stop you. In WafCharm’s context, the “standard entry check” refers to inspections by other WafCharm rules, excluding the Denylist rules.
For more details on each feature, please refer to the following help pages.
Since both the allowlist and the deny exceptions list serve the role of preventing requests from being blocked by the denylist, their functions may seem somewhat overlapping and a bit confusing at first.
In this blog post, we will take a look at the use cases for the allowlist and the deny exceptions list.
2. Allowlist use cases
As described above, the allowlist is used to register IP addresses that you want to give access to. Since the purpose is to allow specific IP addresses, WafCharm rules are generally not applied to requests from them.
Some typical use cases are as follows.
When tools used by administrators, such as CMS, are also protected by the WAF
In tools like CMS, it is assumed that administrators will freely input data and handle a wide variety of content. Depending on the input values or the type of content, false positives may occur.
Since access to CMS and similar tools is generally limited to administrators, registering their IP addresses in the allowlist helps prevent situations where specific operations might otherwise be blocked.
When conducting security assessments or testing (sending suspicious requests without being affected by the WAF)
When performing assessments or tests, there may be cases where you want to send suspicious requests without being affected by the WAF. One option is to use a route that does not pass through the WAF, but if that is not possible, you can register the IP address used for the assessment or testing in the allowlist so that such requests are always permitted by the WAF.
When using WafCharm, requests from allowlisted IP addresses also bypass inspection by WafCharm rules, which effectively means bypassing the WAF itself.
Emergency response when false positives occur
If a false positive occurs due to the denylist or WafCharm rules, you can register the relevant IP address in the allowlist. This makes it possible to allow access from that source while you investigate the issue or consider preventive measures to avoid future false positives.
3. Deny exception list use cases
As described above, the deny exception list is used to register IP addresses that you do not want to be blocked by the denylist. Since its purpose is to prevent blocking by the denylist, requests from these IP addresses are still subject to inspection by WafCharm rules.
If you register an IP address in the deny exception list, even if the same IP address (for example, x.x.x.2 in the image below) is also registered in the denylist, it will not be blocked by the denylist.
Note: If a request is detected by WafCharm rules, it may still be blocked by those rules.
The specific behavior of the deny exception list and the denylist may vary depending on your platform and rule policies. However, the common behavior is that requests from IP addresses in the deny exception list will not be blocked by the denylist.
On the other hand, if an IP address is not registered in the deny exception list (for example, x.x.x.1 in the image below), requests from that IP address will be blocked by the denylist.
Some typical use cases are as follows.
When conducting security assessments or security testing (and you want to run them through the WAF)
When performing assessments or tests, there is a high chance that suspicious requests will be detected by the denylist. Once detected and the IP address is registered in the denylist, subsequent requests may continue to be blocked for some time, which can disrupt assessment or testing activities. If you want to conduct assessments or tests while still passing through the WAF, we recommend using the deny exception list to bypass only the denylist.
By registering the source IP address in the deny exception list before running the assessment or test, you can avoid being affected by the denylist in advance.
Use in development and verification environments
The deny exception list is also useful in cases where special requests are sent for development or verification purposes and are mistakenly detected by the denylist. By registering the IP addresses of developers or verifiers in advance, you can prevent unexpected blocking.
External services and partner integrations
If you want to prevent false positives from requests sent by health checks or monitoring systems, you can register the IP addresses used by those systems in the deny exception list in advance. This helps avoid unintended detections.
Emergency response when false positives occur
If a false positive occurs due to the denylist, you can use the deny exception list to avoid it. The deny exception list is useful in cases where an IP address cannot be registered in the allowlist, or when you want requests to still be inspected by WafCharm rules while you investigate the issue and consider preventive measures.
4. Conclusion
In this blog post, we took a look at use cases for the allowlist and the deny exception list.
Since there is some overlap in their purposes, you may sometimes find it hard to decide which one to use, since either could seem appropriate. To make the decision easier, keep in mind that the allowlist is a mechanism that ensures requests from registered IP addresses are allowed. In other words, consider whether the source is one that you absolutely want to allow through or that is generally safe to let through.
Also, there is no need to register the same IP address in both the allowlist and the deny exception list at the same time. As long as it is registered in either one, it will not be blocked by the denylist.
