BIG-IP Advanced Firewall Manager (AFM) DNS NXDOMAIN Query Attack Type Walkthrough
Introduction
In this article, we will look at configuring BIG-IP Advanced Firewall Manager's (AFM) DNS NXDOMAIN attack type in the Device Protection and DNS enabled protection profile to mitigate DNS NXDOMAIN response floods. We will review data from a packet capture and BIG-IP DNS' DNS profile statistics to set detection and mitigation thresholds.
This is part one of two of this article series.
Part two is at https://community.f5.com/t5/technical-articles/big-ip-advanced-firewall-manager-afm-dns-nxdomain-query-attack/ta-p/317681
What is a NXDOMAIN dns response
The DNS protocol [RFC1035] defines response code 3 as "Name Error",
or "NXDOMAIN" [RFC2308], which means that the queried domain name
does not exist in the DNS. Since domain names are represented as a tree of labels ([RFC1034], Section 3.1), nonexistence of a node
implies nonexistence of the entire subtree rooted at this node.
From https://datatracker.ietf.org/doc/html/rfc8020#page-5
How is NXDOMAIN dns response generated
RCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:
3 Name Error - Meaningful only for
responses from an authoritative name
server, this code signifies that the
domain name referenced in the query does
not exist.
https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.1
What is a NXDOMAIN (response) flood?
From the F5 Glossary in https://www.f5.com/glossary/dns-flood-nxdomain-flood
The roadmap to every single computer on the Internet is held in DNS servers. The DNS NXDOMAIN flood attack attempts to make servers disappear from the Internet by making it impossible for clients to access the roadmap.
In this attack, the attacker floods the DNS server with requests for invalid or nonexistent records. The DNS server spends its time searching for something that doesn't exist instead of serving legitimate requests. The result is that the cache on the DNS server gets filled with bad requests, and clients can't find the servers they are looking for.
How do threat actors generate random dns queries
There are many tools to generate a flood of DNS queries . The DNS records in the flood of DNS queries for the most part, should be unique if an attacker wants to poison a DNS servers cache. Otherwise, a DNS administrator can simply blackhole if the same DNS record is queried in DNS flood query.
DNS Blackhole
https://en.wikipedia.org/wiki/DNS_sinkhole
Here is a devcentral article on DNS Blackhole implemented in an iRule
https://community.f5.com/t5/codeshare/dns-blackhole/ta-p/283786
Domain Generation Algorithms
To generate many random host records for one or many domains, Domain Generation Algorithms are used.
https://en.wikipedia.org/wiki/Domain_generation_algorithm
Many examples of DGA as collected in https://github.com/baderj/domain_generation_algorithms shows how these random records may look like.
In the lab setup we will be using, we have the fop789[.]loc domain, and I borrowed from the github page random host list generated thru the "mydoom (aka Novarg, Mimail.R, Shimgapi)" DGA and appended the host part of the host list to the test lab domain .
qehspqnmrn[.]fop789[.]loc
mmahaesqar[.]fop789[.]loc
pwprhhnqqn[.]fop789[.]loc
....
Here is a sample query using the one of the hostnames. As expected, a NXDOMAIN response is received because this record does not exist in the sample lab domain fop789.loc.
root@ubuntu-server1:~# dig @10.93.56.197 qehspqnmrn.fop789.loc
; <<>> DiG 9.16.1-Ubuntu <<>> @10.93.56.197 qehspqnmrn.fop789.loc
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1279
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;qehspqnmrn.fop789.loc. IN A
;; AUTHORITY SECTION:
fop789.loc. 300 IN SOA ns1.fop789.loc. hostmaster.ns1.fop789.loc. 2023041101 10800 3600 604800 86400
;; Query time: 4 msec
;; SERVER: 10.93.56.197#53(10.93.56.197)
;; WHEN: Sun Jun 25 11:10:41 UTC 2023
;; MSG SIZE rcvd: 101
root@ubuntu-server1:~#The most prevalent reason why threat actors would use DGA is in malware and phishing campaigns to avoid detection and resilient to counter measures. The evasion technique used is Fast flux.
Fast flux
Fast flux is a domain name system (DNS) based evasion technique used by cyber criminals to hide phishing and malware delivery websites behind an ever-changing network of compromised hosts acting as reverse proxies to the backend botnet master—a bulletproof autonomous system. It can also refer to the combination of peer-to-peer networking, distributed command and control, web-based load balancing and proxy redirection used to make malware networks more resistant to discovery and counter-measures.
The fundamental idea behind fast-flux is to have numerous IP addresses associated with a single fully qualified domain name, where the IP addresses are swapped in and out with extremely high frequency, through changing DNS resource records, thus the authoritative name servers of the said fast-fluxing domain name is—in most cases—hosted by the criminal actor
Depending on the configuration and complexity of the infrastructure, fast-fluxing is generally classified into single, double, and domain fast-flux networks. Fast-fluxing remains an intricate problem in network security and current countermeasures remain ineffective.
https://en.wikipedia.org/wiki/Fast_flux
What information can be used in observing NXDOMAIN response spike
There are several sources of information that can be used when NXDOMAIN response spike.
BIG-IP DNS profile statistics
A BIG-IP DNS listener (Virtual Server) will have a DNS profile applied to it. This profile provides access to DNS traffic statistics. In particular, "Question Type" and "Return Code" sections has statistics on DNS record types queried and return code count.
Here is a sample output from a script that periodically captured DNS profile statistics - stats were taken 20 seconds apart. These were taken during a lab test where NXDOMAIN response flood is being simulated.
Here is the sample script:
while true; do date >> /var/tmp/dns_stat.txt; tmsh show ltm profile dns dns-prof-1 >> /var/tmp/dns_stat.txt; echo "###################" >> /var/tmp/dns_stat.txt; sleep 20; doneNotice that the "Question Type" has only "A" records queried and in the "Return Code (RCODE)" , only " No Name (NXDOMAIN)" were the responses.
Date: Sun Jun 25 11:15:59 PDT 2023
---------------------------------------------------
Ltm::DNS Profile: dns-prof-1
---------------------------------------------------
Virtual Server Name N/A
Query Message
Recursion Desired (RD) 18847 100.0
DNSSEC Checking Disabled (CD) 0 0.0
EDNS0 18847 100.0
Client Subnet 0 0.0
Client Subnet Inserted 0 0.0
Operation Code (OpCode)
Query 18847 100.0
Notify 0 0.0
Update 0 0.0
Other 0 0.0
Question Type
A 18847 100.0
AAAA 0 0.0
ANY 0 0.0
CNAME 0 0.0
MX 0 0.0
...
Other 0 0.0
Response Message
Authoritative Answer (AA) 18843 99.9
Recursion Available (RA) 0 0.0
Authenticated Data (AD) 0 0.0
Truncated (TC) 0 0.0
Return Code (RCODE)
No Error 1 0.0
No Name (NXDOMAIN) 18842 99.9
Server Failed 0 0.0
Refused 1 0.0
Bad EDNS Version 0 0.0
Name Error (NXDOMAIN) Override 0 0.0
EDNS0 client subnet 0 0.0
Date: Sun Jun 25 11:16:19 PDT 2023
Query Message
Recursion Desired (RD) 18993 100.0
DNSSEC Checking Disabled (CD) 0 0.0
EDNS0 18993 100.0
Client Subnet 0 0.0
Client Subnet Inserted 0 0.0
Operation Code (OpCode)
Query 18993 100.0
Notify 0 0.0
Update 0 0.0
Other 0 0.0
Question Type
A 18993 100.0
AAAA 0 0.0
ANY 0 0.0
CNAME 0 0.0
...
Other 0 0.0
Response Message
Authoritative Answer (AA) 18989 99.9
Recursion Available (RA) 0 0.0
Authenticated Data (AD) 0 0.0
Truncated (TC) 0 0.0
Return Code (RCODE)
No Error 1 0.0
No Name (NXDOMAIN) 18988 99.9
Server Failed 0 0.0
Refused 1 0.0
Bad EDNS Version 0 0.0
Name Error (NXDOMAIN) Override 0 0.0
EDNS0 client subnet 0 0.0Sample packet capture during a NXDOMAIN response spike
Earlier, we reviewed what is Domain Generation Algorithm (DGA) and that its used to generate random DNS names which are used by threat actors in fast flux technique to evade detection and mitigations for their phishing and malware campaigns.
The sample packet capture was taken while using the sample random DNS names generated thru a DGA to simulate a NXDOMAIN response flood.
Using the capinfos command, we can observe various details about the packet capture. First and last packet time tells us how long this pcap was running, in this case it has been around 13 mins. Also average packet rate per second, 76 packets/sec, can be useful if we are looking to find a baseline on packets per second value. And other packet capture details which may be useful depending on your purpose.
Since we are looking at DNS traffic, remember its query and response packets, so 76 packets per second, presumably may contain both type of packets, thus, estimation of 38 packets per second for dns queries.
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # capinfos nx-4.pcap
File name: nx-4.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Number of packets: 60 k
File size: 16 MB
Data size: 15 MB
Capture duration: 786.961838 seconds
First packet time: 2023-06-25 11:05:48.352417
Last packet time: 2023-06-25 11:18:55.314255
Data byte rate: 19 kBps
Data bit rate: 159 kbps
Average packet size: 260.57 bytes
Average packet rate: 76 packets/s
SHA1: 10d3652ce3b97d68d16f324ee6eaac918b8f34d9
RIPEMD160: 7c766e4e5819fb9f5c90cee133f0e1f61e9b5801
MD5: 51cd10815de35802460ae0b26e156d66
Strict time order: False
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 60063Next up, use tshark to get more information from the packet capture. Specifically, we are interested in the dns related information, such as the DNS records queried and the DNS response.
Extract all dns names from the packet capture - queries or response
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # tshark -r nx-4.pcap -n -T fields -e dns.qry.name > nx-4-pcap-records.txt
Running as user "root" and group "root". This could be dangerous.Reviewing the number of dns names extracted, it matches the output from capinfos - 60063.
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records.txt | wc -l
60063Sort the dns names extracted from the pcap - notice the randomness of these dns names. Could be fast flux technique or an attempt to drown a DNS server of random records that it needs to search and eventually cause service disruption - a classic DNS water torture attack.
The sample DNS names taken from the pcap are still not so random and are short. There are longer and more random hostnames that can be generated by DGAs and this can really take a lot of memory and cpu resource from a DNS server.
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records.txt | sort | uniq -c | sort -nrk 1
3514 mmahaesqar.fop789.loc
3512 arphansaqh.fop789.loc
3509 hwepmerswa.fop789.loc
3508 qrqnswerqs.fop789.loc
3506 seenwrqrps.fop789.loc
3506 pwprhhnqqn.fop789.loc
3506 hrhspsrenn.fop789.loc
3506 arwrseqssh.fop789.loc
3505 eqqhnpswmh.fop789.loc
3504 fop789.locaehwmnms.fop789.loc
3503 qehspqnmrn.fop789.loc
3503 psrhaaeqqa.fop789.loc
3503 paepnpamea.fop789.loc
3503 ewamspqwha.fop789.loc
3501 aepaaemrmn.fop789.loc
3500 mrspmramrn.fop789.loc
3499 rnqhapapwn.fop789.loc
475DNS Water Torture Denial-of-Service Attacks
Customers reported pseudo-random subdomain or “DNS water torture attacks” hitting their networks with half a million connections per second. Outages were occurring even if a network wasn’t the direct target of the attack. For example, service providers still felt the effects as the DNS water torture traffic passed through their networks and saturated their pipes.
To pull off a DNS water torture attack, an attacker leverages a botnet (or thingbot) to make thousands of DNS requests for fake subdomains against an Authoritative Name Server.1 Because the requests are for non-existent subdomains or hosts, the requests consume the memory and processing resources on the main resolver. If there are intermediary DNS resolvers inline, they too get clogged up with these fake requests. For legitimate end users, all this resource consumption means everything runs slow or even stops, resulting in a denial of service.
Filtering further, we can extract the DNS response packets only
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # tshark -r nx-4.pcap -n -Y "dns.flags.response == 1" -T fields -e dns.qry.name > nx-4-pcap-records-response.txt
Running as user "root" and group "root". This could be dangerous.DNS response packets only count shows 29994, approx half of the previous output of 60063
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records-response.txt | wc -l
29994We can then sort DNS response packets only and find the number of times each DNS name was responded to. We know that the response to these queries are NXDOMAIN because we don’t have these records in the lab DNS server records list. We can also observe which DNS names were responded the most. In the example output, each of the records were responded almost equally.
[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records-response.txt | sort | uniq -c | sort -nrk 1
1748 qehspqnmrn.fop789.loc
1748 mmahaesqar.fop789.loc
1746 seenwrqrps.fop789.loc
....
1746 aepaaemrmn.fop789.loc
1744 paepnpamea.fop789.loc
1744 arphansaqh.fop789.loc
1742 eqqhnpswmh.fop789.loc
316