Key Concepts : Understanding FortiDDoS protocol anomaly protection
 
Understanding FortiDDoS protocol anomaly protection
This section includes the following topics:
• “TCP/IP anomalies”
• “TCP session state anomalies”
• “HTTP anomalies”
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:
• IP version other than 4 or 6
• Header length less than 5 words
• End of packet (EOP) before 20 bytes of IPV4 Data
• Total length less than 20 bytes
• EOP comes before the length specified by Total length
• End of Header before the data offset (while parsing options)
• Length field in LSRR/SSRR option is other than (3+(n*4)) where n takes value greater than or equal to 1
• Pointer in LSRR/SSRR is other than (n*4) where n takes value greater than or equal to 1
• For IP Options length less than 3
• Source and destination addresses are the same (LAND attack)
• Source or destination address is the same as the localhost (loopback address spoofing)
The FortiDDoS system drops and logs the following Layer 4 anomalies:
• Checksum errors
• Invalid flag combinations, such as SYN/RST
• Other header anomalies, such as incomplete packet
• Urgent flag is set then the urgent pointer must be non-zero
• SYN or FIN or RST is set for fragmented packets
• Data offset is less than 5 for a TCP packet
• End of packet is detected before the 20 bytes of TCP header
• EOP before the data offset indicated data offset
• Length field in Window scale option other than 3 in a TCP packet
• Missing UDP payload
• Missing ICMP payload
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 Mode
Symmetric or Asymmetric
Symmetric
Asymmetric
seq-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 configuration page to enable detection for the following HTTP anomalies:
• unknown-opcode-anomaly—Drops HTTP traffic that uses a method other than one of the following: GET, HEAD, OPTIONS, PUT, POST, CONNECT, DELETE, or TRACE. For example, TEST or PROPFIND.
• invalid-opcode-anomaly—Drops HTTP traffic with an HTTP version other than one of the following: 0.9, 1.0, or 1.1.
• HTTP Range header—Drops sessions when the HTTP request includes the HTTP Range header. The Range header can be abused by attackers to exhaust HTTP server resources.