DNS most interesting protocol can be analyzed using some packet filters that can help you look at and analyze various types of DNS packets on the network. In this blog, I am compiling a list of these to summarize the ones I have discovered as useful for analyzing DNS packets. The examples are relevant to UDP DNS which is about 90-95% of DNS packets seen.
Some DNS packet Basics
The diagram below shows DNS packets (from SANS TCP/IP cheat-sheet)
A DNS packets basically is reasonably structured and a fast link layer BPF filter can be applied to capture or analyze relevant packets.
Some Packet filter basics
The list below shows some basic examples of how BPF works say with tcpdump as a tool (taken from Washington State University talks)
Example:
The above example shows a DNS response with NXDomain bit set saying office-pc.mariposa.com is a non-existent domain record.
2. Is the DNS packet a Query or a Response
Example:
The two examples above shows a query for ad.doubleclick.net from 10.207.3.31 to 10.207.0.3 and the subsequent response for this query from 10.207.0.3 with the response details.
3. Is the DNS response authoritative or not?
Example:
The above example shows an authoritative response/answer for a227.da1akamai.net from 77.67.86.174 IP address to 10.207.0.3.
4. Combining filters - to say find DNS responses that are NXDomain and are NOT authoritative
Example:
The above above example is looking for NXDomain response that is not authoritative. This response from 10.24.28.100 to 172.19.1.5 is a relayed NXDomain response that was received from the root-servers.
5. Query refused - a DNS response from the server saying it cannot answer for the requested domain.
Example:
The above example is for a DNS response from 10.8.255.238 to 172.20.1.30 for "www.google.com" , which has been refused. The DNS server either cannot do recursion or denies recursion by policy for this domain from IP address 10.8.255.238.
6. Recursion Desired - a DNS query packet that has recursion desired set. Typically sent to your local DNS server to your ISP (DNS forwarding). Combination of a RD (Recursion Desired) filter and a Query filter.
Some DNS packet Basics
The diagram below shows DNS packets (from SANS TCP/IP cheat-sheet)
| 
|
Some Packet filter basics
The list below shows some basic examples of how BPF works say with tcpdump as a tool (taken from Washington State University talks)
Expression Meaning ========== ======= [x:y] start at offset x from the beginning of packet and read y bytes [x] abbreviation for [x:1] proto[x:y] start at offset x into the proto header and read y bytes p[x:y] & z = 0 p[x:y] has none of the bits selected by z p[x:y] & z != 0 p[x:y] has any of the bits selected by z p[x:y] & z = z p[x:y] has all of the bits selected by z p[x:y] = z p[x:y] has only the bits selected by z the usual rules about operator precedence apply; nesting things inside brackets is probably a good plan. you'll probably want to put the filter into a file or at least single-quote it on the command line to stop the shell from interpreting the metacharacters. !([:])&
Lets go to some use cases now
1. NXDomain (Non-Existent Domain) packets.
Capturing only NXDomain filter. NXDomain packet can be captured using the following filter
| udp[11] & 0xf = 3 |
| sh-4.1$ tcpdump -c 1 -pnnvvr dns_20120419072623.pcap "udp[11] & 0xf = 3" reading from file dns_20120419072623.pcap, link-type EN10MB (Ethernet) 12:26:23.257988 IP (tos 0x0, ttl 255, id 25644, offset 0, flags [DF], proto UDP (17), length 124) 10.207.0.3.53 > 10.207.21.38.51011: [udp sum ok] 22570 NXDomain* q: A? Office-pc.mariposa.com. 0/1/0 ns: mariposa.com. SOA server06.mariposa.com. hostmaster.mariposa.com. 2012041829 3600 1800 604800 3600 (96) |
2. Is the DNS packet a Query or a Response
Detecting a query or response has to do with using bitmask to find the first bit of udp[10]. If the first bit is 0 the DNS packet is a Query and first bit is 1 dns packet is a Response.
| udp[10] & 0x80 = 0 udp[10] & 0x80 = 128 |
| sh-4.1$ tcpdump -c 1 -pnnvvr dns_20120419072623.pcap "udp[10] & 0x80 = 0" reading from file dns_20120419072623.pcap, link-type EN10MB (Ethernet) 12:26:23.257645 IP (tos 0x0, ttl 126, id 456, offset 0, flags [none], proto UDP (17), length 64) 10.207.3.31.54383 > 10.207.0.3.53: [udp sum ok] 30335+ A? ad.doubleclick.net. (36) sh-4.1$ tcpdump -c 1 -pnnvvr dns_20120419072623.pcap "udp[10] & 0x80 = 128" reading from file dns_20120419072623.pcap, link-type EN10MB (Ethernet) 12:26:23.257934 IP (tos 0x0, ttl 255, id 50028, offset 0, flags [DF], proto UDP (17), length 263) 10.207.0.3.53 > 10.207.3.31.54383: [udp sum ok] 30335 q: A? ad.doubleclick.net. 3/4/4 ad.doubleclick.net. CNAME dart.l.doubleclick.net., dart.l.doubleclick.net. A 74.125.225.123, dart.l.doubleclick.net. A 74.125.225.124 ns: l.doubleclick.net. NS ns4.google.com., l.doubleclick.net. NS ns2.google.com., l.doubleclick.net. NS ns1.google.com., l.doubleclick.net. NS ns3.google.com. ar: ns1.google.com. A 216.239.32.10, ns2.google.com. A 216.239.34.10, ns3.google.com. A 216.239.36.10, ns4.google.com. A 216.239.38.10 (235) |
3. Is the DNS response authoritative or not?
| udp[10] & 4 = 4 |
| sh-4.1$ tcpdump -c 1 -pnnvvr dns_20120419072623.pcap "udp[10] & 0x4 = 4 " reading from file dns_20120419072623.pcap, link-type EN10MB (Ethernet) 12:26:23.336953 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 97) 77.67.86.174.53 > 10.207.0.3.48196: [udp sum ok] 32040*- q: A? a227.da1.akamai.net. 2/0/0 a227.da1.akamai.net. A 69.22.154.10, a227.da1.akamai.net. A 69.22.154.25 (69) |
4. Combining filters - to say find DNS responses that are NXDomain and are NOT authoritative
| udp[11] & 0xf = 3 and udp[10] & 4 != 4 |
| bash-3.2# tcpdump -i en2 -pnnvv "port 53 and udp[11] & 0xf = 3 and udp[10] & 4 != 4 " tcpdump: listening on en2, link-type EN10MB (Ethernet), capture size 65535 bytes 12:50:10.060297 IP (tos 0x0, ttl 59, id 5352, offset 0, flags [none], proto UDP (17), length 134) 10.24.28.100.53 > 172.19.1.5.62430: [udp sum ok] 38032 NXDomain q: A? www.gkkk.comm. 0/1/0 ns: . SOA a.root-servers.net. nstld.verisign-grs.com. 2013071900 1800 900 604800 86400 (106) |
The above above example is looking for NXDomain response that is not authoritative. This response from 10.24.28.100 to 172.19.1.5 is a relayed NXDomain response that was received from the root-servers.
5. Query refused - a DNS response from the server saying it cannot answer for the requested domain.
| udp[11] & 0xf = 5 |
| bash-3.2# # tcpdump -pnnvvr qrefused.pcap "udp[11] & 0xff = 5 " reading from file qrefused.pcap, link-type EN10MB (Ethernet) 15:00:22.391913 IP (tos 0x0, ttl 250, id 21282, offset 0, flags [none], proto UDP (17), length 60) 10.8.255.238.53 > 172.20.1.30.56977: [udp sum ok] 25150 Refused- q: ANY? www.google.com. 0/0/0 (32) |
The above example is for a DNS response from 10.8.255.238 to 172.20.1.30 for "www.google.com" , which has been refused. The DNS server either cannot do recursion or denies recursion by policy for this domain from IP address 10.8.255.238.
6. Recursion Desired - a DNS query packet that has recursion desired set. Typically sent to your local DNS server to your ISP (DNS forwarding). Combination of a RD (Recursion Desired) filter and a Query filter.
| udp[10] & 4 = 1 and udp[10] & 0x80 = 0 |
| bash-3.2# # tcpdump -pnnvvr ravailable.pcap "udp[10] & 1 = 1 and udp[10] & 0x80 = 0" reading from file ravailable.pcap, link-type EN10MB (Ethernet) 15:10:26.147419 IP (tos 0x0, ttl 64, id 43293, offset 0, flags [DF], proto UDP (17), length 62) 10.20.1.30.42324 > 10.20.1.1.53: [bad udp cksum 0x5a83 -> 0x378c!] 53253+ AAAA? daisy.ubuntu.com. (34) |
7. DNS response either too big or too small.
These two factors in DNS response (either too big or too small) can show some really interesting information. For example the DNS packet too small during Dyn DDOS attack showed that Dyn DNS servers where actually providing empty or not meaningful answers. DNS too large response shows that DNS response is being used in things like covert channel for malware.
| greater 180 or less 50 |
| bash-3.2# # tcpdump -pnnvvr dnsmessenger.pcap "greater 180 and less 50" reading from file ravailable.pcap, link-type EN10MB (Ethernet) 15:10:26.147419 IP (tos 0x0, ttl 64, id 43293, offset 0, flags [DF], proto UDP (17), length 2479) 10.20.1.1.53> 10.20.1.130.1139: [bad udp cksum 0x9983 -> 0x3a8c!] 53253+ TXT mail.reld.info. (2433)
09:33:39.910885 IP (tos 0x0, ttl 64, id 4043, offset 0, flags [none], proto UDP (17), length 44)
204.13.250.57.53 > 10.207.1.130.35020: [bad udp cksum f510!] 8556 ServFail q: A? paypal.co. 0/0/0 (20) |
The above example shows a TXT record that exceeds 180 bytes and shows the behavior of malware in DNSMessenger. The second record is from Dyn DDOS attacks that showed how the Dyn DNS servers answered with bogus answer or SRVFAIL answer. This actually caused my clients to keep asking for paypal.co and end up making Dyn's servers even more bottlenecked!
Conclusion
Using the above SANS TCP/IP chart and the basic understanding of BPF filters, you can build easy ways to capture DNS packets of interest. There are a number of good tools such as dnstop, dnscap are resourceful in doing DNS analysis. If you have DNS packets from some environment like a sandbox environment for analysis, this PCAP files can be quickly isolated to find issues with DNS.
No comments:
Post a Comment