Advanced settings
Several system-wide options that determine how FortiWeb scans traffic and caches server responses are configurable. You can configure the following:
- Source IP detection
- Recursive URL decoding
- Decoding enhancements
- Maximum body cache sizes
- Maximum DLP cache sizes
You can also configure the size of FortiWeb’s scan buffers. For details, see |
To configure Advanced settings
- Go to System > Config > Advanced.
- Configure these settings according to your environment's needs:
Shared IP Enable to analyze the identification (ID) field in IP packet headers in order to distinguish source IP addresses that are actually Internet connections shared by multiple clients, not single clients. For an example, see Example: Setting a separate rate limit for shared Internet connections.
You can configure the ID difference threshold that triggers shared IP detection. For details, see
config system ip-detection
in the FortiWeb CLI Reference:http://docs.fortinet.com/fortiweb/reference
Note: The shared IP address rate limit for some features will be ignored unless you enable this option. For details, see Preventing brute force logins and Limiting the total HTTP request rate from an IP.
Tip: To improve performance and reduce memory consumption, if all source IP addresses should receive the same rate limit regardless of the number of clients sharing each connection, disable this option.
Recursive URL Decoding It is enabled by default to detect URL-embedded attacks that are fuzzified using recursive URL encoding (that is, multiple levels’ worth of URL encoding).
Encoded URLs can be legitimately used for non-English URLs, but can also be used to avoid detection of attacks that use special characters. FortiWeb can decode encoded URLs to scan for these types of attacks. Several encoding types are supported, including IIS-specific Unicode encoding.
For example, you could detect the character
A
that is encoded as either%41
,%x41
,%u0041
, or\t41
.Disable to decode only one level, if the URL is encoded.
Advanced Decoding Enable to decode cookies and parameters using Base64 or CSS for specified URLs.
Enable Advanced Decoding.
Click Apply.
To add a decoding rule, click Create New.
For URL Type, select between:
Simple String—String of text that contains a literal URL.
Regular Expression—String of text that defines a search pattern for a URL that may come in many variations. For details, see Appendix D: Regular expressions .
Enter the URL Path for which you want the decoding rule to apply.
Click OK.
Click Create New.
For Field Type, Select whether you want the decoding rule to apply for parameters or cookies.
For Field Name Type, select between:
Simple String—String of text that contains a literal field name.
Regular Expression—String of text that defines a search pattern for a field name that may come in many variations. For details, see Appendix D: Regular expressions .
Enter the Field Name for the parameter or cookie.
Enable Base64 Decoding and/or CSS Decoding according to your environment's needs.
Click OK.
Maximum Body Cache Size Type the maximum size (in KB) of the body of the HTTP response from the web server that FortiWeb will cache per URL for body compression, rewriting, and XML detection.
Increasing the body cache may decrease performance.
Valid values range from 32 to 4096. The default value is 64.
Maximum DLP Cache Size Type the maximum size in kilobytes (KB) of the body of the HTTP response from the web server that FortiWeb will buffer and scan for data leak protection (DLP).
Responses are cached to improve performance on compression, and rewriting on often-requested URLs.
Valid values vary by Maximum Body Cache Size.
See also
- Defeating cipher padding attacks on individually encrypted inputs
- Limiting the total HTTP request rate from an IP
- Preventing brute force logins
- Example: Setting a separate rate limit for shared Internet connections
- Blocking known attacks & data leaks
- Rewriting & redirecting
- Compression
- Supported cipher suites & protocol versions
Example: Setting a separate rate limit for shared Internet connections
The small ice cream shop Tiny Treats might have only one network-connected smart cash register. Any request from that public IP likely comes, therefore, from that single client (unless they have not secured their WiFi network...). There is a 1:1 ratio of clients to source IP addresses from FortiWeb’s perspective.
Down the street, Giant Gelato, which distributes ice cream to eight provinces, might have a LAN for the entire staff of 250 people, each with one or more computers. Requests that come from the Giants Gelato office’s public IP therefore may actually originate from many possible clients, and therefore normally could be much more frequent. However, like many offices, the LAN uses source IP network address translation (SNAT) at the point that it links to the Internet. As a result, from FortiWeb’s perspective, the private network address of each client is impossible to know: it only knows the single public IP address of Giant Gelato’s router. So there is a single source IP address for Giant Gelato. However, there is a 250:1 ratio of clients to the source IP address.
This is a big proportionate difference. While a low rate limit might seem generous to Tiny Treats, Giant Gelato would be unhappy if you applied the same rate limit to its IP address.
Let’s say that both companies need access to the same ice cream inventory web application: Tiny Treats buys from Giant Gelato. Each view in the application contains the page itself, but also up to 15 images of ice cream, 3 external JavaScripts, and an external CSS style sheet, for a total of 20 HTTP requests in order to produce each view.
40 requests per second then might be more than adequate for Tiny Treats: the clerk could page through the inventory twice every second, if she wanted to.
But for Giant Gelato, its clients would frequently see completely or half-broken views: some images or CSS would be missing, or page requests denied the first or second time, because some other clients on Giant Gelato’s LAN had already consumed the 40 requests allowed to it per second of time. Normal use would be impossible.
To be practical, then, you would not base your rate limiting solely on the source IP address of requests. Instead, you would want dual thresholds:
- A lower threshold for sources that are a single client
- A higher threshold when multiple clients are behind the same source IP address
You could enable Shared IP so that FortiWeb could know to permit more requests per second from Giant Gelato than from Tiny Treats. Because Giant Gelato’s ID fields would not usually be continuous as a single client’s usually would be, FortiWeb could then apply a different, higher limit.