Understanding FortiDDoS DNS attack mitigation

This section includes the following information:

• DNS attack vulnerability overview
• FortiDDoS DNS protection module summary
• FortiDDoS DNS flood mitigation overview
• FortiDDoS DNS flood types
• FortiDDoS DNS deployment topologies
• Getting started with DNS mitigation

DNS attack vulnerability overview

DNS was designed for robustness and reliability, not security. It is vulnerable to multiple types of attacks that can compromise or take down a network. Some of these attacks are described here.

DNS tunneling

DNS tunneling exploits the fact that firewall administrators must open port 53 in order for DNS authoritative name servers to respond to queries from the Internet. The attacker compromises a host in the internal network and runs a DNS tunnel server on it. A DNS tunnel client outside the internal network can then gain access to the internal network by sending a DNS query to the compromised host that sets up a DNS tunnel.

DNS query floods

A DNS flood is an attempt to create a network outage by flooding critical DNS servers with excessive queries.

Some DNS floods target the authoritative name server for a domain. In these types of attacks, malware bots send a continuous flood of queries for random, nonexistent subdomains of a legitimate domain. All of the DNS servers in the recursive chain consume resources processing and responding to the bogus queries.

If clients in your internal network have been compromised by malware, your internal DNS resolvers could also be targets of query flood attacks.

In non-existent NX domain (NXDOMAIN) attacks, the clients that have been compromised send queries for domains that do not exist. This uses resources and can fill up the cache.

In phantom domain attacks, the clients that have been compromised send DNS queries for a phantom domain name—a domain server that exists, but it is controlled by an attacker. The attacker might have configured it to send no responses or slow responses. These illegitimate transactions waste resources, and a flood of them can take down the DNS resolver.

You can use FortiDDoS DNS flood mitigation features to prevent query floods.

DNS response exploits

There are also many attacks that use DNS responses to do damage. Unsolicited responses are a symptom of DNS Distributed Reflective Denial of Service attacks, DNS amplification attacks, and DNS cache poisoning.

You can use the FortiDDoS DNS query response matching (DQRM) feature to prevent DNS response exploits.

FortiDDoS DNS protection module summary

FortiDDoS has the following protection modules for DNS (transport over TCP or UDP):

• Protocol anomaly rules
  Built-in and user-enabled rules filter malformed traffic and known protocol exploits. There is a special set of anomalies that can be detected in DNS traffic. For an overview of protocol anomalies, see Understanding FortiDDoS protocol anomaly protection.
• Rate meters and flood mitigation mechanisms
  For TCP, the DNS rate meters enforce rate limits (drops). For UDP, the DNS rate meters trigger flood mitigation responses that drop illegitimate queries but continue DNS services for legitimate user queries. For details, see FortiDDoS DNS flood mitigation overview.
• DNS Query Response Matching (DQRM)
  Blocks unsolicited responses and throttles duplicate queries (regardless of flood state). See FortiDDoS DNS flood mitigation overview.

The following two figures illustrate the order in which FortiDDoS applies its rules and actions for TCP and UDP DNS traffic, respectively.

FortiDDoS DNS flood mitigation overview

FortiDDoS mitigates DNS threats by applying tests to determine whether queries and responses are legitimate. These methods minimize illegitimate traffic from reaching protected DNS servers and maximize the availability of DNS services for legitimate queries during a flood.

Under normal conditions (no floods), FortiDDoS builds a baseline of DNS traffic statistics and stores DNS query and response data in tables. At all times, the tables are used to validate response traffic. During UDP floods, the tables are used to test queries and responses. The following table describes the system tables used for DNS attack mitigation.

DNS-related system tables

System Table	DNS Flood Mitigation
DNS Query Response Match (DQRM) table	Used for all DNS traffic—UDP or TCP. When it receives a DNS query, the system stores the DNS transaction details in the DQRM table. It can store up to 1.9 million records. When it receives a response, it searches this table for a matching query. If the response has no matching query, FortiDDoS drops the unmatched response. Drops are reported on the Monitor > Layer 7 > DNS > Unsolicited Response graph. The table entry is cleared after the matching response is received. The DQRM table response validation prevents attacks that attempt to exploit DNS responses, such as DNS cache poisoning and DNS amplification attacks (also called Distributed Reflective Denial of Service attacks). The DQRM can also be used to throttle repeated queries that would otherwise result in unnecessary server activity. The "Duplicate query check before response" option drops identical queries (same transaction details) that are repeated at a rate of 3/second. Drops are reported on the Monitor > Layer 7 > DNS > Unexpected Query graph.
Legitimate Query (LQ) table	Used to mitigate UDP floods. When a valid response is received, the query details are stored in the table. It can store 128,000 records. Entries are cleared when the TTL expires. During a flood, the system drops queries that do not have entries in the table. Drops are reported on the Monitor > Layer 7 > DNS > LQ Drop graph.
TTL table	Used to mitigate UDP floods. When a valid response is received, the query details are correlated with the client IP address and stored in the table. It can store 1.5 million records. Entries are cleared when the TTL expires. Responses with TTL=0 are not added to the table. During a flood, the system drops queries that have an entry in the table. It is not expected that a client would send the same query before the TTL expires. Drops are reported on the Monitor > Layer 7 > DNS > TTL Drop graph.
Legitimate IP table	Used to mitigate UDP floods. During DNS query floods, you can leverage the legitimate IP (LIP) table to test whether the source IP address is spoofed. If the source IP address is found in the LIP table, processing continues; if there is no entry, the system can test source IP legitimacy by performing a UDP retransmission test or by sending a response with the TC flag set. The TC flag indicates to the client to retry the request over TCP. When the query is retried over TCP, other flood mitigation mechanisms may be available, such as SYN flood antispoofing features. Drops are reported on the Monitor > Layer 7 > DNS > Spoofed IP Drop graph.
DNS cache	Used to mitigate UDP floods. When a valid response is received, the system caches the response packets. It can store 64,000 records. Entries are cleared when the TTL expires. During a flood, if the query passes the LQ and TTL checks, the response is served from the cache and the query is not forwarded to the DNS server. This enables legitimate clients to get DNS results without adding load to the server that is being attacked. If there is not an entry in the cache, you can configure whether you want the query to be forwarded to the DNS server or have FortiDDoS send a response with the TC flag set. The TC flag indicates to the client to retry the request over TCP. Drops are reported on the Monitor > Layer 7 > DNS > Cache Drop graph.
Source tracking table	Used for source flood tracking—UDP or TCP. Tracks DNS queries per source and suspicious actions per source. It drops packets that exceed the maximum thresholds and applies the blocking period for identified sources. Drops are reported on the Monitor > Layer 7 > DNS Query Per Source and the Monitor > Layer 7 > Suspicious Sources graphs.

Source tracking thresholds and TCP thresholds are rate limits, resulting in drops when the flood rate thresholds are crossed. For UDP, rate thresholds trigger mitigation mechanisms. Drops are based on results of the mitigation checks. The figure below illustrates the packet flow through mitigation mechanisms during a UDP flood.

FortiDDoS DNS flood types

The following table summarizes the types of DNS floods mitigated by FortiDDoS.

DNS Flood types

DNS flood types

DNS Flood Type	Thresholds
Query Flood	Abnormal rate of DNS queries or occurrences of query data. Spikes in DNS queries and fragmented queries are obvious symptoms of an attempt to take down the DNS server. Changes in norms for query data, such as question type and question count, are also symptoms of exploit attempts. Detected by the dns-query, dns-fragment, dns-question-count, dns-mx -count, dns-all-count, and dns-zone-xfer-count thresholds. The Monitor > Layer 7 graphs include packet rate graphs for each key threshold, and the Layer 7 drops graphs show which thresholds were at a flood state when the packets were dropped.
Per Source Flood	Rate limit for DNS queries from a single source. Detected by the dns-query-per-source threshold. The system applies the blocking period for identified sources. The Monitor > Layer 7 graphs include a Query Per Source graph.
Suspicious Sources	Heuristics to track other abnormal activity from a single source. Detected by the dns-packet-track-per-src threshold. This counter is incremented when a query is not found in the DQRM, when there are fragmented packets in the query or response, and when the response has an RCODE other than 0. The system applies the blocking period for identified sources. The Monitor > Layer 7 graphs include a Suspicious Sources graph.

FortiDDoS DNS deployment topologies

FortiDDoS can be deployed to protect:

• Authoritative DNS servers that receive queries from the Internet.
• DNS recursive resolvers that send queries to and receive responses from Internet DNS authorities.

The following figure shows a topology where FortiDDoS is deployed primarily to protect the authoritative DNS server for a domain. Under normal traffic rates, FortiDDoS builds a baseline of DNS traffic statistics and stores DNS query and response data in tables. The tables are used to validate response traffic.

DNS no flood: inbound queries

	Query	Response
UDP	Adds an entry to the DQRM table. Performs a duplicate query check to prevent unnecessary queries to the server.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped. Updates the LQ table, the TTL table, and the DNS cache.
TCP	Adds an entry to the DQRM table. Performs a duplicate query check to prevent unnecessary queries to the server.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped.

The following figure shows a topology where FortiDDoS is deployed in front of an internal DNS resolver that sends queries to and receives responses from the Internet. This type of deployment is useful for open resolvers where the DNS resolver is protected primarily from Internet-originating inbound reflection attacks.

FortiDDoS collects data and validates the inbound responses and outbound requests the same as when queries are inbound. This deployment protects your network against different threats, such as DNS amplification attacks that result in unsolicited DNS response floods to targeted victims and DNS cache poisoning attacks, in which attackers send responses with malicious records to DNS recursive resolvers. In a deployment like this, the unsolicited responses would fail the DQRM check and be dropped.

DNS query flood mitigation

The following shows how FortiDDoS mitigates a DNS query flood. It uses the DNS tables and LIP table to validate queries and responses.

	Query	Response
UDP	Validates against the LQ table. Under flood conditions, a query must have an entry in the LQ table or it is dropped. Validates against the TTL table. If a match is found, the TTL check fails and the packets are dropped. It is not expected that a client would send the same query before the TTL expires. Perform a lookup in the LIP table. If an entry exists, processing continues; otherwise, FortiDDoS drops the packets and tests the legitimacy of the source IP address. You can configure FortiDDoS to do so by performing a UDP retransmission challenge or by sending the requestor a response with the TC flag set. The TC flag indicates to the client to retry the request over TCP. Performs a lookup in the DNS cache. If found, the response to the query is sent from the cache and the query is not forwarded to the protected server. If not found, you can configure whether to forward the query to the server or to send a TC=1 response to force the client to retry using TCP. Adds an entry to the DQRM table.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped. Updates the LQ table, the TTL table, and the DNS cache.
TCP	Drops packets according to thresholds. Adds an entry to the DQRM table. Performs a duplicate query check to avoid unnecessary queries to the server.	Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped.

Getting started with DNS mitigation

We recommend you allocate an SPP exclusively for DNS traffic. It takes a week to establish a baseline of traffic statistics for the SPP.

Steps

1. Go to Service Protection > Service Protection Policy and create an SPP rule exclusively for DNS traffic.
2. Go to Service Protection > Service Protection Policy> {SPP Rule} > Service Protection Policy. Ensure the SPP is in Detection mode.
3. Navigate to Service Protection > DNS Profile and create a DNS Profile that links the SPP Rule created in step 1.
4. Set DNS Feature Controls > DNS Fragment to Enable to apply Fragment ACLs (If required/Optional)
5. Add DNS Resource Record Type ACL to same DNS Profile (if required/Optional)
6. We recommend that you enable all anomaly checks under the section DNS Anomaly Feature controls and disable only if you encounter false positives (not expected)
7. We recommend you enable all features under DNS Feature Controls section and leave disabled only features that are not suitable for your deployment.
8. Navigate to Traffic Monitor > Layer 7 > DNS and observe the accumulation of traffic statistics for the SPP's DNS counters. After you have established a baseline (a week's worth of traffic), continue on to the next steps to prepare for and switch to prevention mode.
9. Configure thresholds in the following way:
   1. Go to Service Protection > Service Protection Policy > Threshold Settings > System Recommendation and generate baseline statistics.
   2. On the same System Recommendation page, generate thresholds.
   3. Go to Service Protection > Service Protection Policy > Thresholds, and review the configurations. Make any manual changes if necessary.
10. Create TCP Profile and Enable TCP Session Feature controls > Foreign packet validation. This feature is useful when there is DNS traffic over TCP and FortiDDoS drops connections due to rate limits. When this setting is enabled, subsequent packets from the same connection are dropped.
11. Navigate to Service Protection > Service Protection Policy > {SPP rule}> Service Protection Policy, set Operating mode to Prevention.