1. A typical DNS request uses UDP.
2. While UDP is common for a DNS request, if the response will be greater than 512 bytes, the DNS server answering the request sends enough data in the response packet to fit 512 bytes but also sets the “TC” flag. When the receiving client sees the “TC” flag sets, it knows it should retry the request but this time over TCP.
3. DNS Zone Transfers always use TCP
4. In a master-slave DNS topology, it is the slave which always request the DNS zone transfer, not the master. However, if “DNS Notify” is available and configured, the master can notify the slave that it has updates. Once the slave is notified of the updates, the slave then request the updates.
5. Zone Transfers can be either AXFR (Authoritative Transfers) or IXFR (Incremental Zone Transfer)
With that out the way, let’s see what we can learn. Analyzing the logs.
First is the BIND server configured for logging? Let’s find out.
Let’s if we manage to capture anything
Looking at the log, we see that the client 10.0.0.100 requested the zone transfer. We also see when it started and when it ended.
Let’s see what our Windows 2012 system shows:
Event Type: Information
Event Source: DNS
Event Category: None
Event ID: 6001
Date: 4/29/2014
Time: 11:03:58 PM
User: N/A
Computer: SECURITYNIK2012
Description:
The DNS server successfully completed transfer of version 5 of zone securitynik.lab to the DNS server at 10.0.0.100.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Once again, we see the DNS zone was successfully transferred to 10.0.0.100.
Let’s do a packet analysis of one of a successful transfer.
What can we extract?
In this case, it takes 10 packets to complete the zone transfer of securitynik.lab
As can be seen, the IP Protocol number is “6” (TCP) for all packets.
The first 3 packets is the usual setup of the TCP 3-way handshake. However, as we look at the length of all the packets, it seems packet 6 is the largest at 289 bytes. Let’s expand this packet to see what we have.
Hmmm, above we see some info available in the hex dump. Now that we have this information, we can try pinging these names to see which ones replies.
Since we did an analysis of a successful zone transfer, how about we do the same for a failed one.
Let’s see what tshark gives us.
A quick analysis shows that in packet 4 the request was made from the client and in packet 5 the server refused to transfer the zone.
Your’s IDS/IPS may also have rules to detect zone transfers. Snort has two rules I’m aware of which should detect this. However, I did not run the snort against the pcap.
root@securitynik:~# grep -i 'zone transfer' /etc/snort/rules/*
/etc/snort/rules/protocol-dns.rules:alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"PROTOCOL-DNS dns zone transfer via TCP detected"; flow:to_server,established; content:"|00 01 00 00 00 00 00|"; depth:8; offset:6; byte_test:1,!&,0xF8,4; content:"|00 00 FC 00 01|"; fast_pattern; isdataat:!1,relative; metadata:policy security-ips drop, ruleset community, service dns; reference:cve,1999-0532; reference:nessus,10595; classtype:attempted-recon; sid:255; rev:22;)
/etc/snort/rules/protocol-dns.rules:alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"PROTOCOL-DNS dns zone transfer via UDP detected"; flow:to_server; content:"|00 01 00 00 00 00 00|"; depth:8; offset:4; byte_test:1,!&,0xF8,2; content:"|00 00 FC 00 01|"; fast_pattern; isdataat:!1,relative; metadata:policy security-ips drop, ruleset community, service dns; reference:cve,1999-0532; reference:nessus,10595; classtype:attempted-recon; sid:1948; rev:18;)
Additional Readings:
https://tools.ietf.org/html/rfc5966
https://tools.ietf.org/html/rfc1995
https://tools.ietf.org/html/rfc5936
http://tools.ietf.org/html/rfc1034
http://www.wireshark.org/docs/man-pages/tshark.html
No comments:
Post a Comment