Understanding FortiDDoS rate limiting thresholds

This section includes the following information:

Granular monitoring and rate limiting
Source tracking table
Destination table
Continuous learning and adaptive thresholds
Hierarchical nature of protocols and implication on thresholds

Granular monitoring and rate limiting

Increasingly, instead of simple bandwidth attacks, attackers try to avoid detection by creating attacks that mimic the behavior of a large number of clients. Evading an NBA system is easy if attackers do coarse-grained rate-based control. Because the content of the malicious requests does not differ from that of legitimate ones, the resulting attacks are hard to defend against using standard techniques.

In contrast, FortiDDoS-F uses a combination of Layer 3, 4, and 7 counters and continuously adapts expected inbound and outbound rates for each of these traffic parameters.

Granular analytics also enable targeted mitigation responses. For example, if a few TCP connections are exceeding bandwidth, the system blocks those connections rather than all connections. If a single destination is under attack, FortiDDoS-F drops packets to that destination while others continue. During fragmented flood attacks, all non-fragmented packets continue as usual. During a port flood to a non-service port, the packets to other ports continue.

Granularity helps to increase the goodput (the throughput of useful data) of the system.

The table below lists the counters that FortiDDoS uses to detect subtle changes in the behavior of network traffic.

FortiDDoS-F counters

Type	200F	1500F	2000F	3000F
Service Protection Policies (SPPs)	8	16	16	16
Protection Subnets per SPP	512	1024	1024	1024
ACLs (system unless noted)
Global ACLs IPv4	1024
Global ACLs IPv6	1024
ACLs per SPP (IPv4 or IPv6)	1024
Blocklist IPv4 upload list	1 million
Blocklist Domains	1024
Domain Blocklist upload list	1 million
FQDN ACL Allowlist/Blocklist File	150000
FQDN ACL	1024
FQDN Regex	1024
DSN Resource Record ACL	256
Layer 3
Protocol flood (Protocol pps rate, per SPP, per direction)	1 counter/Threshold for each of 256 protocols
Fragment flood (Fragment pps rate. Per SPP per direction)	3 counters/Thresholds for TCP/UDP/Other Fragments
IP source flood & source tracking (Source IPs per system)	1 million	4 million	8 million	16 million
IP destination flood (Destination Ips per system)	1 million	4 million	8 million	16 million
Layer 4
TCP port flood (Port data pps Thresholds per SPP per direction)	65,535 (Port 0 is anomaly)
UDP port flood (Port data pps rate Thresholds per SPP per direction)	65,535 (Port 0 is anomaly)
ICMP type/code flood (Type/Code pps rate Thresholds per SPP per direction)	65,536
TCP session table (sessions per system)	4 million	16 million	32 million	64 million
Legitimate IP table ( IP addresses per system) (used to store legitimate Sources during SYN or DNS Query Floods)	1 million	4 million	8 million	16 million
SYN flood (SYN Rate pps per SPP per direction)	5.3 million	20.5 million	40 million	50 million
SYN/source (Sources tracked per system)	1 million	4 million	8 million	16 million
SYN/destination (Destinations tracked per system)	1 million	4 million	8 million	16 million
Concurrent connections/source (Sources tracked per system)	1 million	4 million	8 million	16 million
Layer 7
HTTP method (per Method pps rate per SPP per direction)	8 Method counters/Thresholds(GET, POST, HEAD, PUT, DELETE, CONNECT, OPTIONS, TRACE)
HTTP Method/Source (1 Threshold per SPP per direction) Total Sources tracked per system	1 million	4 million	8 million	16 million
URLs (1 Threshold per SPP per direction) URLs tracked per SPP per direction	Top 64,000
Hosts (1 Threshold per SPP per direction) Hosts tracked per SPP per direction	Top 8000	Top 16 000	Top 16 000	Top 16 000
Referer (1 Threshold per SPP per direction) Referers tracked per SPP per direction	Top 512	Top 16 000	Top 16 000	Top 16 000
Cookie (1 Threshold per SPP per direction) Cookies tracked per SPP per direction	Top 512	Top 16 000	Top 16 000	Top 16 000
User-Agent (1 Threshold per SPP per direction) User-Agents tracked per SPP per direction	Top 512	Top 16 000	Top 16 000	Top 16 000
DQRM (DNS Query/Responses tracked per system)	2 million	8 million	16 million	32 million
DNS LQ (cached Rcode-0 FQDNs per system)	128,000	512,000	1 million	2 million
DNS TTL (Cached TTLs for Rcode-0 FQDNs per system)	2 million	8 million	16 million	32 million
DNS Cache (Cached Rcode-0 Responses per system)	64 000	256 000	512 000	1 million
NRM (NTP Requests/Responses tracked per system)	4 million	8 million	16 million	32 million

Type	VM-04	VM-08	VM-16
Service Protection Policies (SPPs)	4	8	16
Protection Subnets per SPP	512	512	512
ACLs (system unless noted)
Global ACLs IPv4	1024
Global ACLs IPv6	1024
ACLs per SPP (IPv4 or IPv6)	1024
Blocklist IPv4 upload list	1 million
Blocklist Domains	1024
Domain Blocklist upload list	1 milllion
FQDN ACL Allowlist/Blocklist File	150 000
FQDN ACL	1024
FQDN Regex	1024
DSN Resource Record ACL	256
Layer 3
Protocol flood (Protocol pps rate, per SPP, per direction)	1 counter/ Threshold for each of 256 protocols
Fragment flood (Fragment pps rate. Per SPP per direction)	3 counters/ Thresholds for TCP/ UDP/ Other Fragments
IP source flood & source tracking (Source IPs per system)	1 million	1 million	2 million
IP destination flood (Destination Ips per system)	1 million	1 million	2 million
Layer 4
TCP port flood (Port data pps Thresholds per SPP per direction)	65,535 (Port 0 is anomaly). Ports above 1023 are all graphed into port 1024
UDP port flood (Port data pps rate Thresholds per SPP per direction)	65,535 (Port 0 is anomaly). Ports above 10239 are all graphed into port 10240
ICMP type/code flood (Type/Code pps rate Thresholds per SPP per direction)	65,536 Type/Code indexes. Indexes above 10239 are all graphed into index 10240
TCP session table (sessions per system)	4 million	4 million	8 million
Legitimate IP table ( IP addresses per system) (used to store legitimate Sources during SYN or DNS Query Floods)	1 million	1 million	2 million
SYN flood (SYN Rate pps per SPP per direction)z	2 million	2 million	2 million
SYN/source (Sources tracked per system)	1 million	1 million	2 million
SYN/destination (Destinations tracked per system)	1 million	1 million	2 million
Concurrent connections/source (Sources tracked per system)	1 million	1 million	2 million
Layer 7
HTTP method (per Method pps rate per SPP per direction)	8 Method counters/Thresholds(GET, POST, HEAD, PUT, DELETE, CONNECT, OPTIONS, TRACE)
HTTP Method/Source (1 Threshold per SPP per direction) Total Sources tracked per system	1 million	1 million	2 million
URLs (1 Threshold per SPP per direction) URLs tracked per SPP per direction	Top 1024 x
Hosts (1 Threshold per SPP per direction) Hosts tracked per SPP per direction	Top 512	Top 512	Top 512
Referer (1 Threshold per SPP per direction) Referers tracked per SPP per direction	Top 512	Top 512	Top 512
Cookie (1 Threshold per SPP per direction) Cookies tracked per SPP per direction	Top 512	Top 512	Top 512
User-Agent (1 Threshold per SPP per direction) User-Agents tracked per SPP per direction	Top 512	Top 512	Top 512
DQRM (DNS Query/Responses tracked per system)x	2 million	2 million	4 million
DNS LQ (cached Rcode-0 FQDNs per system)	128 000	128 000	256 000
DNS TTL (Cached TTLs for Rcode-0 FQDNs per system)	2 million	2 million	4 million
DNS Cache (Cached Rcode-0 Responses per system)	64 000	64 000	128 000
NRM (NTP Requests/Responses tracked per system)	4 million	4 million	8 million

Source tracking table

FortiDDoS maintains TCP connection tables of 4-16 million entries while maintaining very low latency and high throughput. FortiDDoS does not use its connection tables for non-TCP traffic and thus is immune to ICMP, Fragment and UDP table-filling attacks. SYN packets are validated under flood without populating the connection table (non-proxy).

The source tracking table with 1-16 million entries correlates sources with attack events and applies more stringent blocking to the sources that exceeded maximum rate limits. The source tracking table also enables the special “per-source” thresholds described in the table below.

All per-source thresholds are part of FortiDDoS "Scalar" thresholds and as such, unless noted below, have machine-learned adaptive Thresholds used in conjunction with the system Recommended Thresholds created from the learned traffic. This "Estimated Threshold" compensates for traffic seasonality over short periods of time (from a few minutes to 6 weeks).

All per-Source Threshold attack log events show the Source IP of the “attacker”. In many cases this IP is likely to be the target of the attack since the attacker is trying to get locally protected servers to reflect floods back the “Source IP”.

All per-Source floods are rate-limited to the SPP Threshold without any attempt to validate the Source IP (see below)

Per-source thresholds

Counter	Description
Most Active Source	This Threshold establishes the maximum allowed packet rate for any IP packet from a single source. A rate that exceeds the adjusted baseline is anomalous and treated as a Source Flood attack event. In conjunction with the Source Multiplier, the most-active-source threshold is useful in tracking and blocking any high-rate sources that are participating in an attack. See the figure: System attack response timeline. How is the threshold determined? While learning Traffic Statistics in the background, FortiDDoS records the highest packet rate from a single source every second. It records the peak rate for every 5-minute, 1-hour, 8-hour, 1-day, 1-week, 1-month, and 1-year period for use when setting Thresholds. Note: Most Active Source is an unlikely attack vector since attacks after 2016 generally use randomized source IPs with very low per-Source rates or use single-source floods on specific parameters as below, which will have lower Thresholds than Most Active Source.
SYN-per-Source	This Threshold establishes the maximum allowed packet rate for SYN packets from a single source. A rate that exceeds the adjusted baseline is anomalous and treated as a SYN Flood from Source attack event. Note: Unlike other SYN Floods, FortiDDoS does not attempt to validate the Source IP for SYN-per-Source floods. That is because most SYN-per-Source floods are designed to reflect SYN-ACK floods from the “attacked” servers back to the Source IP which is the real target of the attack. Attempting SYN validation would thus contribute to the attack.
Concurrent-Connections-per-Source	This Threshold establishes the maximum allowed packet rate for concurrent connections from a single source. A count that exceeds the adjusted baseline is anomalous and treated as an Excessive Concurrent Connections Per Source attack event.
DNS Query per Source	This Threshold establishes the maximum allowed rate of DNS queries from a single source. A count that exceeds the adjusted baseline is anomalous and treated as DNS Query Flood From Source attack event. Note: FortiDDoS will not attempt validations of the DNS Query Source IP or content for Query per Source floods since this type of flood is normally designed to reflect DNS Responses from local protected DNS servers back to the target “Source IP”.
DNS Packet Track Per Source	This counter is based on heuristics to detect suspicious actions from sources. The source tracking counter is incremented when a query is not found in the DQRM, when there are fragmented packets in the query or response, and when the response has an RCODE other than 0. Note: FortiDDoS will not attempt validations of the DNS Query Source IP or content for DNS Packet Track per Source floods since this type of flood purely malicious.
Methods per Source	This Threshold establishes the maximum allowed packet rate of all HTTP Methods from a single source. A count that exceeds the adjusted baseline is anomalous and treated as HTTP Methods per Source attack event. Note: FortiDDoS will not attempt validations of the Source IP or content for Methods per Source floods.
DTLS Client Hello per Source	This Threshold establishes the maximum allowed packet rate of DTLS Client Hello packets from a single source. A count that exceeds the adjusted baseline is anomalous and treated as DTLS Client Hello Source attack event. Note 1: These floods are normally attempting to reflect DTLS Server Hello responses from protected local servers. Note 2: This Threshold does not have an automatic Adaptive/Estimated Threshold.
DTLS Server Hello per Source	This Threshold establishes the maximum allowed packet rate of DTLS Server Hello packets from a single source. A count that exceeds the adjusted baseline is anomalous and treated as DTLS Server Hello Source attack event. Note 1: These floods are normally reflection attacks from outside DTLS servers. Note 2: This Threshold does not have an automatic Adaptive/Estimated Threshold.
QUIC Response Initial per Source	This Threshold establishes the maximum allowed packet rate of QUIC Response Initial packets per Source. A count that exceeds the adjusted baseline is anomalous and treated as QUIC Response Initial per Source attack event. Note: These floods are normally reflection attacks from outside QUIC servers.
DNSSEC Response UDP Asym Source	This Threshold establishes the maximum allowed packet rate of DNS, DNSSEC UDP Response packets per Source in Asymmetric Mode. A count that exceeds the adjusted baseline is anomalous and treated as DNSSEC Response UDP Asym Source attack event. Note 1: This Threshold is only available when FortiDDoS has Asymmetric Mode enabled. Note 2: These floods are normally reflection attacks from outside QUIC servers.

Destination table

FortiDDoS destination table supports 1-16 million entries depending on the model.

This table tracks the packet rate for every destination and is used for “per-destination” thresholds.

The destination tracking table enables FortiDDoS to prevent destination flood attacks and slow connection attacks that are targeted at individual destinations. The “per-destination” thresholds enable it to do so without affecting the rates for other destinations in the SPP.

All per-destination thresholds are part of FortiDDoS "Scalar" thresholds and, unless noted below, have machine-learned adaptive Thresholds used in conjunction with the system Recommended Thresholds created from the learned traffic. This "Estimated Threshold" compensates for traffic seasonality over short periods of time (from a few minutes to 6 weeks).

Generally, per-Destination Threshold attack log events will not show Source IP of the “attacker”, since in most cases these will be spoofed.

All per-Destinations floods result in rate-limiting of the monitored traffic parameter to the Destination, but some support Source IP validation as indicated below.

The table below describes the per-destination thresholds.

Per-destination thresholds

Counter	Description
Most Active Destination	This Threshold establishes the maximum allowed packet rate to any one destination. A rate that exceeds the adjusted baseline is anomalous and treated as a Destination Flood attack event. Note: Most Active Destination is seldom used and is not automatically set by System Recommendations. Recommended for ISP deployments only.
SYN per Destination	This Threshold establishes the maximum allowed packet rate for TCP SYN packets to a single destination. A rate that exceeds the adjusted baseline is anomalous and treated as a SYN Per Destination flood attack event. When the SYN per Destination limits are exceeded for a particular destination, the Source IP validation tests are applied to all new SYN connection requests to that destination. Traffic to other destinations is not subject to the tests.
NTP Response per Destination	This Threshold establishes the maximum allowed packet rate for NTP Responses to any single destination. A rate that exceeds the Threshold is treated as an NTP per Destination flood attack event. When the NTP per Destination limits are exceeded for a particular destination, NTP Response Packets are rate-limited to that destination without affecting NTP traffic to any other destination.
DTLS Server Hello per Destination	This Threshold establishes the maximum allowed packet rate of DTLS Server Hello packets to a single destination. A count that exceeds the adjusted baseline is anomalous and treated as DTLS Server Hello per Destination attack event. Note 1: These floods are normally reflections from outside DTLS Servers. Note 2: This Threshold does not have an automatic Adaptive/Estimated Threshold.
SYN-ACK per Destination in Asym Mode	This Threshold establishes the maximum allowed packet rate of SYN-ACK packets to a single destination when FortiDDoS is in Asymmetric Mode. A count that exceeds the adjusted baseline is anomalous and treated as a SYN-ACK per Destination in Asym Mode attack event. Note 1: These floods are normally reflections from outside TCP Servers. Note 2: This Threshold does not have an automatic Adaptive/Estimated Threshold.
DNSSEC Response UDP Asym Destination	This Threshold establishes the maximum allowed packet rate of DNS DNSSEC UDP Response packets to a single destination when FortiDDoS is in Asymmetric Mode. A count that exceeds the adjusted baseline is anomalous and treated as a DNSSEC Response UDP Asym Destination attack event. Note 1: These floods are normally reflections from outside DNS Servers that support DNS, DNSSEC and EDNS0.
DNSSEC Response UDP Asym Destination QUIC Response Initial per Destination	This Threshold establishes the maximum allowed packet rate of QUIC Response Initial packets to a single destination. A count that exceeds the adjusted baseline is anomalous and treated as a QUIC Response Initial per Destination attack event.

Continuous learning and adaptive thresholds

Most NBA systems use fixed value thresholds. Traffic, however, is never static. It shows trends and seasonality (a predictable or expected variation).

FortiDDoS uses adaptive thresholds. Adaptive thresholds take into account the traffic’s average, trend, and seasonality (expected or predictable variations).

Traffic prediction

Unlike other network behavior analysis (NBA) systems, FortiDDoS-F never stops learning. It continuously models inbound and outbound traffic patterns for key Layer 3, Layer 4, and Layer 7 parameters.

FortiDDoS-F uses the following information to model normal and abnormal traffic:

The historical base, or weighted average, of recent traffic (more weight is given to recent traffic)
The trend, or slope, of the traffic
The seasonality of traffic over historical time periods

Trend, slope, and base of traffic

FortiDDoS-F uses these statistics to create a forecast for the next traffic period.

Forecast vs. actual traffic

Traffic is non-deterministic; therefore, the forecast cannot be exact. The extent to which an observed traffic pattern is allowed to exceed its forecast is bounded by thresholds. Generally speaking, a threshold is a baseline rate that the system uses to compare observed traffic rates to determine whether a rate anomaly is occurring.

The FortiDDoS system maintains multiple thresholds for each key Layer 3, Layer 4, and Layer 7 parameter:

Configured minimum threshold
Estimated threshold
Adaptive limit maximum threshold
Adjustments for proxy IP addresses
Packet count multipliers applied to traffic associated with an attack

The figure below illustrates how the system maintains multiple thresholds. The sections that follow explain the significance of each.

Adaptive, minimum and fixed

Configured minimum thresholds

The configured minimum threshold is a baseline of normal counts or rates. The baseline can be generated (based on statistics collected during the learning period) or stipulated (based on defaults or manually configured settings).

The configured minimum threshold is a factor in setting rate limits, but it is not itself the rate limit. Rate limits are set by the estimated threshold, a limit that is subject to heuristic adjustment based on average, trend, and seasonality.

Many of the graphs in the Monitor menu display the configured minimum threshold as a reference.

The table below summarizes the alternative methods for setting the configured minimum threshold.

Minimum threshold configuration settings
Settings	Usage
Thresholds	The thresholds configuration is open. You can set user-defined thresholds and fine-tune them. You can set reasonable values for port and protocol thresholds based on your knowledge of your network’s services and server capacity. It is advised that you have a thorough understanding of FortiDDoS before manually setting values for scalar thresholds.
System Recommendation	The recommended method for setting the configured minimum thresholds. The configured minimum thresholds are a product of the observed rates adjusted by a percentage that you specify.
Emergency Setup	Use if you do not have time to use Detection Mode to establish a baseline.
Factory Defaults	Use to quickly restore the system to high values. The factory defaults are high to avoid possible traffic disruption when you first put the system inline. In general, these settings are used together with Detection Mode when you are setting an initial baseline or a new baseline.
Percent Adjust	Use when you expect a spike in legitimate traffic due to an event that impacts business, like a news announcement or holiday shopping season.

Estimated thresholds

The estimated threshold is a calculated rate limit, based on heuristic adjustments.

The system models an adjusted normal baseline based on average, trend, and seasonality. It uses the heuristics to distinguish attack traffic from increases in traffic volume that is the result of legitimate users accessing protected resources.

The minimum value of an estimated threshold is the configured minimum threshold. In other words, if it is not predicting normal traffic becoming heavier than the baseline, it allows a rate at least as high as the configured minimum threshold.

The maximum value of an estimated threshold is the product of the configured minimum threshold and the adaptive limit. In other words, the system does enforce an absolute maximum rate limit.

Adaptive limit

The adaptive limit is a percentage of the configured minimum threshold.

An adaptive limit of 100% means no dynamic threshold estimation adjustment takes place once the configured minimum threshold is reached (that is, the threshold is a fixed value).

The product of the configured minimum threshold and adaptive limit is the absolute maximum rate limit. If the adaptive limit is 150% (the default), the system can increase the estimated threshold up to 150% of the value of the configured minimum threshold.

There are scenarios where FortiDDoS-F drops legitimate traffic because it cannot adapt quickly enough to a sudden change in traffic patterns. For example, when a news flash or other important announcement increases traffic to a company’s website. In these situations, you can use the Protection Profiles > Thresholds > Percent Adjust configuration page to increase all configured thresholds by a specific percentage.

Adjustments for proxy IP addresses

FortiDDoS can take account of the possibility that a source IP address might be a proxy IP address, and adjust the threshold triggers accordingly. If a source IP address is determined to be a proxy IP address, the system adjusts thresholds for a few key parameters by a factor you specify on the Global Settings > Proxy IP page.

Packet count multipliers applied to traffic associated with an attack

Packet count multipliers are adjustments to counters that are applied to traffic associated with an attack so that the thresholds that control drop and block responses are triggered sooner. You can configure multipliers for the following types of traffic:

Source floods—Traffic from a source that the system has identified as the source of a flood.
Layer 7 floods—Traffic for attacks detected based on a URL or Host, Referer, Cookie, or User-Agent header field.

You can use the Protection Profiles > Settings page to specify packet count multipliers.

When both Source flood and Layer 7 flood conditions are met, the packet count multipliers are compounded. For example, when there is a User Agent flood attack, a source is sending a User-Agent that is overloaded. If the Source multiplier is 4 and the Layer 7 multiplier is 64, the total multiplier that is applied to such traffic is 4 x 64 = 264. In effect, each time the source sends a Layer 7 packet with that particular User-Agent header, FortiDDoS considers each packet the equivalent of 256 packets.

Hierarchical nature of protocols and implication on thresholds

An HTTP packet has Layer 7, Layer 4 (TCP), and Layer 3 (IP) properties. A packet must be within the estimated thresholds of all these counters in order to pass through the FortiDDoS-F gateway. When it sets recommended thresholds, the system takes account of this complexity. If you set thresholds manually, you must also be sure that Layer 7 rates are consistent with Layer 4 and Layer 3 rates.

Protocol hierarchy for determining thresholds

The below illustrates system processing for an HTTP packet.

HTTP packet properties

The following IPv4/IPv6 packet properties are tracked:

Protocol
Fragment or not a fragment
Source IP address (the system can monitor the packet rate from that specific source)

The following TCP packet properties are tracked:

Destination port
SYN or not a SYN packet
TCP connection tuple (the system can monitor the packet rate within that connection)

An HTTP packet has the following properties that can be tracked:

Method (GET, HEAD, POST, PUT, TRACE DELETE, OPTIONS, CONNECT)
Method per Source
URL
Headers

The figure below illustrates system processing for a UDP packet.

UDP packet properties

The following IPv4/IPv6 packet properties are tracked:

Protocol
Fragment or not a fragment
IP option values
Source IP address, and hence packet rate from that specific source

The following UDP packet properties are tracked:

Destination port 1-65, 535 (Port 0 is invalid)
Source port 1-9999, plus 32 user-entered ports

A DNS message has the following additional properties that can be tracked in queries and responses:

24 DNS header, Query, Response and exploit anomalies
Rates for Queries, MX, ALL, ZT, Qcount, Query/Source, Suspicious Sources, DNS Fragments
DNS Response Codes 0-15

To summarize, because determining thresholds is a hierarchical process, avoid setting low thresholds on common conditions that can cause FortiDDoS-F to block legitimate traffic as well as attack traffic. The more specific you are about the type of traffic you want to allow as ‘normal’, the more effective the FortiDDoS-F is in blocking other traffic.