Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: DNS query spam

Subject: Re: DNS query spam
Date: Mon, 28 Nov 2005 17:37:35 -0700
On Nov 27, 2005, at 3:30 PM, Piotr Kamisiski wrote:
Recently my DNS servers get jammed with bogus queries. The attacks come in series, taking a few minutes each, sometimes from different IPs at the same time, at least twice a day.

<snap>
23:05:40.241026 IP 204.92.73.10.40760 > xx.xx.xx.xx.53: 38545+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:41.600902 IP 204.92.73.10.16561 > xx.xx.xx.xx.53: 22242+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:42.091743 IP 204.92.73.10.37547 > xx.xx.xx.xx.53: 64644+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:43.433539 IP 204.92.73.10.32370 > xx.xx.xx.xx.53: 31772+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:43.854481 IP 204.92.73.10.12913 > xx.xx.xx.xx.53: 33470+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:44.378640 IP 204.92.73.10.62484 > xx.xx.xx.xx.53: 8726+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:45.368970 IP 204.92.73.10.57384 > xx.xx.xx.xx.53: 1073+ [1au] ANY ANY? e.mpisi.com. (40)
23:05:45.379251 IP 204.92.73.10.36997 > xx.xx.xx.xx.53: 22257+ [1au] ANY ANY? e.mpisi.com. (40)
<snap>


Has anyone noticed a similar activity?

I was seeing this kind of thing last month. I suspect that it's part of a DDoS attack on the IP address that the queries claim to come from, but it could also be an attack on your DNS server. The idea is that the attacker sends a small bogus DNS query on UDP port 53 with a bogus IP address. Your server then sends a much larger response to that IP address, greatly multiplying the amount of traffic that the attacker can direct at the target site. This occurs via UDP since that makes it easy to spoof the source address.


Assuming you use Bind, can edit your named.conf file, only wish to provide recursive DNS services (ie. handle queries for domains that you are not authoritative for) to a known range of IP addresses, and the query is for a domain that you're not authoritative for, you can solve the problem by adding something like this to named.conf:

options {
   allow-recursion { 127.0.0.1/32; };
};

That particular setting would cause Bind to ignore recursive queries from all IP addresses except 127.0.0.1 (localhost). My DNS server only provides recursive queries for itself, so the setting was easy for me. After I started blocking recursive queries, it took a week or so for the bogus traffic to stop. But in the mean time, since I wasn't sending responses, the amount of my bandwidth that was wasted decreased dramatically.

<Prev in Thread] Current Thread [Next in Thread>