DoS prevention
You can protect your web assets from a wide variety of denial of service (DoS) attacks.
|
Some DoS protection features are not supported in all modes of operation. For details, see Supported features in each operation mode. |
DoS features are organized by which open system interconnections (OSI) model layer they use primarily to apply the rate limit:
- Application layer (HTTP or HTTPS)
- Network and transport layer (TCP/IP)
Appropriate DoS rate limits vary by the web application you are protecting. For details, see Reducing false positives.
Configuring application-layer DoS protection
The DoS Protection > Application submenu enables you to configure DoS protection at the network application layer.
For some DoS protection features, the FortiWeb appliance uses session management to track requests.
- When a FortiWeb appliance receives the first request from any client, it adds a session cookie to the response from the web server in order to track the session. The client will include the cookie in subsequent requests.
- If a client sends another request before the session timeout, FortiWeb examines the session cookie in the request.
- If the cookie does not exist or its value has changed, the FortiWeb appliance drops the request.
- If the same cookie exists, the request is treated as part of the same session. FortiWeb increments its count of connections and/or requests from the client. If the rate exceeds the limit, FortiWeb drops the extra connection or request.
See also
- Limiting the total HTTP request rate from an IP
- Limiting TCP connections per IP address by session cookie
- Preventing an HTTP request flood
Limiting the total HTTP request rate from an IP
You can limit the number of HTTP requests per second, per source IP address.
This feature is similar to DoS Protection > Application > HTTP Flood Prevention. However, this feature can prevent HTTP request floods that involve many different URLs. It also can detect source IP addresses that are shared by multiple clients, and intelligently enforce a separate request rate limit for those IPs, even if those clients do not support cookies.
FortiWeb appliances track the rate of requests from each source IP address, regardless of their HTTP method. If the rate of requests exceeds the limit, FortiWeb performs the Action.
|
This scan is bypassed if the client’s source IP is a known search engine and you have enabled Allow Known Search Engines. |
To configure an HTTP request rate limit
- Before you configure the rate limit, enable detection of when source IP addresses are shared by multiple clients. For details, see Advanced settings.
- Go to DoS Protection > Application > HTTP Access Limit.
- Click Create New.
- Configure these settings:
Name Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters. HTTP Request Limit/sec (Standalone IP) Type a rate limit for the maximum number of HTTP requests per second from each source IP address that is a single HTTP client.
For example, if loading a web page involves:
- 1 HTML file request
- 1 external JavaScript file request
- 3 image requests
the rate limit should be at least 5, but could be some multiple such as 10 or 15 in order to allow 2 or 3 page loads per second from each client.
For best results, this should be at least as many requests as required to normally load the URL. When a client accesses a web application, it normally requests many files, such as images and style sheets, used by the web page itself. If you set limits too low, it can cause false positive attack detections and block requests. In extreme cases, this could prevent a single web page from fully loading all of its components — images, CSS, and other external files.
The valid range is from 0 to 65,536. The default value is 0. Fortinet suggests an initial value of 500. For details, see Reducing false positives.
HTTP Request Limit/sec (Shared IP) Type a rate limit for the maximum number of HTTP requests per second from each source IP address that is shared by multiple HTTP clients.
Typically, this limit should be greater than HTTP Request Limit/sec (Standalone IP).
For example, let’s say a branch office with 10 employees is accessing your website. Some solitary telecommuters also access your website. Each telecommuter has her own IP address. However, the 10 people at the branch office are behind a firewall with NAT, and from the perspective of the Internet appear to have a single source IP address. If the appropriate rate limit for solitary telecommuters is 20 requests/sec., a fair rate limit for the branch office might be 200 requests/sec.:
20 requests/sec/person x 10 persons = 200 requests/sec.
The valid range is from 0 to 65,536. The default value is 0. Fortinet suggests an initial value of 1000. For details, see Reducing false positives.
Note: If detection of shared IP addresses is disabled, this setting will be ignored and all source IP addresses will be limited by HTTP Request Limit/sec (Standalone IP) instead. For details, see Advanced settings.
Bot Recognition You can select between:
- Real Browser Enforcement—Specifies whether FortiWeb returns a JavaScript to the client to test whether it is a web browser or automated tool when it meets any of the specified conditions. If the client fails the test or does not return results before the Validation Timeout expires, FortiWeb applies the Action. If the client appears to be a web browser, FortiWeb allows the client to exceed the action. See also Bot analysis.
- CAPTCHA Enforcement—Requires the client to successfully fulfill a CAPTCHA request. If the client cannot successfully fulfill the request within the Max Attempt Times or doesn't fulfill the request within the Validation Timeout, FortiWeb applies the Action and sends the CAPTCHA block page. For details, see Customizing error and authentication pages (replacement messages).
Max Attempt Times If CAPTCHA Enforcement is selected for Bot Recognition, enter the maximum number of attempts that a client may attempt to fulfill a CAPTCHA request. The default value is 3. The valid range is 1–5.
Validation Timeout Enter the maximum amount of time that FortiWeb will wait for results from the client for Bot Recognition. Action Select which action the FortiWeb appliance will take when it detects a violation of the rule:
- Alert—Accept the request and generate an alert email and/or log message.
-
Alert & Deny—Block the request (or reset the connection) and generate an alert email and/or log message.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Deny (no log)—Block the request (or reset the connection).
-
Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Tip: For improved performance during a confirmed DDoS, select this option. Attackers participating in the DoS will then be blocked at the IP layer, conserving FortiWeb resources that would otherwise be consumed by scanning each attacker’s request at the HTTP layer, compounding the effects of the DDoS.
Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers.
The default value is Alert.
Caution: This setting will be ignored if Monitor Mode is enabled.
Note: Because the new active appliance does not know previous session history, after an HA failover, for existing sessions, FortiWeb will not be able to enforce actions for this feature. For details, see Sessions & FortiWeb HA.
Note: Logging and/or alert email will occur only if enabled and configured. For details, see Logging and Alert email.
Block Period Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule.
This setting is available only if Action is set to Period Block. The valid range is from 1 to 10,000 (2.78 hours). The default value is 0. For details, see Monitoring currently blocked IPs.
Severity When rule violations are recorded in the attack log, each log message contains a Severity Level (
severity_level) field. Select which severity level the FortiWeb appliance will use when it logs a violation of the rule:- Informative
- Low
- Medium
- High
The default value is Medium.
Trigger Policy Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages. - Click OK.
|
|
If you do not enable detection of shared IP addresses (Shared IP) , FortiWeb ignores the second threshold, HTTP Request Limit/sec (Shared IP). |
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
Group the rule in a DoS protection policy that is used by a protection profile. For details, see Grouping DoS protection rules.
Enable the Session Management option in the protection profile.
Attack log messages contain DoS Attack: HTTP Access Limit Violation when this feature detects a multi-URL HTTP flood. For details, see Log rate limits.
Example: HTTP request rate limit per IP
If you set 10 per second for both the shared and standalone limit, here are two scenarios:
- A client opens 5 TCP connections, where each connection has a different source port. Each TCP connection creates 3 HTTP
GETrequests. The FortiWeb appliance blocks the extra connections as there are 15 HTTP requests overall, which exceeds the limit. - A client opens a single TCP connection with 12 HTTP
GETrequests. The Period Block action is set. Once the count exceeds 10, the FortiWeb appliance blocks all traffic from the client for the specified block period.
Limiting TCP connections per IP address by session cookie
You can limit the number of TCP connections per HTTP session. This can prevent TCP connection floods from clients operating behind a shared IP with innocent clients.
Excessive numbers of TCP connections per session can occur if a web application or client is malfunctioning, or if an attacker is attempting to waste socket resources to produce a DoS.
This feature is similar to DoS Protection > Network > TCP Flood Prevention. However, this feature counts TCP connections per session cookie, while TCP Flood Prevention counts only TCP connections per IP address. Because it uses session cookies at the application layer instead of only TCP/IP connections at the network layer, this feature can differentiate multiple clients that may be behind the same source IP address, such as when the source IP address hides a subnet that uses network address translation (NAT). However, in order to work, the client must support cookies.
If the count exceeds the limit, FortiWeb executes the Action.
|
This scan is bypassed if the client’s source IP is a known search engine and you have enabled Allow Known Search Engines. |
To configure a TCP connection limit per session
- Go to DoS Protection > Application > Malicious IPs.
- Click Create New.
- Configure these settings:
- Alert—Accept the request and generate an alert email and/or log message.
-
Alert & Deny—Block the request (or reset the connection) and generate an alert email and/or log message.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Deny (no log)—Block the request (or reset the connection).
-
Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Tip: For improved performance during a confirmed DDoS, select this option. Attackers participating in the DoS will then be blocked at the IP layer, conserving FortiWeb resources that would otherwise be consumed by scanning each attacker’s request at the HTTP layer, compounding the effects of the DDoS.
Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers.
- Informative
- Low
- Medium
- High
- Click OK.
- Group the rule in a DoS protection policy that is used by a protection profile. For details, see Grouping DoS protection rules.
- Enable the Session Management option in the protection profile.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
| Name | Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters. |
| TCP Connection Number Limit |
Type the maximum number of TCP connections allowed with a single HTTP client. The valid range is from 1 to 1,024. The default is 1. Fortinet suggests an initial value of 100. For details, see Reducing false positives. |
| Action |
Select which action the FortiWeb appliance will take when it detects a violation of the rule: The default value is Alert. Caution: This setting will be ignored if Monitor Mode is enabled. Note: Because the new active appliance does not know previous session history, after an HA failover, for existing sessions, FortiWeb will not be able to enforce actions for this feature. For details, see Sessions & FortiWeb HA. Note: Logging and/or alert email will occur only if enabled and configured. For details, see Logging and Alert email. |
| Block Period |
Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule. This setting is available only if Action is set to Period Block. The valid range is from 1 to 10,000 (2.78 hours). The default value is 0. For details, see Monitoring currently blocked IPs. |
| Severity |
When rule violations are recorded in the attack log, each log message contains a Severity Level ( The default value is Medium. |
| Trigger Policy | Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages. |
Attack log messages contain DoS Attack: Malicious IPs Violation when this feature detects a TCP flood with the same HTTP session cookie. For details, see Log rate limits.
Example: TCP connection per session limit
If you set 10 as the connection limit, here are two scenarios:
- A client opens 5 TCP connections. Each connection has a different source port. Because each connection has a valid session cookie, and does not exceed the connection limit, the FortiWeb appliance allows them.
- A client opens 11 TCP connections. The FortiWeb appliance blocks the last connection because it exceeds the limit of 10.
See also
Preventing an HTTP request flood
You can limit the number of HTTP requests per second, per session, per URL. This effectively prevents HTTP request floods that utilize a single URL.
Because this feature uses session cookies at the application layer instead of only TCP/IP connections at the network layer, this feature can differentiate multiple clients that may be behind the same source IP address, such as when the source IP address hides a subnet that uses network address translation (NAT). However, the client must support cookies.
This feature is similar to DoS Protection > Application > HTTP Access Limit. However, rather than preventing many requests to any URL by the same client, it prevents many requests to the same URL by the same client.
If the rate exceeds the limit, the FortiWeb appliance executes the Action.
|
This scan is bypassed if the client’s source IP is a known search engine and you have enabled Allow Known Search Engines. |
To configure HTTP flood prevention
- Go to DoS Protection > Application > HTTP Flood Prevention.
- Click Create New.
- Configure these settings:
- Real Browser Enforcement—Specifies whether FortiWeb returns a JavaScript to the client to test whether it is a web browser or automated tool when it meets any of the specified conditions. If the client fails the test or does not return results before the Validation Timeout expires, FortiWeb applies the Action. If the client appears to be a web browser, FortiWeb allows the client to exceed the action. For details, see Bot analysis.
- CAPTCHA Enforcement—Requires the client to successfully fulfill a CAPTCHA request. If the client cannot successfully fulfill the request within the Max Attempt Times or doesn't fulfill the request within the Validation Timeout, FortiWeb applies the Action and sends the CAPTCHA block page. For details, see Customizing error and authentication pages (replacement messages).
- Alert—Accept the request and generate an alert email and/or log message.
-
Alert & Deny—Block the request (or reset the connection) and generate an alert email and/or log message.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Deny (no log)—Block the request (or reset the connection).
-
Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Tip: For improved performance during a confirmed DDoS, select this option. Attackers participating in the DoS will then be blocked at the IP layer, conserving FortiWeb resources that would otherwise be consumed by scanning each attacker’s request at the HTTP layer, compounding the effects of the DDoS.
Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers.
- Informative
- Low
- Medium
- High
- Click OK.
- Group the rule in a DoS protection policy. For details, see Grouping DoS protection rules.
- Select the DoS protection policy in a protection profile. For details, see Configuring a protection profile for inline topologies.
- Enable the Session Management option in the protection profile.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
| Name | Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters. |
| HTTP Request Limit/sec |
Type the maximum rate of requests per second allowed from a single HTTP client. The valid range is from 0 to 4,096. The default is 0. Fortinet suggests an initial value of 500. For details, see Reducing false positives. |
| Bot Recognition |
You can select between: |
| Max Attempt Times | If CAPTCHA Enforcement is selected for Bot Recognition, enter the maximum number of attempts that a client may attempt to fulfill a CAPTCHA request. The default value is 3. The valid range is 1–5. |
| Validation Timeout | Enter the maximum amount of time that FortiWeb will wait for results from the client for Bot Recognition. |
| Action |
Select which action the FortiWeb appliance will take when it detects a violation of the rule: The default value is Alert. Caution: This setting will be ignored if Monitor Mode is enabled. Note: Because the new active appliance does not know previous session history, after an HA failover, for existing sessions, FortiWeb will not be able to enforce actions for this feature. For details, see Sessions & FortiWeb HA. Note: Logging and/or alert email will occur only if enabled and configured. For details, see Logging and Alert email. |
| Block Period |
Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule. This setting is available only if Action is set to Period Block. The valid range is from 1 to 10,000 (2.78 hours). The default value is 0. For details, see Monitoring currently blocked IPs. |
| Severity |
When rule violations are recorded in the attack log, each log message contains a Severity Level ( The default value is High. |
| Trigger Policy | Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages. |
Attack log messages contain DoS Attack: HTTP Flood Prevention Violation when this feature detects an HTTP flood.
Example: HTTP request flood prevention
Assuming you set 10 as the limit, here are three scenarios:
- A client opens a single TCP connection with 8 HTTP GET requests. As long as they all have the session cookie set by the FortiWeb appliance, it allows the requests.
- A client opens a single TCP connection with 8 HTTP GET requests. One request does not have the session cookie. The FortiWeb appliance drops the TCP connection (dropping all sessions).
- Two clients open 2 TCP connections. Each has 6 HTTP requests with the same session cookie. The FortiWeb appliance blocks the last two requests because there are 12, which exceeds the 10 limit.
Configuring network-layer DoS protection
You configure DoS protection at the network layer using the DoS Protection > Network submenu and server policies.
Limiting TCP connections per IP address
You can limit the number of fully-formed TCP connections per source IP address. This effectively prevents TCP flood-style denial-of-service (DoS) attacks.
TCP flood attacks exploit the fact that servers must consume memory to maintain the state of the open connection until either the timeout, or the client or server closes the connection. This consumes some memory even if the client is not currently sending any HTTP requests.
Normally, a legitimate client will form a single TCP connection, through which they may make several HTTP requests. As a result, each client consumes a negligible amount of memory to track the state of the TCP connection. However, an attacker will open many connections with perhaps zero or one request each, until the server is exhausted and has no memory left to track the TCP states of new connections with legitimate clients.
This feature is similar to DoS Protection > Application > Malicious IPs. However, this feature counts TCP connections per IP, while Malicious IPs counts TCP connections per session cookie.
It is also similar to the Syn Cookie setting in a server policy. However, this feature counts fully-formed TCP connections, while Syn Cookie counts partially-formed TCP connections.
FortiWeb counts the TCP connections. If a source IP address exceeds the limit, FortiWeb executes the Action for that client.
To configure a TCP connection flood limit
- Go to DoS Protection > Network > TCP Flood Prevention.
- Click Create New.
- Configure these settings:
- Alert—Accept the request and generate an alert email and/or log message.
-
Alert & Deny—Block the request (or reset the connection) and generate an alert email and/or log message.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Deny (no log)—Block the request (or reset the connection).
-
Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period.
You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages).
Tip: For improved performance during a confirmed DDoS, select this option. Attackers participating in the DoS will then be blocked at the IP layer, conserving FortiWeb resources that would otherwise be consumed by scanning each attacker’s request at the HTTP layer, compounding the effects of the DDoS.
- Informative
- Low
- Medium
- High
- Click OK.
- Group the rule in a DoS protection policy that is used by a protection profile. For details, see Grouping DoS protection rules.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
| Name | Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters. |
| TCP Connection Number Limit |
Type the maximum number of TCP connections allowed with a single source IP address. The valid range is from 0 to 65,535. The default is 0. |
| Action |
Select which action the FortiWeb appliance will take when it detects a violation of the rule: The default value is Alert. Caution: This setting will be ignored if Monitor Mode is enabled. Note: Logging and/or alert email will occur only if enabled and configured. For details, see Logging and Alert email. |
| Block Period |
Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule. This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 (1 hour). The default value is 0. For details, see Monitoring currently blocked IPs. |
| Severity |
When rule violations are recorded in the attack log, each log message contains a Severity Level ( The default value is Medium. |
| Trigger Action | Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages. |
Attack log messages contain DoS Attack: TCP Flood Prevention Violation when this feature detects a TCP connection flood. For details, see Log rate limits.
Example: TCP flood prevention
Assume you set 10 as the limit. A client opens 15 TCP connections. Each connection has a different source port. The FortiWeb appliance counts all connections as part of the same source IP and blocks the connections because they exceed the limit.
See also
Preventing a TCP SYN flood
You can configure protection from TCP SYN flood-style denial of service (DoS) attacks.
TCP SYN floods attempt to exploit the state mechanism of TCP. At the point where a client has only sent a SYN signal, a connection has been initiated and therefore consumes server memory to remember the state of the half-open connection. However, because the connection is not yet fully formed, packets are not required to contain any actual application layer payload such as HTTP. Therefore, application-layer scans cannot block the connection. Scans that only count fully-formed socket connections (where the client’s SYN has been replied to by a SYN ACK from the server, and the client has confirmed connection establishment with an ACK) cannot block it either.
Normally, a legitimate client quickly completes the connection build-up and tear-down. However, an attacker initiates many connections without completing them until the server is exhausted and has no memory left to track the TCP connection state for legitimate clients.
To prevent this, FortiWeb can use a “SYN cookie”—a small piece of memory that keeps a timeout for half-open connections. This mechanism prevents half-open connections from accumulating to the point of socket exhaustion.
This feature is similar to DoS Protection > Network > TCP Flood Prevention. However, this feature counts partially-formed TCP connections, while TCP Flood Prevention counts fully-formed TCP connections.
TCP SYN flood protection is available only when the operating mode is Reverse Proxy or True Transparent Proxy. To enable the feature, you configure the Syn Cookie and Half Open Threshold options in the appropriate server policy.
Grouping DoS protection rules
Before you can apply them in a server policy via a protection profile, you must first group DoS prevention rules. (You enable TCP SYN flood protection in the appropriate server policy.)
To configure a DoS protection policy
- Before you can configure a DoS protection policy, you must first configure the rules that you want to include:
- HTTP request flood prevention (see Preventing an HTTP request flood)
- HTTP request rate limit (see Limiting the total HTTP request rate from an IP)
- TCP connections per session (see Limiting TCP connections per IP address by session cookie)
- TCP connection flood prevention (see Limiting TCP connections per IP address)
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see Permissions.
- From HTTP Flood Prevention, select an existing rule that sets the maximum number of HTTP requests per second to a specific URL. For details, see Preventing an HTTP request flood.
- From Malicious IPs, select an existing rule that limits TCP connections from the same client. For details, see Limiting TCP connections per IP address by session cookie.
- From HTTP Access Limit, select a rule, if any, that you want to include. For details, see Limiting the total HTTP request rate from an IP.
- From TCP Flood Prevention, select a rule, if any, that you want to include. For details, see Limiting TCP connections per IP address.