Summary
Infoblox Advanced DNS Protection (ADP) protects DNS resources in both your local and other related DNS infrastructures. It makes the NIOS appliance highly resilient to network attack and protects your authoritative and recursive (internal and external) DNS infrastructures. It is used by Enterprise and Service Providers for authoritative and recursive DNS servers.
Overview
It is expected that you have access to an ADP or have used ADP at some point. Having experience with deep packet inspection firewalls is also useful.
This article is aimed at having you look at and understand the different categories that encompass a recent ruleset that was deployed to a lab Grid. We’ll explore a number of rules that range from simple pattern matching, and rate limiting rules to those that have tight integration with the DNS Server. This combined with weighted random early detection (which if you are unfamiliar with is summarized in WRED) allows for unparalleled protection of the DNS infrastructure. WRED is an integral part of the ADP feature set.
There are more than 2,500 rules in this ruleset. The majority of these rules are explicitly DNS whilst others protect services like BGP/OSPF/ICMP. The default, like many firewalls, is to drop incoming packets. This means that there are also pass rules. So a DNS query, if it is not subjected to rate limiting, dropping due to anomalous protocol conformance, needs to be explicitly passed.
There are three primary types of rules: Auto, System, and Custom.
The Auto rules are further broken down into whether they are enabled dependent upon a service that is enabled/disabled. For example, if you are not serving NTP, then only a single drop all NTP packets needs to be enabled, but if you are serving NTP, a number of rate limit rules, and checks are performed. All other auto rules are always enabled. Some have tunable parameters.
System rules can be enabled, disabled, and if needed tuned. They have parameters like Events per Second (EPS), Packets Per Second (PPS), Drop Interval, and Rate Algorithm.
Custom rules for UDP or TCP are based upon your security needs. They can blacklist, whitelist, pass message types, or enforce rate limiting based upon an attribute like FQDN or an IP address.
Note: This blog is about the rules generally (including custom templates), but should not be relied upon or used for overall tuning which is specific to your deployment architecture and traffic volume and type.
ADP and DNS Firewall
It is important to understand the difference between ADP, and DNS Firewall (RPZ) when discussing such rules.
ADP’s intent is to protect the DNS infrastructure from direct and indirect volumetric attack. It can also be used to blunt the attack of other parts (that you do not control) of the recursive DNS infrastructure.
DNS Firewall can look at millions of FQDNs and IP addresses to match the initial query and/or a FQDN/IP address found during its recursion. DNS Firewall is looking for C2, Malware delivery (including watering holes), DNS tunnels (Exfiltration/Infiltration with a known FQDN) and many other undesirable endpoints.
Categories
Since some categories consist of just service defined auto rules, we will only briefly describe them here.
BFD
Auto rules used in conjunction with BGP and/or OSPF to support Bidirectional Forwarding Detection (BFD). This is a service based category, and there are a number of rate limiting rules. The defaults should suffice for the majority of deployments. Changes should only be instigated with the approval of Infoblox Support or Professional Service Engineers.
Example: RATELIMIT PASS BFD multi-hop with IPv6 BGP peer
BGP
Auto rules required to support your member being part of a BGP Anycast deployment. This is another service based category, and there are a number of rate limiting rules. The defaults should suffice for the majority of deployments. Changes should only be instigated with the approval of Infoblox Support or Professional Service Engineers.
Example: DROP BGP spoofed connection reset attempts
DHCP
The category protects the DHCP process when it is running on the appliance. In general, it is advised not to have any network devices on the same L2 broadcast domain as your ADP appliance. Rules are intended to protect against malicious clients that flood with abnormal amounts of data or with malformed dhcp requests. ADP manages the state of these rules to match the service being enabled or not. You need to consider the Leases Per second capability of the Infoblox member before changing the rate limits.
Example: PASS IPv4 DHCP Fail-Over Association
DNS Amplification and Reflection
The primary rule “WARN & DROP DoS DNS possible reflection/amplification attack attempts” is an auto rule which should never be increased over 5 PPS, as this allows classic amplification/reflection attacks. This is the ANY request and it is normally used for troubleshooting purposes. Attackers use it with DNSSEC to obtain a maximum sized response with a spoofed client address.
The other rules with regards to root requests should be enabled and kept default unless the PPS rate is greater than the flood rules (covered later).
Example: WARN & DROP DoS DNS possible reflection/amplification attack attempts
DNS Cache Poisoning
In order to be susceptible to DNS Cache Poisoning, a Recursive NameServer needs to accept large volumes of DNS responses over extended periods of time. The default values offer significantly reduced possibilities that this could occur. Of course if DNSSEC is properly configured and used, DNS Cache Poisoning is eliminated for those DNS Zones protected by DNSSEC.
Example: EARLY PASS UDP response traffic
DNS DDoS
There are a number of rules which take into account the response to the query from each client and will block the offending client entirely from making any more DNS queries during the drop interval. These rules pick up on NXDomain, NXRRset, and SERVFAIL responses. In general, these rules should be enabled, initially at a PPS value of just under the flood rules (so you can see them being hit), and tuned lower if needed.
Example: NXRRSET rate limiting rule
DNS Malware
A list of categories that is dynamically updated with known malware domains. It also includes TOR proxies and at the moment of writing is over 800 entries. Enabling this category can generate a lot of logging depending on the type of clients that resolve dns through ADP. Having it enabled stops the proliferation of malware in the connected networks as clients cannot connect to their command and control servers anymore. These are pure FQDN pattern matching rules, and queries tend to arrive in large volumes.
Example: EARLY DROP UDP MALWARE backdoor
DNS Message Types
These rules will be applied after all the rate limiting, protocol anomalies, etc … They are the default passes for regular query types. If you disable this category, you will drop all DNS queries. This a very bad idea !!
You can, after very careful consideration, block an individual record types by disabling its matching rule in this category. For example, if you will never serve a NAPTR, you could disable the relevant Pass rule.
Example: DNS TLSA record
DNS Protocol Anomalies
Designed to detect and stop invalid DNS traffic and DNS data noncompliant with the standards. While this filters out misbehaving clients you can also see certain IoT devices causing hits because of non-standard dns behavior. If you disable any of these rules, you’ll likely see FORMERR type responses from Named.
There are two rules, EARLY DROP UDP DNS query without Recursion Desired and EARLY DROP TCP DNS query without Recursion Desired. These rules should only be instigated with the approval of Infoblox Support or Professional Service Engineers. The intent of these rules is to prevent cache analysis of a recursive server. If they are enabled on an authoritative DNS server, it will not respond to authoritative queries without the RD bit set.
Example: EARLY DROP UDP query invalid question count
DNS Tunneling
Is a category that contains rules to detect DNS tunnels based on volumetric parameters, and also some specific pattern matching rules for known tunneling applications (IODINE, DNScat2 etc). This is not to be confused with Threat Insight, which performs live analysis of traffic to find the low and slow tunneling activities.
Adjusting the Packet Size and PPS should be done carefully from their defaults. RATELIMIT UDP high rate inbound large DNS queries (anti tunneling) is very effective against volumetric tunnels that are used to bypass data limits for Service Providers, and for aggressive exfiltration of data.
Example: Iodine Case Check payload over UDP (anti tunneling)
Default Pass/Drop
Generic PASS and DROP rules that are either at the top of the chain or at the bottom to deal with unexpected protocols. It allows established connections via TCP, and UDP VPN Grid traffic to flow unimpeded. Typically, the only adjustment done is to change the EPS values of the DROP UDP DNS unexpected rule from 1 to 0, which prevents syslog messages being generated for this hit. Note that the count of these hits is still available in the reporting server.
Example: DROP unexpected protocol
General DDoS
This category is meant to prevent a number of classic DDoS techniques like the LAND attack, and LAN loopback attacks. These are auto rules.
Example: EARLY DROP DoS packets with same source and destination IP
HA Support
Category required to support and protect ADP appliances in HA configurations. ADP manages the state of these rules to match the service being enabled or not. These are auto rules.
ICMP
A category to deal with floods and unexpected ICMP messages. It is important to understand the IPv6 relies upon ICMP v6 for solicitation, and advertisement of neighbors, and routers. These rules will allow ICMP to function, but not allow it to abuse the system by attempting to cause resource starvation etc. These are auto rules.
Example: DROP ICMP large packets
NTP
Rules designed to protect NTP when it is running on your appliance or to discard any NTP traffic when it is not. ADP manages the state of these rules to match the service being enabled or not as well as the configuration of the NTP service. These are auto rules.
Example: RATELIMIT PASS NTPQ IPv4 requests
OSPF
Auto rules required to support your member being part of an Anycast deployment using OSPF. It provides protection for OSPF from various attacks. ADP manages the state of these rules to match the service being enabled or not. These are auto rules.
Example: RATELIMIT PASS OSPF multicast
Potential DDoS related Domains
These domains have been observed to be used in DDoS attacks like Slow Drip. They are system rules and are updated regularly.
Custom Templates
These templates allow you to create custom additions to your ruleset. For example you could rate-limit the number of MX queries per second because you suspect your network is being used to generate SPAM. Alternatively, you may want to isolate an IP address or network from querying this DNS Server. You may also want to drop or rate-limit a specific FQDN query.
Custom Templates to allow you to specify rate-limits, whitelists and blacklists. Once a rule is created using these templates it is high in the order of rules that get processed. Adding domains and IPs to these lists will have an impact on the further analysis/response of the query traffic.
Pass TCP DNS Message Types / Pass UDP DNS Message Types
These rules are here to allow the passage of DNS Message Types that are not normally used. This may be for experimentation or a specific use case. The creation of these rules is rare.
BLACKLIST DROP TCP IP prior to rate limiting / BLACKLIST DROP UDP IP prior to rate limiting
You can create rules to drop traffic based on IP or network. If you are seeing spoofed incoming traffic from your networks, it is advisable to review your network’s compliance with BCP 38. You can drop based on IP or CIDR. Allowing spoofed traffic also enables the use of your infrastructure for Amplification/Reflection attacks.
BLACKLIST TCP FQDN lookup for DNS Message Type / BLACKLIST UDP FQDN lookup for DNS Message Type
This allows for rule creation to drop a specific combination of Message Type and FQDN.
BLACKLIST TCP FQDN lookup / BLACKLIST UDP FQDN lookup
The following domains can be considered strong candidates for custom rules, as these are domains that are frequently generating a lot of traffic by misconfigured clients. They are also the reverse zones for internal networks which can generate a lot of NXDOMAIN responses:
- .wpad
- .local
- .localdomain
- 1.0.0.127.in-addr.arpa
- 168.192.in-addr.arpa
- 10.in-addr.arpa
- 172.16.in-addr.arpa
If your DNS server is authoritative, you could also create more appropriate responses.
RATE LIMITED TCP DNS Message Type / RATE LIMITED UDP DNS Message Type
The simple example is to limit the rate of MX queries per second, which may impact spammers, as well as notify you where they are.
RATE LIMITED TCP FQDN lookup / RATE LIMITED UDP FQDN lookup
If you have a high hit-rate on a DNS Firewall (RPZ) rule, and for some reason queries are constantly flooding, you can use this to blunt the effect of this FQDN, and you will still allow good DNS queries to be resolved from that client.
RATE LIMITED TCP IP / RATE LIMITED UDP IP
These three templates allow similar functionality as mentioned before, but rate limits specific client requests. The IP address can be an individual IP, or a network. A use case for this is to throttle a network that only has a certain type of IoT devices that may be misbehaving.
WHITELIST PASS TCP IP prior to rate limiting / WHITELIST PASS UDP IP prior to rate limiting / WHITELIST TCP domain / WHITELIST UDP domain
In a production environment, these generally should not be used unless you have complete control of the client generating the queries. They could be used to bypass an issue that is a result of misconfiguration, or bad architecture, but should not be considered as a long term solution. Whitelist removes rate-limiting protections.
Reconnaissance
A minor category that prevents attackers from fingerprinting the version and author of named. It is a simple reconnaissance restriction.
Example: EARLY DROP UDP DNS named author attempts
Subscriber Services
These rules allow Radius messages, and Subscriber cache replication. These are auto rules.
Example: PASS Radius Accounting-Request
TCP/UDP Floods
These are high in the order of rules and can serve as warning and rate limit rules for DNS traffic. Because they are so high in the order they act as the limit against lower ordered DNS based rate-limiting rule. This is very important to understand. For example if the NXDOMAIN rate limiting rule is the same, or higher in PPS that the flood rule, you will never see a hit against it.
Four rules exist, a pair of UDP and a pair of TCP. The first are a pair of simple warning rules for clients that exceed a PPS value for DNS queries, these two rules are typically only useful for environments with NOC/SOC monitoring. The other pair will block DNS queries that exceed a PPS rate.
Conclusion
Whilst we’ve only covered a handful of rules, it is easy to see the deep DNS coverage ADP rulesets cover. In most firewalls and proxy servers, there are only a shallow set of rules that attempt to validate the incoming DNS packet.
Infoblox Advanced DNS Protection provides through its ruleset the ability to mitigate and defeat DNS service disruption from the broadest array of DNS-based attacks. ADP distinguishes between legitimate and malicious DNS traffic in real time, enabling the DNS server to respond only to valid queries, even whilst under attack. You can defend against volumetric attacks, including DDoS and TCP/UDP/ICMP floods, whilst prevent DNS hijacking, cache poisoning, and other DNS-specific exploits.
