Hardening security

FortiWeb is designed to enhance the security of your websites 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.

Topology

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.
Make sure web traffic cannot bypass the FortiWeb appliance in a complex network environment.
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:. For details, see Defining your proxies, clients, & X-headers.
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.

Disabling port2 in System > Network > Interface

Administrator access

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.
Change all administrator passwords regularly. Set a policy—such as every 60 days—and follow it. You can click the Edit Password icon to reveal the password dialog.
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.) For details, 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 also Encryption Password.
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. For details, 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 Password Policy to force the use of stronger passwords. For details, see Global web UI & CLI settings.

Change Password dialog in System > Admin > Administrators

Create New dialog in System > Admin > Administrators

Strengthening passwords and the idle timeout System > Admin > Settings

Restrict administrative access to a single network interface (usually port1) and allow only the management access protocols needed 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. For details, see Configuring the network interfaces.

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

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.

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. For details, see Restricting access to specific URLs.

User access

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.
Immediately revoke certificates that have been compromised. If possible, automate the distribution of certificate revocation lists. For details, see Revoking certificates.

Signatures & patches

Upgrade to the latest available firmware to take advantage of new security features and stability enhancements. For details, see Updating the firmware.
Use FortiWeb services to take advantage of new definitions for viruses, predefined robots, data types, URL patterns, disreputable clients, and attack signatures.
Update methods can be either:
Manual (see Uploading signature & geography-to-IP updates or Manually initiating update requests)
Automatic (see Scheduling automatic signature updates)

System > Config > FortiGuard

Regularly update FortiWeb FortiGuard Subscription Services.
Schedule updates often.

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. For details, 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 Parameters Length
URL parameter’s individual size	Configurable. See `http-cachesize` in the FortiWeb CLI Reference (http://docs.fortinet.com/fortiweb/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	Total URL Parameters 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

If your web server does not require anything other than GET or POST, disable unused HTTP methods to reduce vectors of attack. For details, see Specifying allowed HTTP methods.
Enforce RFC compliance and any limitations specific to your back-end web servers or applications to defeat exploit attempts. For details, see HTTP/HTTPS protocol constraints and Limiting file uploads.

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. For details, see Validating parameters (“input rules”) and Preventing tampering with hidden inputs.