Thresholds View

SYN

Packet/second rate of SYN packets received. Threshold for a SYN Flood event. When total SYNs to the SPP exceeds the threshold, the SYN flood mitigation mode tests are applied to all new connection requests from IP addresses that are not already in the legitimate IP address table.

Prerequisite: A TCP Profile with following settings should be linked: SYN Flood Mitigation => Enabled

TCP Session Feature Control : SYN Validation => Enabled

New Connections

Connection/second rate of new connections. Threshold for zombie floods (when attackers hijack legitimate IP addresses to launch DDoS attacks). When it detects a zombie flood, FortiDDoS blocks all new connection requests for the configured blocking period. In order to be effective, the new-connections threshold should always be higher than the syn threshold. We recommend that you use the FortiDDoS generated threshold unless you have a specific reason to change it.

Prerequisite: A TCP Profile with following settings should be linked to generate SYN Flood scenario: SYN Flood Mitigation => Enabled

TCP Session Feature Control : SYN Validation => Enabled

SYN Per Source

Packet/second rate of SYN packets from any one source. No single source in an SPP is allowed to exceed this threshold. Threshold for a SYN Flood from Source event. The system applies the blocking period for identified sources. Only SYNs from identified source will be blocked

Most Active Source

Packet/second rate for the most active source. A source that sends packets at a rate that surpasses this threshold is considered a threat. Threshold for a source flood. No single source in an SPP is allowed to exceed this threshold, and the system applies the blocking period for identified sources. All traffic from identified source will be blocked

Concurrent Connections Per Source

Count of TCP connections from a single source. The TCP connection counter is incremented when a connection moves to the established state and decremented when a session is timed out or closes. This threshold is used to identify suspicious source IP behavior. An inordinate number of connections is a symptom of both slow and fast TCP connection attacks. The system applies the blocking period for identified sources for SYN (session initiation). If the aggressive aging high-concurrent-connection-per-source option is enabled, the system also sends a TCP RST to the server to reset the connection.

SYN Per Destination

Packet/second rate for SYN packets to a single destination. When the per-destination limits are exceeded for a particular destination, the SYN flood mitigation mode tests are applied to all new connection requests to that particular destination. Traffic to other destinations is not subject to the tests. The system applies the blocking period for identified sources.

Prerequisite: A TCP Profile with following settings should be linked to generate SYN Flood scenario: SYN Flood Mitigation => Enabled

TCP Session Feature Control : SYN Validation => Enabled

HTTP Method Per Source

Packet/second rate for Method packets (GET, HEAD, OPTION, POST, etc) from a single Source. When the per-source limits are exceeded for a particular source, the system applies the blocking period for identified sources sending HTTP traffic. The connection to the server may also be RST if Protection Profiles > SPP Settings > TCP Tab: Aggressive Aging TCP Connections Feature Control: Layer 7 Flood is enabled.

Most Active Destination

Packet/second rate for the most active destination. A destination that is sent packets at this rate is considered under attack. Threshold for a destination flood.

OTH Fragment

Packet/second rate of fragmented packets received for Protocols Except TCP and UDP. Although the IP specification allows IP fragmentation, excessive fragmented packets can cause some systems to hang or crash.

UDP Fragment

Packet/second rate of UDP fragmented packets received. Although the IP specification allows IP fragmentation, excessive fragmented packets can cause some systems to hang or crash.

TCP Fragment

Packet/second rate of TCP fragmented packets received. Although the IP specification allows IP fragmentation, excessive fragmented packets can cause some systems to hang or crash.

DNS Query UDP

Queries/second. Threshold for a DNS Query Flood event for traffic over UDP.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS Query TCP

Queries/second. Threshold for a DNS Query Flood event for traffic over TCP.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS Question Count UDP

Question count/second. Threshold for a DNS Question Flood over UDP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS MX Count UDP

Question count/second. Threshold for a DNS Question Flood over TCP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS MX Count UDP

Packet/second rate of DNS queries for MX records (QTYPE=15). Threshold for a DNS MX Flood over UDP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS MX Count TCP

Packet/second rate of DNS queries for MX records (QTYPE=15). Threshold for a DNS MX Flood over TCP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS ALLUDP

Packet/second rate of DNS queries for all DNS records (QTYPE=255). Threshold for a DNS ALL Flood over UDP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS ALLTCP

Packet/second rate of DNS queries for all DNS records (QTYPE=255). Threshold for a DNS ALL Flood over TCP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS Zone Transfer TCP

Packet/second rate of DNS zone transfer (AXFR) queries (QTYPE=252). Threshold for a DNS Zone Transfer Flood event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS Fragment UDP

Packet/second rate of fragmented packets received. Threshold for a DNS Fragment Flood over UDP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS Fragment TCP

Packet/second rate of fragmented packets received. Threshold for a DNS Fragment Flood over TCP event.

Prerequisite: A DNS Profile should be linked to SPP rule

DNS Query Per Source

Packet/second rate of normal DNS queries from any one source. No single source in an SPP is allowed to exceed this threshold. Threshold for a DNS Query Per Source flood event. The system applies the blocking period for identified sources.

Prerequisite: A DNS Profile should be linked to SPP rule with DNS Source blocking feature set to Enable

DNS Packet Track Per Source

Packet/second rate of a source that demonstrates suspicious activity, a score based on heuristics that

• count fragmented packets
• response not found in DQRM
• queries that generate responses with RCODE other than 0.

Threshold for a DNS Suspicious Sources flood event. The system applies the blocking period for identified sources.

Prerequisite: A DNS Profile should be linked to SPP rule with DNS Source blocking feature set to Enable

NTP Request

Rate Limit of NTP Requests to or from the SPP

NTP Response

Rate Limit of NTP Responses to or from the SPP.

Usage: This Threshold can be set for any environment but if FortiDDoS sees both Requests and Responses (symmetric traffic or both asymmetric links pass through FortiDDoS) the Unsolicited Response Anomaly feature above will respond to NTP Response Floods faster than this Thresholds. These is no harm in using both. If FortiDDoS is in Asymmetric Mode, use this Threshold and DISABLE the NTP Unsolicited Response Anomaly.

Note: NTP Response attacks are common. Always set a Response Threshold or use NTP Unsolicited Response (NRM) Anomaly.

NTP Broadcast

Rate Limit of NTP Broadcast packets to or from the SPP.

Usage:.You should never see NTP Broadcast packets on public networks. If, during Learning/Detection Mode, you see these in either direction, examine the protected IPs involved to see if they are originating, terminating or spoofed. Unless you know you are broadcasting for some reason, this Thresholds can be set to zero.

NTP Response Per Destination

Rate Limit of NTP Responses per individual Destination.

Usage: This Threshold can be set for any environment. This threshold will normally be less than or equal to the “Response Threshold” above. If FortiDDoS sees both Requests and Responses (symmetric traffic or both asymmetric links pass through FortiDDoS) the Unsolicited Response Anomaly feature above will respond to NTP Response per Destination Floods faster than this Thresholds. These is no harm in using both.

If FortiDDoS is in Asymmetric Mode, use this Threshold and DISABLE the NTP Unsolicited Response anomaly.

DTLS Client Hello Per Source

Rate limit of DTLS Client Hello messages sent per Source.

DTLS Server Hello Per Source

Rate limit of DTLS Server Hello messages sent per Source.

DTLS Server Hello Per Destination

Rate limit of DTLS Server Hello messages sent per Destination.

SYN/ACK in Asym Mode

Rate limit of inbound SYN/ACKs when in Asymmetric Mode

Note: This Threshold must be set manually. Please observe Traffic Monitor > Layer 3/4/7 > Layer 4 > SYN: SYN-ACK graph to determine peak traffic rate and multiple 2x for Threshold.

SYN/ACK per Destination in Asym Mode

Rate limit of inbound SYN/ACKs per Destination when in Asymmetric Mode

Note: This Threshold must be set manually. Please observe Traffic Monitor > Layer 3/4/7 > Layer 4 > SYN: SYN-ACK per Destination graph to determine peak traffic rate and multiple 2x for Threshold.

DNSSEC Response UDP Asym

Asymmetric Mode SPP aggregate rate limit Threshold for inbound DNSSEC UDP Response packets (from UDP port 53 with Resource Record 41 (Option) fields.

In Asymmetric Mode, DQRM and DNSSEC Message Type Match or DNSSEC Require Response After Query cannot be used and this Threshold offers protection.

When using this Threshold, Enable Service Protection > DNS Profile (used with the applicable SPP) > DNS Message IP Fragment Try Best. This feature parses fragmented Response packet to determine if they are DNSSEC.

This is a manual Threshold and must be set by the user. In Asymmetric Mode, go to Monitor: TRAFFIC MONITOR > Layer 3/4/7 > Select SPP > Layer 7 and scroll to DNSSEC graph. This graph will only appear if system is in Asymmetric Mode.

Observe the PEAK traffic of the UDP Asymmetric Response Ingress Max Packet Rate/Sec over a reasonable period of time (1-Week to 1-Month).

Multiply the PEAK rate by 2 and use this rate as the Inbound Threshold for this Scalar. No Outbound Threshold is available.

DNSSEC Response UDP Asym Source

Asymmetric Mode per Source IP rate limit Threshold for inbound DNSSEC UDP Response per Source packets (from UDP port 53 with Resource Record 41 (Option) fields.

In Asymmetric Mode, DQRM and DNSSEC Message Type Match or DNSSEC Require Response After Query cannot be used and this Threshold offers protection.

When using this Threshold, enable Service Protection > DNS Profile (used with the applicable SPP) > DNS Message IP Fragment Try Best. This feature parses fragmented Response packet to determine if they are DNSSEC.

This is a manual Threshold and must be set by the user. In Asymmetric Mode, go to Monitor: TRAFFIC MONITOR > Layer 3/4/7 > Select SPP > Layer 7 and scroll to DNSSEC graph. This graph will only appear if system is in Asymmetric Mode.

Observe the PEAK traffic of the UDP Asymmetric Response per Source Ingress Max Packet Rate/Sec over a reasonable period of time (1-Week to 1-Month).

Multiply the PEAK rate by 2 and use this rate as the Inbound Threshold for this Scalar. No Outbound Threshold is available.

DNSSEC Response UDP Asym Destination

Asymmetric Mode per Source IP rate limit Threshold for inbound DNSSEC UDP Response per Destination packets (from UDP port 53 with Resource Record 41 (Option) fields.

In Asymmetric Mode, DQRM and DNSSEC Message Type Match or DNSSEC Require Response After Query cannot be used and this Threshold offers protection.

When using this Threshold, enable Service Protection > DNS Profile (used with the applicable SPP) > DNS Message IP Fragment Try Best. This feature parses fragmented Response packet to determine if they are DNSSEC.

This is a manual Threshold and must be set by the user. In Asymmetric Mode, go to Monitor: TRAFFIC MONITOR > Layer 3/4/7 > Select SPP > Layer 7 and scroll to DNSSEC graph. This graph will only appear if system is in Asymmetric Mode.

Observe the PEAK traffic of the UDP Asymmetric Response per Destination Ingress Max Packet Rate/Sec over a reasonable period of time (1-Week to 1-Month).

Multiply the PEAK rate by 2 and enter this rate as the Inbound Threshold for this Scalar. No Outbound Threshold is available.

HTTP/1.1 uses the following set of common methods:

• GET
• HEAD
• OPTIONS
• TRACE
• POST
• PUT
• DELETE
• CONNECT

Packet/second rate for the specified HTTP method. Threshold for an HTTP method flood attack. When the maximum rate is reached, the system drops packets matching the parameter. If the aggressive aging layer7-flood option is enabled, the system also sends a TCP RST to the server to reset the connection.

Protocol Start / End

Packet/second rate for the specified protocol (0-255). Threshold for a Protocol Flood event.

When you specify a threshold for protocols, enter a range, even if you are specifying a threshold for a single protocol. For example, to set a threshold for protocol 6, enter 6 for both Protocol Start and Protocol End.

Port Start / End

Packet/second rate for the specified TCP port (0-65535). Threshold for a Port Flood event. Monitoring the packet rate for ports is helpful to prevent floods against a specific application such as HTML, FTP, SMTP or SQL. TCP accommodates 64K (65,536) ports, most of which may never be used by a particular server. Conversely, a server might see most or all of its traffic on a small group of TCP ports. For this reason, globally assigning a single threshold to all ports generally does not provide useful protection. However, you can globally set a (usually low) TCP Port Threshold for all TCP ports and then manually configure a higher threshold for the ports your protected network is using. When you specify a threshold for ports, you enter a range, even if you are specifying a threshold for a single port. For example, to set a threshold for port 8080, enter 8080 for both Port Start and Port End.

Port Start / End

Packet/second rate for the specified UDP port (0-65535). Threshold for a Port Flood event.

When you specify a threshold for ports, you enter a range, even if you are specifying a threshold for a single port. For example, to set a threshold for port 53, enter 53 for both Port Start and Port End.

ICMP Type/Code Start/End

Packet/second rate for the specified ICMP type/code range (0:0-255:255). The ICMP header includes an 8-bit type field, followed by an 8-bit code field. Threshold for an ICMP Type/Code Flood event.

A popular use for ICMP is the “Echo groping” message (type 8) and its corresponding reply (type 0), which are often useful tools to test connectivity and response time. In some cases, this message and reply can also be used as an attack weapon to effectively disable a target system’s network software. Take care when you set the ICMP type 0 and type 8 thresholds to ensure the desired functionality is preserved.

URL

Packet/second rate for packets with the specified URL match. When the maximum rate is reached, the system drops packets matching the parameter. If the aggressive aging layer7-flood option is enabled, the system also sends a TCP RST to the server to reset the connection.

Specify the URL for a specific website. Botnets make it easy to launch attacks on specific URLs. When such an attack happens, FortiDDoS can isolate the URL and limit just the traffic that is associated with it, while all other traffic is unaffected. The URL is found in the website’s HTTP GET or POST operations. For example, the URL for http://www.website.com/index.html is /index.html.

When you specify a threshold for a URL, the system generates a corresponding hash index value. FortiDDoS displays the hash index value in the list of URL thresholds. Make note of it. You can use the hash value to select this URL elsewhere in the web UI. To view statistics associated with the threshold, go to Monitor > Specific Graphs > URLs, and then for Please enter URL/Hash index, enter either the original URL you specified or the hash index value.

The valid range of hash index values for URLs is 0-64k per SPP.

You can use the special prefix sys_reco_v to create hash index ranges that aggregate URLs that you are interested in only as an aggregate. For example, assume your team wants to pay close attention to a five websites, and all others can be treated essentially the same. With the first five, your configuration is specific, so you know the website URL and the corresponding hash index, and you can use FortiDDoS to track it specifically. The system does not track the others with specificity, but you can track, as an aggregate, whether those sites experience rising and falling rates, including attacks. Create entries for the five priority websites and note their hash index numbers. Let’s assume the hash index numbers are 1, 20, 21, 39, 40.

1. Create ranges to aggregate the gaps:
   1. The first gap is from 2-19, so you create a configuration named sys_reco_v2_19. This includes hash numbers 2 through 19.
   2. The second gap is from 22-38, so you create a configuration named sys_reco_v22_38.
   3. The next gap is from 41 to the end of the range, so you create a configuration named sys_reco_v41_8192.

Note: You cannot carve out a small block out of a large block. If you want to use hash index values that are already in use, you must delete the existing range and then create two ranges.

Host, Referer, Cookie, User-Agent headers

Packet/second rate for packets with the specified header matches. When the maximum rate is reached, the system drops packets matching the parameter. If the aggressive aging layer7-flood option is enabled, the system also sends a TCP RST to the server to reset idle connections. A connection is deemed idle if it has not sent traffic in the last 2 minutes.

Specify HTTP header values. With the advent of botnets, it is easy to launch attacks using scripts. Most of the scripts use the same code. The chances that they all use the same Host, Referer, Cookie, or User-Agent header fields is very high. When such an attack happens, FortiDDoS can easily isolate the four headers among many and limit traffic associated with that specific header, while all other traffic is unaffected.

As with URL hash indexes, you can use the sys_reco_v prefix to define hash index ranges that aggregate header values you are not specifically interested in.

The valid range of hash index values is 0-511 for each setting for each SPP: Host, Referer, Cookie, User-Agent