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.

• To protect your web servers, install the FortiWeb appliance or appliances between the web servers and a general purpose firewall such as a FortiGate. FortiWeb complements, and does not replace, general purpose firewalls. FortiWeb appliances are designed specifically to address HTTP/HTTPS threats; general purpose firewalls have more features to protect at lower layers of the network.

Figure 80: Disabling port4 in System > Network > Interface

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.

• Define the IP addresses of other trusted load balancers or web proxies to prevent spoofing of HTTP headers such as X-Forwarded-For: and X-Real-IP: (see “Defining your proxies, clients, & X-headers”).

• As soon as possible during initial FortiWeb setup, give the default administrator, 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.

Figure 81: Edit Password dialog in System > Admin > Administrators

• Instead of allowing administrative access to the FortiWeb appliance from any source, restrict it to trusted internal hosts. (IPv6 entries of ::/0 will be ignored, but you should configure all IPv4 entries.) See “Trusted hosts”. On those computers that you have designated for management, apply strict patch and security policies. Always password-encrypt any FortiWeb configuration backup that you download to those computers to mitigate the information that attackers can gain from any potential compromise. See “Encryption Password”.

Figure 82: New Administrator dialog in System > Admin > Administrators

• Do not use the default administrator access profile for all new administrators. Create one or more access profiles with limited permissions tailored to the responsibilities of the new administrator accounts. See “Configuring access profiles”.

• By default, an administrator login that is idle for more than five minutes times out. You can change this to a longer period in Idle Timeout, but Fortinet does not recommend it. Left unattended, a web UI or CLI session could allow anyone with physical access to your computer to change FortiWeb settings. Small idle timeouts mitigate this risk.

• Administrator passwords should be at least 8 characters long and include both numbers and letters. For additional security, use Enable Strong Passwords to force the use of stronger passwords. See “Global web UI & CLI settings”.

Figure 83: Strengthening passwords and the idle timeout System > Admin > Settings

Figure 84: Restricting accepted administrative protocols in the Edit Interface dialog in System > Network > Interface

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”.

Figure 85: Disabling port4 in System > Network > Interface

• Similar to applying trusted host filters to your FortiWeb administrative accounts, apply URL access control rules to limit potentially malicious access to the administrative accounts of each of your web applications from untrusted networks. See “Restricting access to specific URLs”.

• Authenticate users only over encrypted channels such as HTTPS, and require mutual authentication — the web server or FortiWeb should show its certificate, but the client should also authenticate by showing its certificate. Password-based authentication is less secure than PKI authentication. For certificate-based client authentication, see “How to apply PKI client authentication (personal certificates)”. For certificate-based server/FortiWeb authentication, see “How to offload or inspect HTTPS”.

Figure 86: System > Config > FortiGuard

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.

Table 62: 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.

• Enforce RFC compliance and any limitations specific to your back-end web servers or applications to defeat exploit attempts. See “HTTP/HTTPS protocol constraints” and “Limiting file uploads”.

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”.