Our authoritative only name-servers are every once in a while hit by strange DNS queries. To spot anomalies we use DSC (DNS Statistic Collector), which allows exploring many details of DNS requests and responses to and from our name-servers. Usually one can already get a good sense of what has happened with DSC. However often, deep packet inspection is needed to get the full picture.
DNS traffic heading towards our authoritative only name-servers is stored for a few days in PCAP. Should we have any need to analyse some of the data we can then easily do so. Analysing very large PCAP files may sound cumbersome but thanks to PacketQ this is actually very easy and fast. PacketQ was originally developed by IIS.SE and is open source. It is a command line tool to run sql queries directly on PCAP files. It exports some IP and UDP header fields and most importantly all DNS protocol fields.
Let’s have a practical look at how PacketQ works by trying to figure out what kind of DNS ANY queries are being sent towards our name-server.
DNS ANY traffic is currently commonly abused for DNS amplification attacks (See Blog post “DDoS-Angriffe durch Reflektierende DNS-Amplifikation vermeiden” in German). The first thing I want to know is what are the IP addresses of the victims of this potential DNS amplification attack:
packetq -t -s "select src_addr,count(*) as count from dns where qtype=255 group by src_addr order by count desc limit 3" lolo.20130118.070000.000179
This suggests that a server within the Limestone Networks, US was targeted the most. Now the second question is what kind of query was being sent to us from this spoofed IP address:
packetq -t -s "select src_port,qname,NAME('qtype',qtype) as type,msg_id,msg_size,edns_version,edns0,do,udp_size,rd from dns where qtype=255 and src_addr='188.8.131.52' group by src_port" lolo.20130118.070000.000179
27015 ,"li." ,"*" ,0 ,31 ,1 ,1 ,4096 ,1
When using ‘dig’, the recursion desired (RD bit) is set by default. When doing a DNSSEC lookup where the DO bit is set, EDNS is set with a default buffer size of 4096. So, the query we see above can be shortened and manually executed as follow:
dig +dnssec li. ANY
This query provides a very high amplification factor. As the DNS ANY traffic burst was quite short and the source port was static; one can assume that this was not a DDoS against network bandwidth. It is more likely an application DDoS. So the assumption would be that port 27015 was actually an open (reachable) TCP or UDP port on the target system.
Entering both the IP address and the source port on Google reveals that the target was indeed a Game Server. We can also try and estimate the size of the botnet which was used to send this DNS ANY traffic:
packetq -t -s "select ip_ttl,count(ip_ttl) from dns where qtype=255 and src_addr='184.108.40.206' group by ip_ttl" lolo.20130118.0* | grep ^[0-9] | wc -l
Each of the infected 176 bot-clients sent roughly 10’000 DNS ANY requests as the following command output suggests:
packetq -t -s "select ip_ttl,count(ip_ttl) from dns where qtype=255 and src_addr='220.127.116.11' group by ip_ttl" lolo.20130118.0*
Thanks to PacketQ it usually takes less then a minute to explain such events.
If you are an operator of some DNS infrastructure and need to analyse DNS traffic anomalies I suggest you give PacketQ a try. Rickard Dahlstrand, one of the authors of PacketQ, has also made a short demo-video that shows the capabilities of PacketQ.