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.
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.
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:
- 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.
- 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.
- Go to Web Protection > Advanced Protection > Custom Policy, and select the Custom Rule tab.
- Click Create New.
- Configure the action and trigger settings for the rule.
- Click Create New to add a rule entry.
- For Filter Type, select HTTP Header, and then click OK.
- 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://126.96.36.199/, use the following expression:
- Click OK to save the rule entry, and then click OK to save the rule.
- Go to Web Protection > Advanced Protection > Custom Policy, and select the Custom Policy tab to group the custom rule into a policy.
- 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.
For detailed information on these settings, see "Combination access control & rate limiting" in FortiWeb Administration Guide.
For details about creating policies, see "Combination access control & rate limiting" in FortiWeb Administration Guide.
Attack log messages contain
Custom Access Violation when this feature detects an unauthorized access attempt.
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.
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.
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.
The modules below support Client ID based period block from 7.0.0:
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
HTTP-connection-flood-check-rule – IP based
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.
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:
4) The max import/include schema level is limited to 256.
Also, you can see the specific error information returned by the GUI.
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.