This section includes the following information:
|
|
Note: FortiDDoS 600B and 900B do not support DNS ACLs, DNS anomaly detection, or DNS flood mitigation. |
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 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.
Figure 20: DNS tunneling attack
You can use FortiDDoS DNS anomaly detection to drop DNS tunneling attempts if the tunneling attempts do not conform to DNS header syntax.
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.
Figure 21: DNS slow-drip, random, non-existent subdomain attack
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.
Figure 22: DNS NX domain and phantom domain attack
You can use FortiDDoS DNS flood mitigation features to prevent query floods.
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.
Figure 23: DNS reflection attack
Figure 24: DNS amplification attack
Figure 25: DNS cache poisoning
You can use the FortiDDoS DNS query response matching (DQRM) feature to prevent DNS response exploits.
FortiDDoS has the following protection modules for DNS (transport over TCP or UDP):
Figure 26 and Figure 27 illustrate the order in which FortiDDoS applies its rules and actions for TCP and UDP DNS traffic, respectively.
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.
Table 11 describes the system tables used for DNS attack mitigation.
| 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. Figure 28 illustrates the packet flow through mitigation mechanisms during a UDP flood.
Table 12 summarizes the types of DNS floods mitigated by FortiDDoS.
| 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. The Monitor > Layer 7 graphs include a Suspicious Sources graph. |
FortiDDoS can be deployed to protect:
Figure 29 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.
| Query | Response | |
|---|---|---|
| UDP |
|
|
| TCP |
|
Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped. |
Figure 30 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.
Figure 31 shows how FortiDDoS mitigates a DNS query flood. It uses the DNS tables and LIP table to validate queries and responses.
| Query | Response | |
|---|---|---|
| UDP |
|
|
| TCP |
|
Validates the response against the DQRM table. If there is an entry, the traffic is forwarded; otherwise, it is dropped. |
We recommend you allocate an SPP exclusively for DNS traffic. It takes a week to establish a baseline of traffic statistics for the SPP.
