• Detection—Logs events and builds traffic statistics for the profile but does not limit or block traffic.
• Prevention—Limits and blocks traffic that exceeds thresholds.

• Detection—Logs events and builds traffic statistics for the profile but does not limit or block traffic.
• Prevention—Limits and blocks traffic that exceeds thresholds.

Enable/disable the feature for one or both traffic directions.

Enable/disable the feature in one or both traffic directions.

A SYN packet with payload is an anomaly that indicates an attack known as a Tsunami SYN Flood. We recommend you enable this feature for inbound traffic. The only reason to disable is if you are running tests with tools that generate SYN packets with payload.

Drops due to this anomaly are logged as L4 Anomaly events and included in the Layer 4 Anomaly graphs.

• ACK cookie—Sends the client two ACK packets: one with a correct ACK number and another with a wrong number. The system determines whether the source is spoofed based on the client’s response. If the client’s response indicates that the source is not spoofed, FortiDDoS allows the connection and adds the source to the legitimate IP address table. Fortinet recommends this option if you have enough bandwidth in the reverse direction of the attack.
• SYN cookie—Sends a SYN/ACK with a cookie value in the TCP sequence field. If it receives an ACK back with the right cookie, an RST/ACK packet is sent and the IP address is added to the legitimate IP address table. If the client then retries, it succeeds in making a TCP connection. Fortinet recommends this option if you cannot use ACK Cookie and you anticipate high volume attacks. Fortinet recommends this option if you cannot use ACK Cookie and you anticipate high volume attacks.
• SYN retransmission—Drops the initial SYNs to force the client to send a SYN again. If the expected number of retransmitted SYNs arrive within the predetermined time period, the system considers the source to be legitimate. FortiDDoS then allows the connection to go through and adds the source to the legitimate IP address table. Fortinet recommends this option if you cannot use ACK Cookie and you anticipate low volume attacks.

• Fixed—Does not use the adaptive limit. The configured minimum thresholds are the maximum limits.
• Adaptive—Uses the adaptive limit. The configured minimum thresholds multiplied by the adaptive limit are the maximum limits.

Select one or more of the following options to detect TCP state anomalies:

• Sequence validation—The FortiDDoS TCP state machine ensures that TCP sequence numbers for the packets within a session are valid.
• SYN validation—Required to support SYN Flood Mitigation.
  
  If SYN Validation is not enabled, packets are not dropped during a SYN flood.
  
  If SYN Validation is enabled, during a SYN flood, the TCP state machine allows only TCP SYNs from IP addresses in the legitimate IP address (LIP) table (sources that have done a three-way handshake in the recent past). SYNs from source IP addresses that do not have an entry in the LIP table must pass a SYN Flood Mitigation challenge to be added to the LIP table.
• State transition anomalies validation—The TCP state machine ensures that TCP state transitions follow the rules. For example, if an ACK packet is received when FortiDDoS has not observed a SYN/ACK packet, it is a state transition anomaly.
• Foreign packet validation—The TCP state machine drops TCP packets without an existing TCP connection and reports them as a foreign packet. In most cases, the foreign packet validation is useful for filtering out junk, but enabling it is not important. The number of foreign packets can be high, so the system does not store the source and destination of each packet. Therefore, you might not be able to determine the origin of a foreign packet. Foreign packet drops are logged in the DDoS Attack Log (State Anomalies event).

Important: See TCP session state anomalies for recommended settings for Detection Mode, Prevention Mode, and Asymmetric Mode.

The configuration also enables you to allow some TCP state sequences that the system would otherwise detect as a TCP state anomaly when the anomaly detection options are enabled.

Select the following options to enable them:

• Allow tuple reuse—Allow this exception to Sequence validation (if enabled). Otherwise, these are logged as a “State Anomalies: Outside window” event. When the “allow” option is enabled, the FortiDDoS TCP state machine updates the TCP entry when a tuple is reused. This update occurs only during the closed or close-wait, fin-wait, time-wait states, when the connection is just about to retire. Useful in testing environments where test equipment reuses tuples in rapid succession. Enabled by default. Cannot be disabled.
• Allow duplicate SYN-in-SYN-SENT—Allow this exception to Sequence validation (if enabled). Otherwise, these are logged as a “State Anomalies: Outside window” event. When the “allow” option is enabled, the TCP state machine allows duplicate TCP SYN packets during the SYN-SENT state. It allows this type of packet even if the sequence numbers are different. Disabled by default. We suggest you enable this in Detection Mode.
• Allow duplicate SYN-in-SYN-RECV—Allow this exception to Sequence validation (if enabled). Otherwise, these are logged as a “State Anomalies: Outside window” event. When the “allow” option is enabled, the TCP state machine allows duplicate TCP SYN packets during the SYN-RECV state. It allows this type of packet even if the sequence numbers are different. Disabled by default. Normally these violations are not expected in real-world traffic but might be seen in test environments.
• Allow SYN anomaly, Allow SYN-ACK anomaly, Allow ACK anomaly, Allow RST anomaly, Allow FIN anomaly—Allow these exceptions to State transition anomalies (if enabled). Otherwise, these are logged as a “State Anomalies: State transition error” event. When the “allow” options are enabled, the TCP state machine allows duplicate TCP packets during any other state even if the sequence numbers are different from the existing connection entry. This is equivalent to allowing the packet without updating an existing connection entry with the new information from the allowed packet. Disabled by default. Normally these violations are not expected in real-world traffic but might be seen in test environments. In most cases, these options should remain disabled to enforce TCP compliance.

Select to enable aggressive aging options:

• Layer 7 flood—Sends a TCP RST to the destination server to reset idle connections when a Layer 7 flood is detected.
• High concurrent connections per source—Sends a TCP RST to the destination server to reset idle connections from the identified source when the maximum is reached for the concurrent-connection-per-source threshold.
• Track slow TCP connections—Sends a TCP RST to the destination server to reset idle connections from the identified source when the slow connection attack thresholds set on the Global Settings > Settings page are reached. Slow connection detection events are logged in the DDoS Attack Log (Slow Connection: Agrressive Aging).

• Invalid op-code—Invalid value in the OpCode field.
• SP, DP both 53—Normally, all DNS queries are sent from a high-numbered source port (49152 or above) to destination port 53, and responses are sent from source port 53 to a high-numbered destination port. If the header has port 53 for both, it is probably a crafted packet.
• Illegal flag combination—Invalid combination in the flags field.

• Query bit set—DNS query with the query reply (QR) bit set to 1. In a legitimate query, QR=0.
• RA bit set—DNS query with the recursion allowed (RA) bit set. The RA bit is set in responses, not queries.
• Null query—DNS query in which the question, answer, additional, and name server counts are 0.
• QDCNT not 1 in query—Number of entries in the question section of the DNS packet is normally 1. Otherwise, it might be an exploit attempt.

• QCLASS in reply—DNS response with a resource specifying a CLASS ID reserved for queries only (QCLASS).
• Query bit not set—DNS response with the query reply (QR) bit set to 0. In a legitimate response, QR=1.
• QTYPE in reply—DNS response with a resource specifying a TYPE ID reserved for queries only (QTYPE).
• QDCNT not 1 in response—Number of entries in the question section of the DNS packet is normally 1. Otherwise, it might be an exploit attempt.

• TCP Message too long—TCP query or response message that exceeds the maximum length specified in the message header.
• Label length too large—Query or response with a label that exceeds the maximum length (63) specified in the RFC.
• UDP message too long—UDP query or response message that exceeds the maximum length specified in the message header.
• Name too long—DNS name that exceeds 255 characters. This can cause problems for some DNS servers.

• Pointer loop—DNS message with a pointer that points beyond the end of data (RFC sec4.1.4). This is an exploit attempt.
• Class is not IN—A query/response in which the question/resource address class is not IN (Internet Address). Although allowed by the RFC, this is rare and might indicate an exploit attempt.
• Message ends prematurely—A message that ends prematurely might indicate an exploit attempt.
• Zone transfer—An asynchronous Transfer Full Range (AXFR) request (QTYPE=252) from untrusted networks is likely an exploit attempt.
• Empty UDP message—An empty message might indicate an exploit attempt.
• TCP Buffer underflow—A query/response with less than two bytes of data specified in the two-byte prefix field.

• Type ALL used—Detects a DNS request with request type set to ALL (QTYPE=255).

Enable/disable the DNS query response match (DQRM) table.

Enable/disable the legitimate query (LQ) table.

Enable/disable the time-to-live (TTL) table.

Enable/disable anti-spoofing checks for inbound and outbound UDP DNS traffic.

Specify the antispoofing method if the source IP address is not already in the legitimate IP table (LIP):

• Force TCP (TC=1)—Return a DNS response to the client that has the DNS Truncate bit set and no response record data. A properly implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port 53.
• DNS Query Retransmission—Drop packets and test for valid retransmission. A valid client is expected to retransmit the queries within preset time windows.

Enable/disable DNS caching.

If DNS caching is enabled, one of the following behaviors must be configured:

• Force TCP (TC=1)—Return a DNS response to the client that has the DNS Truncate bit set and no response record data. A properly implemented DNS client will respond to the spoofed response by retrying the original DNS query using TCP port 53.
• Forward to Server—Forward the DNS query to the DNS server.

Enable/disable source IP address blocking periods for violators of any DNS-protection feature (ACL, anomalies, or flood meters). Disabled by default. DNS floods are often spoofed, so we do not recommend blocking an identified source to avoid punishing legitimate clients. Instead, we recommend you rely on the other DNS protection methods. They make packet-by-packet determinations, and are not prone to false positives.

The configuration is open, allowing you to enable source blocking if you want to experiment with it in your network. If enabled, when a threshold is reached, packets are dropped and the identified sources are subject to the Blocking Period for Identified Sources configured on the Global Settings > Settings page.

When disabled, DNS per-source thresholds (dns-query-per-source and dns-packet-track-per-source) are not tracked and the following graohs will not be updated:

• Layer 7 > DNS > Query Per Source > DNS Query Per Source Egress Max Packet Rate/Sec
• Layer 7 > DNS > Suspicious Sources > Packet Track Per Source Egress Max Packet Rate/Sec