FortiWeb is designed to enhance the security of your web sites and web applications, and when fully configured, it can automatically plug holes commonly used by attackers to compromise a system.
This section lists tips to further enhance security.
Disable all network interfaces that should not receive any traffic.
For example, if administrative access is typically through port1, the Internet is connected to port2, and web servers are connected to port3, you would disable (“bring down”) port4. This would prevent an attacker with physical access from connecting a cable to port4 and thereby gaining access if the configuration inadvertently allows it.
X-Forwarded-For: and X-Real-IP: (see Defining your proxies, clients, & X-headers).
admin, a password. This super-administrator account has the highest level of permissions possible, and access to it should be limited to as few people as possible.
Restrict administrative access to a single network interface (usually port1), and allow only the management access protocols needed.
Use only the most secure protocols. Disable PING, except during troubleshooting. Disable HTTP, SNMP, and TELNET unless the network interface only connects to a trusted, private administrative network. See Configuring the network interfaces.
Disable all network interfaces that should not receive any traffic.
For example, if administrative access is typically through port1, the Internet is connected to port2, and web servers are connected to port3, you would disable (“bring down”) port4. This would prevent an attacker with physical access from connecting a cable to port4 and thereby gaining access if the configuration inadvertently allows it.
While analyzing traffic, FortiWeb’s HTTP parser must extract and buffer each part in the request or response. The buffer allows FortiWeb to scan and/or rewrite it before deciding to block or forward the finished traffic. Buffers are not infinite — due to the physical limitations inherent in all RAM, they are allocated a maximum size. If the part of the request or response is too large to fit the buffer, FortiWeb must either pass or block the traffic without further analysis of that part.
Practically speaking, while oversized requests are not common, when they do exist, they may be harmless. Movie uploads are a common example. HTTP GET requests involving many database queries with encrypted values are another example. In these cases, hardening the buffer could result in many false positives during normal use. Such false positives are to be avoided because the flood of information could distract you from real attacks.
In terms of attacks, large DoS attacks from a single attacker are impractical: if the attacking host must consume its own bandwidth or CPU faster than the web server can process it, the attack won’t work. Therefore DoS request traffic is unlikely to be oversized.
Determined attackers, though, often craft oversized requests to mask an exploit. Tactics to pad an attack with harmless data in order to push the payload beyond the scan buffer are popular with more knowledgeable and motivated APT attackers, and with black hat researchers crafting exploit packages for Metasploit and other tools that ultimately land in the hands of script kiddies. Similar to buffer overflow attacks, these padded attacks attempt to bypass and exploit inherent limits. If a request cannot fit into the buffer, it might be a padded attack.
If your web applications do not require oversized requests to work, you can toughen security by blocking oversized requests. Configure HTTP constraints with Malformed Request etc. (see HTTP/HTTPS protocol constraints). Also configure exceptions for URLs that require you to ignore the buffer limitations, such as music or movie uploads.
To determine your appropriate HTTP constraints, first observe your normal traffic. Compare it with FortiWeb’s buffer counts and maximum sizes.
| Buffer | Limit | Block oversized requests using |
|---|---|---|
URL size, excluding appended parameters and the parameter delimiter ( ? ) (e.g. /path/to/app) |
Usually 2 KB | Malformed Request |
| URL parameters’ total size | Buffer | Total URL and Body Parameters Length |
| URL parameter’s individual size | Configurable (see http-cachesize in the FortiWeb CLI Reference) |
Malformed Request |
| Number of parameters | 64 | Malformed Request |
| HTTP header lines’ total size | 4 KB | Header Length |
| HTTP header line’s individual size | Buffer | Header Line Length |
| Number of HTTP header lines | 32 | Number of Header Lines In Request |
| Cookies’ total size | 2 KB | Malformed Request |
| Number of cookies | 32 | Number of Cookies In Request |
| Adobe Flash (AMF) parameters’ total size | Buffer | Total URL Parameters Length |
| Number of Adobe Flash (AMF) parameters | 32 | Malformed Request |
| File uploads’ total size | Buffer | Body Length |
| Number of file uploads | 8 | Malformed Request |
|
Other buffers also exist. Their limitations, however, vary dynamically. |
GET or POST, disable unused HTTP methods to reduce vectors of attack. See Specifying allowed HTTP methods. Most web applications are not written with security in mind, and do not correctly sanitize input. Before a signature or patch is available, you can still block new input-related attacks by rejecting all invalid input that could potentially break the intended behavior of ASP, PHP, JavaScript or other applications. See Validating parameters (“input rules”) and Preventing tampering with hidden inputs.
By default, server policies support the SSL 3.0 protocol. This default behavior is designed to allow older browser versions that do not support TLS to access your web servers.
However, to avoid POODLE other attacks that exploit SSL 3.0 vulnerabilities, disable SSL 3.0 in all server policies.