Chapter 1: Key Concepts > TCP/IP anomalies

Understanding FortiDDoS protocol anomaly protection

This section includes the following topics:

TCP/IP anomalies

Legitimate traffic conforms with standards set out in Internet Engineering Task Force (IETF) documents known as Requests for Comments (RFC). Traffic that does not conform with RFCs is anomalous. Often, anomalous traffic contains malicious components. In any case, it should be dropped to prevent resource issues.

The FortiDDoS system drops and logs the following Layer 3 anomalies:

The FortiDDoS system drops and logs the following Layer 4 anomalies:

TCP session state anomalies

TCP session state anomalies are a symptom of an attack or invalid junk traffic, but they can also be seen as a by-product of traffic load tools used in test environments. You can use the Protection Profiles > SPP Settings configuration page to enable detection for TCP session state anomalies and to allow for the anomalies that are sometimes triggered by traffic load tools.

Table 6 summarizes recommended settings for TCP session state for the FortiDDoS deployment modes. In a typical Prevention Mode deployment where FortiDDoS receives both sides of the TCP connection, all settings are available and can be useful. Some settings are not appropriate when FortiDDoS is deployed in Detection Mode or Asymmetric Mode. See Understanding FortiDDoS Detection Mode or Understanding FortiDDoS Asymmetric Mode for additional information on the guidelines for those modes.

 Table 6:   TCP session state anomalies detection options

Setting Detection Mode Prevention -
Symmetric
Prevention - Asymmetric
Sequence validation

Drops packets with invalid TCP sequence numbers.
Do not enable Recommended Do not enable
SYN validation

Drops SYNs during a flood if the source has not completed the TCP three-way handshake.
Do not enable Recommended Recommended
State transition anomalies validation

Drops packets with TCP state transitions that are invalid. For example, if an ACK packet is received when FortiDDoS has not observed a SYN/ACK packet, it is a state transition anomaly.
Do not enable Recommended Do not enable
Foreign packet validation

Drops TCP packets without an existing TCP connection and reports them as a foreign packet. In most cases, the foreign packets validation is useful for filtering out junk.
Do not enable Recommended Recommended
Allow tuple reuse

Allows tuple reuse. Updates the TCP entry during the closed or close-wait, fin-wait, time-wait states, when the connection is just about to retire.
Recommended Recommended Recommended
Allow duplicate SYN-in-SYN-SENT

Allows duplicate TCP SYN packets during the SYN-SENT state. It allows this type of packet even if the sequence numbers are different.
Recommended Useful in some lab environments Useful in some lab environments
Allow duplicate-SYN-in-SYN-RECV

Allows duplicate TCP SYN packets during the SYN-RECV state. It allows this type of packet even if the sequence numbers are different.
Do not enable Useful in some lab environments Do not enable
Allow SYN anomaly, Allow SYN-ACK anomaly, Allow ACK anomaly, Allow RST anomaly, Allow FIN anomaly

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.
Do not enable Seldom necessary but available in case these anomalies are false positives in legitimate traffic. Do not enable

HTTP anomalies

You can use the Global Settings > Settings > General tab to enable detection for the following HTTP anomalies:

DNS anomalies

DNS anomalies are packet or session state irregularities known to be exploited by attackers.

Table 7 lists the types of DNS anomalies that can be detected.

 Table 7:   DNS anomaly detection

Group Anomaly
DNS header anomaly
  • Invalid op-code—Invalid value in the OpCode field.
  • Illegal flag combination—Invalid combination in the flags 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.
DNS query anomaly
  • Query bit set—DNS query with the query reply (QR) bit set to 1. In a legitimate query, QR=0.
  • Null query—DNS query in which the question, answer, additional, and name server counts are 0.
  • RA bit set—DNS query with the recursion allowed (RA) bit set. The RA bit is set in responses, not queries.
  • 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.
DNS response anomaly
  • QCLASS in reply—DNS response with a resource specifying a CLASS ID reserved for queries only (QCLASS).
  • QTYPE in reply—DNS response with a resource specifying a TYPE ID reserved for queries only (QTYPE).
  • Query bit not set—DNS response with the query reply (QR) bit set to 0. In a legitimate response, QR=1.
  • 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.
DNS buffer overflow anomaly
  • TCP Message too long—TCP query or response message that exceeds the maximum length specified in the message header.
  • UDP message too long—UDP 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.
  • Name too long—DNS name that exceeds 255 characters. This can cause problems for some DNS servers.
DNS exploit anomaly
  • Pointer loop—DNS message with a pointer that points beyond the end of data (RFC sec4.1.4). This is an exploit attempt.
  • Zone transfer—An asynchronous Transfer Full Range (AXFR) request (QTYPE=252) from untrusted networks is likely 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.
  • Empty UDP message—An empty message might indicate an exploit attempt.
  • Message ends prematurely—A message that ends prematurely 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.
DNS info anomaly Type ALL used—Detects a DNS request with request type set to ALL (QTYPE=255). Typical user queries to not request ALL.
DNS data anomaly
  • Invalid type, class—A query/response with TYPE or CLASS reserved values.
  • Extraneous data—A query/response with excess data in the packet after valid DNS data.
  • TTL too long—TTL value is greater than 7 days (or 604800 seconds).
  • Name length too short—A query/response with a null DNS name.