Understanding FortiDDoS protocol anomaly protection

This section includes the following topics:

IP/UDP/TCP anomalies
TCP session state anomalies
HTTP anomalies
DNS anomalies
NTP Anomalies
SSL/TLS Anomalies

IP/UDP/TCP 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.

This section provides detail for all types of anomalies detected and/or removed. Settings to determine processing of these anomalies are contained within the various SPP Profiles detailed later in the document.

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
Reserved flag set
More fragments
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:

TCP Checksum Error
UDP Checksum Error
ICMP Checksum Error
TCP Invalid Flag Combination
Invalid ICMP Type/Code (Global option)
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
SYN with payload (SPP option)

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.

The table below 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 TCP for additional information on the guidelines for those modes.

TCP session state anomalies detection options

Setting	Detection Mode	Prevention - Symmetric	Prevention - Asymmetric Inbound SYN Direction
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	Recommended
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

HTTP anomalies

You can use the Service Protection > HTTP Profile to enable detection/ prevention for the following HTTP anomalies:

Anomaly	Description
Known Method Anomaly	There are eight known methods: GET, HEAD, OPTIONS, PUT, POST, CONNECT, DELETE, or TRACE. Drop HTTP traffic if the checkbox of the corresponding method is selected. By default, all methods are disabled.
Unknown Method Anomaly	Drops HTTP traffic that uses a method other than GET, HEAD, OPTIONS, PUT, POST, CONNECT, DELETE, or TRACE. For example, TEST or PROPFIND. The dropped packets will be shown in the Monitor Graphs as well as in the Attack Log.
Invalid HTTP Version Anomaly	Drops HTTP traffic with an HTTP version other than 0.9, 1.0, or 1.1. The dropped packets will be shown in the Monitor Graphs as well as in the Attack Log.
Do Not Parse HTTP 0.9	If enabled, do not parse and check HTTP 0.9 traffic. Disabled by default.
Drop Range Header	Drops packet when the HTTP request includes the HTTP Range header. The Range header can be abused by attackers to exhaust HTTP server resources.
Persistent Transaction	A simple HTTP transaction is one where the client makes a single request for HTTP content within a TCP session. Persistent connections allow the browser / HTTP client to utilize the same connection for different object requests to the same host name. If Persistent HTTP Transactions feature is enabled, FortiDDoS checks for application level conformity in every packet of a TCP connection.
Incomplete HTTP Request	Incomplete HTTP Request Detects HTTP packets that do not end with correct end-of-packet characters. This can be a result of attack packets, network fragmentation or large HTTP cookies. Since many web servers use tracking cookies that are getting very large, it is not recommended to enable this function on SPPs containing firewalls, proxies or gateways with outbound sessions. You can enable in Detection Mode on web servers and observe the logs for large and consistent numbers of drops, which would indicate the server is using large cookies. If so, disable before entering Prevention Mode. Block Incomplete HTTP Requests: Block Incomplete HTTP Requests drops HTTP requests that do not end in the correct end-of-packet information. There are three reasons for incomplete packets: Attack traffic MTU or PMTU settings are incorrect resulting in a network-fragmented HTTP packets Large Cookies used by your website to identify clients can exceed standard packet lengths and result in HTTP fragments. Do not enable this option if you use large cookies. Block Sources with Incomplete HTTP Requests: Block Sources of incomplete HTTP packets for all traffic, based on Global Blocking Periods, as well as dropping the incomplete packets. If enabled, the source of incomplete HTTP packets will be blocked based on Service Protection Policy> Blocking Period for Identified Sources (default 60 seconds) and reported as Slow Connection: Source floods. Use this option with care as this may block Firewall, proxy and CDN traffic inbound, most of which is not incomplete HTTP packets.
Aggressive aging feature control	Layer 7 Flood and incomplete HTTP request—Sends a TCP RST to the destination server to reset idle connections when an Incomplete HTTP Request is seen, depending on Incomplete HTTP Request settings.
HTTP Get/Post Mitigation Direction	Enable/disable mitigation when HTTP Get/Post flood is enabled.
HTTP Get flood mitigation	Send redirect packet to client. If the client redirect to the new URL that the source is not spoofed, FortiDDoS allows the connection and adds the source to the legitimate IP address table.
HTTP Post flood mitigation	Send set cookie packet to client. If the client's next request with the set cookie of a source is not spoofed, FortiDDoS allows the connection and adds the source to the legitimate IP address table. This option is recommended if you have enough bandwidth in the reverse direction of the attack.

DNS anomalies

DNS anomalies are packet or session state irregularities known to be exploited by attackers. The table below lists the types of DNS anomalies that can be detected.

Note: DNS Anomalies are disabled by default and should only be enabled with Fortinet assistance.

Many networking devices use encrypted DNS packets but still use UDP 53 as the Query/Response Port. FortiDDoS may see these as anomalous, if these features are enabled and may block legitimate Queries to networking vendors' proprietary web filtering services, for example.

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.

NTP Anomalies

For both intentional and unintended reasons, NTP queries and responses may be improperly crafted. FortiDDoS allows you to block any packet with the following anomalies. Anomalies will be displayed in Attack Logs and Monitor > Anomaly Drops > Layer 7 > NTP graph page.

The following Header Anomalies can be enabled/disabled as required. Turn these Anomalies ON during Learning/Detection Mode and evaluate the Outbound drops showing for these anomalies. If you are seeing large outbound drops for a specific anomaly and the Protected IP looks legitimate, disable the anomaly. Note that while Outbound may be in Detection mode if the system “drops” an Outbound Query because of an Anomaly, it will not put this Query in the NRM table and if an Inbound Response is seen it will be dropped as “unsolicited” (see below) which will affect the ability of your devices to reach NTP servers.

Header Anomaly	Description	Usage
Data Length	Each NTP version has a specified maximum data length in the Query or Response. FortiDDoS will match the actual data length to the defined data length for the identified Version and drop any packet that does match correctly.	Normally, this anomaly can be enabled for all conditions.
Stratum	NTP includes Stratum information to describe the accuracy of the server clock. The RFC supports 0-15 “stratum” but the Stratum field allows 256. Any number above 15 is an anomaly and will be dropped. In addition, if the Stratum is 2 or greater a Reference ID must be included in the request and response. If it is not included, it will be dropped.	Normally, this anomaly can be enabled for all conditions.
Version	NTP Version must be between 1 and 4. If the Version is 1, then the Mode must be 0.	Normally, this anomaly can be enabled for all conditions.
Control Header	FortiDDoS monitors 9 different Control header anomalies Request LEAP INDICATOR as zero Request with ERROR or MORE bits set Request with non-zero OFFSET Request with reserved OPCODE ( >7). Response with COUNT value as 0 Fragmented error response (E=1 and M=1) First response with M=1 with non-zero OFFSET Response with reserved STATUS values( >7)	Normally, this anomaly can be enabled for all conditions. However if you are hosting an NTP server, you many need to disable this option. Enable and monitor during Learning/ Detection and evaluate the number of events and drops in both directions. If unsure contact Fortinet Support.

State Anomaly	Description	Usage
Retransmission Check	If multiple identical Requests are seen before a Response is seen subsequent identical Requests are dropped. Note: This feature will not work where there is asymmetric traffic and FortiDDoS may not see all Responses. Disable this feature if FortiDDoS is in Asymmetric Mode.	Normally used on an NTP server seeing Requests.
Sequence Mismatch	Detects header Sequence number errors in Queries and Responses. Note: This feature will not work where there is asymmetric traffic and FortiDDoS may not see all Responses.	Disable this feature if FortiDDoS is in Asymmetric Mode.
Unsolicited Response Check (NRM)	FortiDDoS records all passing NTP Requests. When a matching NTP Response is seen the record is cleared. If an NTP Response has seen that was not Requested, it is “unsolicited” and dropped immediately. Note: This feature mitigates NTP Reflected Response Floods from the first packet, without the requirement for a Response Threshold. However, this feature will not work where there is asymmetric traffic and FortiDDoS may not see all Requests or Responses. If the system is in Asymmetric Mode, disable this feature and use Response Threshold below.	This feature would normally be used where inside protected clients are trying to reach NTP servers outside (internet-side) of the FortiDDoS. This features also works where you are expecting no NTP traffic in either direction, where, for example, you have an NTP server on your network and do not need to access the Internet for time information.
Mode Mismatch	Some Modes must be different in the Client Query and Server Response while some Modes are the same for both. FortiDDoS monitors valid combinations and if any are invalid, that packet will be dropped. The only valid Mode pairs for Requests/Responses are 1/2, 3/4, 6/6 or 7/7. Note: Mode Mismatch (MM) is like Unsolicited Response, working only with symmetric traffic. If FortiDDoS is in Asymmetric Mode, disable this feature. MM can be used without it.	See Unsolicited Response (NRM) above.
Reflection Deny	No parameters. If you enable Reflection Deny, FortiDDoS will deny NTP Mode 7 and NTP Mode 6 packets in Queries and Responses. These packets are not needed and are frequently abused to create reflected, amplified NTP DDoS attacks.

SSL/TLS Anomalies

You can use the Service Protection > SSL/TLS Profile to enable detection/prevention for the following SSL/TLS anomalies:

Anomaly	Description
Protocol Anomaly (Content Type Anomaly)	Enable/Disable TLS Protocol Anomaly (Content Type) check. Normal Content Types include: changecipherspec (20), alert (21), handshake (22), application_data (23), and heartbeat (24). With Protocol Anomaly enabled, any packet where the Content Type is not 20-24 will be dropped.
Version Anomaly	Enable/Disable TLS Version Anomaly Check. Valid version values are SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 which are from 768 to 771 inclusive. Once version-anomaly option enabled, and the version value in the received message is mismatched these values, FortiDDoS will take the message as version-anomaly, then log and drop it.
Cipher Anomaly	Enable/Disable TLS Cipher Anomaly Check. FortiDDoS will verify if the cipher is normal. If not, it will take the message as the cipher-anomaly message, then log and drop it.
Block Incomplete Request	Enable/Disable Block Incomplete TLS Request Slow-connection. When the actual data length of TLS record is less than its length field value or the data length of handshake protocol is less than its length field value, the request is considered as Incomplete Request which will be dropped and logged.
Aggressive Aging Incomplete Request	Enable/Disable switch for send reset to server for incomplete message to release Server resources. When it’s enabled, as long as Incomplete Request traffic is detected, FortiDDoS will send reset to server for aging TCP connection.
Block Source with Incomplete Request	Enable/Disable source with Block Incomplete TLS Request to block client. When it’s enabled, as long as Incomplete Request traffic is detected, FortiDDoS will block all traffic from the same source address for a block period.
Renegotiation Check	Enable/Disable renegotiation check (Per connection check). Drops the packet if SSL renegotiations exceed Renegotiation Threshold per Renegotiation Aging Time from any Source. Renegotiation Aging Time: The period of checking renegotiation, default value is 1 second. Renegotiation Threshold: Max renegotiation time for client during aging-time, default value is 5 seconds.