Table of Contents

1. Introduction
2. Cases Where Customization is Required
3. What You Need to Request Customization
4. Examples of Customization
5. Conclusion

1. Introduction

WafCharm provides WAF rule customization services to customers. We will explain what kind of customization service we provide through the examples of customization we have done so far.

2. Cases Where Customization is Required

There are two main patterns of customization.

1. Customization to avoid unintended blocking (false positive)

2. The customization of additional rule creation corresponds to the following:

• Create rate-based rules
• Create GeoMatch (country-specific restrictions) rules
• Create rules for middleware vulnerabilities (We recommend using newer versions of the middlewares that have not been found to be vulnerable)
• Other customization as needed

3. What You Need to Request for Customization

Customization to avoid unintended blocking (false positive)

WafCharm and WafCharm support cannot judge whether a customer's detection is a false positive or not. We'll need you to provide the relevant rules and logs, and in case of body detection, the body contents as well. After consultation with the customer, our security engineers will provide appropriate customization.

Customization of additional rule creation

If you provide us with the conditions for creating the rules, we will determine whether or not the rules can be applied, and create and apply the rules.

Examples of creation conditions

• ・ block access from outside the country
• ・ rules for CVE-XXXX-XXXXX
• ・ unconditionally allow access to a specific IP and a specific path

4. Examples of Customization

Case 1: Exclusion of specific paths

Path exclusion is the most common customization pattern.
Depending on the site, our rules may detect and block some forms that allow relatively free input of content, such as inquiry functions or file upload functions, even though they are not attacks depending on the content of the request body.

In the case that the IP address cannot be narrowed down, it is possible to narrow down the detection range by excluding the specific path (URI) from the target rule.
Please be aware that security risks do exist.

Basically, the customization is done by adding conditions to the target rules.
For example, if you want to exclude URIs ending with "~/upload" from existing SQL injection, you can create a rule as follows

SQL Injection Rules AND URIs other than "ending with ~/upload

By adding the condition that the URI starts with "/users", it is possible to narrow down the scope of the rule and consequently exclude other URIs.

SQL injection rule AND URI starts with "/users

It is also possible to exclude specific paths in all rules other than the target rule, but we do not recommend it because it is desirable for security to narrow the allowed range as much as possible.

Case 2: Applying rate-based rules with different threshold values for each IP

Rate-based rules are used to block a sender who sends a large number of requests by judging the number of requests per unit time.

How to use Rate Based Rules:
In addition to using the rate-based rule by itself, there have been times when customers have requested that the threshold be tightened for non-specific IPs (user-managed IPs) and loosened for specific IPs (user-managed IPs).

In this case, we created two rate-based rules.

Threshold: 100 accesses /5min AND except for certain IPs (user-managed IPs)
Threshold: 3000 accesses /5min AND specific IPs (user-managed IPs)

The IP list was prepared by the customer.
We also wanted to exclude specific paths for specific IPs (user-managed IPs), so we finally decided to apply the following two rules.

Threshold: 100 access /5min AND other than specific IP (user-managed IP)
Threshold: 3000 access /5min AND specific IP (user-managed IP) AND non-specific path

In this case, it is a specific IP address, but it can also be changed to a country-specific restriction, such as Japan and non-Japan.

Case 3: Rules for CVE-XXXX-XXXXX

After receiving a request for customization for a vulnerability, our security engineers will check if it is possible to create a rule. Depending on the content, it may not be possible to create a rule, or it may be ineffective to create a rule.

Cases where rules cannot be created:

• ・ If the attack is not via network, or if the WAF cannot detect the attack because it cannot be placed in the expected communication path.
• ・ Cases in which WAF cannot detect access using information that has already been leaked, such as IDs and passwords, because the request is normal.
• ・ When there is a risk that false positives will occur with a high probability due to a small difference from normal access.

Cases that do not need to be defined by rules:

• ・ When an attack is embedded using a vulnerability based on a common attack method, or when a detection rule exists for the embedded attack in the first place.

In the above cases, we will make a proposal from the point when customization is ineffective, in consultation with the customer.

5. Conclusion

We have explained the customization of WafCharm with some examples.
If you have any questions, please feel free to contact our support desk.
The time required for customization is on a best-effort basis.