FAQ

Why does my Advanced Protection rule that has both Signature Violation and HTTP Response Code filters not detect any violations?

When you use Web Protection > Advanced Protection > Custom Policy > the Custom Rule tab to create a custom rule, FortiWeb links items in the list of filters with an AND operator. It uses the rule to evaluate both requests and responses. When the rule has both a Signature Violation and a HTTP Response Code filter, a malicious request violates the signature filter and the corresponding response matches the response code filter. But neither the request nor the response can violate both filters at the same time to generate a match.

To solve this problem, create a separate custom rule for each type of filter. For details, see "Combination access control & rate limiting" in FortiWeb Administration Guide.

What's the difference between the Packet Interval Timeout and Transaction Timeout filters in an Advanced Protection rule?

Both Packet Interval Timeout and Transaction Timeout protect against DoS attacks. In most cases, the attacks are some form of slow HTTP attack.

Packet Interval Timeout evaluates the time period between packets that arrive from either the client or server (request or response packets). If the time exceeds the maximum the timeout specifies, FortiWeb takes the action specified in the rule.

However, other types of slow attacks can keep the server occupied and still maintain a minimal data flow. For example, if an attack sends a byte of data per second, it can continue a GET request indefinitely but stay within the Packet Interval Timeout.

The Transaction Timeout evaluates the time period for a transaction—a GET or POST request and its complete reply. In most cases, a transaction lasts no longer than a few milliseconds or, for slower applications, a few seconds.

To detect the widest range of attacks, specify both Packet Interval Timeout and Transaction Timeout filters when you create an Advanced Protection rule.

For details, see "Combination access control & rate limiting" in FortiWeb Administration Guide.

Why is the Signature Violation filter I added to my Advanced Protection custom rule not working?

To add a Signature Violation filter to an Advanced Protection custom rule, you select Signature Violation as the filter type.

However, for the filter to work, the following configuration steps are also required:

• In the Edit Custom Rule dialog box, select at least one signature category. By default, no categories are selected. When you select a category, FortiWeb prompts you to enable all or some of the signatures in the category.

• Ensure that the signatures that correspond to the categories you selected in the rule are enabled in the signature policy (Web Protection > Known Attacks > Signatures).

You select the custom policy that contains the rule and corresponding signature set when you create a protection profile.

For details, see "Combination access control & rate limiting" and "Blocking known attacks & data leaks" in FortiWeb Administration Guide.

How do I prevent cross-site request forgery (CSRF or XSRF) with a custom rule?

A cross-site request forgery attack takes advantage of the trust that a site has in a client’s browser to execute unwanted actions on a web application.

You can add CSRF protection rules or combine it with other methods to protect CSRF/XSRF attacks:

To create a CSRF protection rule to protect against CSRF/XSRF attack. (Recommended)

1. Enable the attribute “Same Site” in Cookie Security. This attribute will declare that your cookie should be restricted to a first-party or same-site context.
2. Check “Referer” in custom rule.

Note: The first method (adding CSRF protection rule) is the most effective. Adding a custom rule with “Referer” header to detect CSRF is very ineffective and can be bypassed easily. However, if needed you can combine two or all of the methods.

To add an advanced access control rule that detects cross-site request forgery (CSRF)

1. Go to Web Protection > Advanced Protection > Custom Policy, and select the Custom Rule tab.
2. Click Create New.
3. Configure the action and trigger settings for the rule.

For detailed information on these settings, see "Combination access control & rate limiting" in FortiWeb Administration Guide.

4. Click Create New to add a rule entry.
5. For Filter Type, select HTTP Header, and then click OK.
6. Configure these settings:
   

   Header Name	Referer
   Header Value Type	Regular Expression
   Header Value	A regular expression that matches the address of your website. For example, if your website is http://211.24.155.103/, use the following expression: ^http://211\.24\.155\.103.*

7. Click OK to save the rule entry, and then click OK to save the rule.
8. Go to Web Protection > Advanced Protection > Custom Policy, and select the Custom Policy tab to group the custom rule into a policy.

For details about creating policies, see "Combination access control & rate limiting" in FortiWeb Administration Guide.

9. To apply the policy, select it as the Custom Policy in a protection profile. For details, see "Configuring a protection profile for inline topologies" or "Configuring a protection profile for an out-of-band topology or asynchronous mode of operation" in FortiWeb Administration Guide.

Attack log messages contain Custom Access Violation when this feature detects an unauthorized access attempt.

Why a URL access rule doesn’t work?

Please check:

1) The URL Pattern value in a URL access rule shouldn’t include the parameter part. That is to say that the value here only matches against the URL string before the question mark.

2) URL access rules may be skipped by previous rule if previous rule has been matched because all of the rules are checked by their sequences.

Does a URL access rule support matching specific HTTP methods or HTTP protocols?

From 7.0.2, you can specify the HTTP methods and HTTP protocols when defining a URL access rule. Only that requests matching the enabled methods or protocols will continue with URL Pattern check.

Why are requests still forwarded to backend servers when the client IP has been already blocked?

Please check:

1) Period block IP only works on new TCP connections. If there are requests on the old TCP connection which was established before the IP be blocked, the request on the old TCP connection will still be forwarded.

2) Customers can choose Client ID based period block for images after 7.0.0. This kind of period block will drop the requests on the old TCP connection.

Why does the reCAPTCHA verification fail even though the custom rule settings are correct and the request is legitimate?

The reCAPTCHA verification fails even though the client is legitimate and required verifications are done within the Validation Timeout period (Bot Confirmation settings in Web Protection > Advanced Protection > Custom Policy > Custom Rule).

This may be caused by a change of reCAPTCHA verification API. FortiWeb sends API calls to a Google reCAPTCHA service URL to complete the reCAPTCHA verification. Google recently changed this URL to https://www.google.com/recaptcha/api/siteverify.

To verify if FortiWeb is configured with this latest URL, run diagnose debug flow filter module-detail recaptcha 7. The output should be as follows:

[reCAPTCHA][DBG](./waf_module/recaptcha.c:678): recaptcha_api_url:https://www.google.com/recaptcha/api/siteverify, recaptcha_api_timeout:10

If the URL is not right, run the following to change it:

config system recaptcha-api

set url https://www.google.com/recaptcha/api/siteverify

end

Please note this URL is subject to change by Google. Please refer to https://developers.google.com/recaptcha/docs/verify#api_request for the latest URL and make sure FortiWeb is configured with the latest URL.

This issue may occur in other WAF modules integrated with reCAPTCHA verification, including:

• HTTP Flood Prevention

• HTTP Access Limit

• Threshold Based Detection

• ML Based Bot Detection

Which modules support Client ID based period block and which modules do not support?

The modules below support Client ID based period block from 7.0.0:

• HTTP-request-flood-prevention-rule

• user-tracking rule

• xml-validation rule

• json-validation rule

• openapi-validation-policy

• csrf-protection

• bot-deception

• input-rule

• custom-protection-rule

• signature

• api-rules

• syntax-based-attack-detection

• HTTP-protocol-parameter-restriction

• webshell-detection-policy

• file-upload-restriction-policy

• threshold-based-detection policy

• custom-access rule

• cookie-security

• site-publish-helper policy

• mobile-api-protection mobile-api-protection-rule

• url-encryption url-encryption-rule

• bot-detection-policy

• known-bots – only bad bot need support

These modules do not support Client ID based period block from 7.0.0:

• padding-oracle - IP-based statistics

• layer4-access-limit-rule - IP-based statistics

• layer4-connection-flood-check-rule – IP-based statistics

• ip-intelligence – IP-based only

• machine-learning-policy

• HTTP-connection-flood-check-rule – IP based

• ftp-file-security

• ftp-command-restriction-rule

Why doesn't MITB work?

Please check:

1) Make sure the request URL matches that rule and the response page is in HTML format with status code 200.

2) Make sure there’s a form tag in the response HTML page and the form’s action URL matches the POST URL in MITB rule.

3) Make sure the type of password input tag is “password” indeed, or FortiWeb’s MITB script can’t locate the password.

4) Make sure the value of the Content Security Policy header doesn’t block the execution of FortiWeb's MITB script.

Why does WSDL import fail?

Below are several common non-bug reasons:

1) When WSDL imports a local schema, the schema should be uploaded to FortiWeb first.

2) When WSDL imports a schema from network, FortiWeb should be able to access the network.

3) If the GUI alerts that the WSDL format is incorrect, you should correct the format before uploading. There is a website for verifying the WSDL format:

https://www.wsdl-analyzer.com/

4) The max import/include schema level is limited to 256.

Also, you can see the specific error information returned by the GUI.

Why doesn't WSDL Validation work?

There are often similar questions caused by incorrect configuration. For WSDL validation, the configurations should be the same between WSDL and the device.

1) The request url of the XML protection rule should be the same as the url of WSDL location.

2) The backend IP/domain of the device should be the same with the IP/domain of WSDL location.

3) The backend port of the device should be the same with the port of WSDL location.

The above three points can confirm the only service on the network.