You are here: Fine-tuning & best practices > Hardening security

Hardening security

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.


Disabling port4 in System > Network > Interface

Administrator access

Edit Password dialog in System > Admin > Administrators

New Administrator dialog in System > Admin > Administrators

Strengthening passwords and the idle timeout System > Admin > Settings

Restricting accepted administrative protocols in the Edit Interface dialog in System > Network > Interface
Disabling port4 in System > Network > Interface

User access

Signatures & patches

System > Config > FortiGuard

Buffer hardening

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.

FortiWeb buffer configuration
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.

Enforcing valid, applicable HTTP

Sanitizing HTML application inputs

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.

Disable SSL 3.0

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.