The Register uses cookies. Find out more.

IT Pro confession: How I helped in the BIGGEST DDoS OF ALL TIME

Oh Trevor, how could you? Like this

Nuts and bolts time

This file redirects any attempts to contact "bad" domains to a honeypot server I maintain. Here users will get a website warning informing them that something nasty could have happened and I trap information on who, when, when, where and why.

; This zone will redirect all requests back to the blackhole itself.
$TTL 86400; one day
@ IN SOA (
28800 ; refresh 8 hours
7200 ; retry 2 hours
864000 ; expire 10 days
86400 ) ; min ttl 1 day

This is a script that I run every night at midnight. It checks to see if the malwaredomains list is newer than the one I already have and then downloads it. It then restarts BIND.

cd /etc/namedb
wget - N
/etc/init.d/named restart

This is my DNS configuration file.

options {
directory "/etc";
pid-file "/var/run/named/";
check-names master ignore;
check-names slave ignore;

zone "." {
type hint;
file "/etc/db.cache";

include "/etc/namedb/spywaredomains.zones";

The solution

I knew about recursion attacks; I even went so far as to set up countermeasures. Should DNS traffic for any reason exceed 1Mbit then the scrubber server was to e-mail me at once and lock all DNS traffic down to 500Kbit. The alarm went off late Tuesday night reporting DNS traffic of 10Mbit.

My mistake stems from the simple assumption that BIND disables recursion by default. The change was made with BIND 9.4 way back in 2007. For reasons incomprehensible to me CentOS 5.9 (which my edge scrubber is currently running) is running BIND 9.3.6 which means that by default recursion requests are honoured.

The fix required is simple; after check-names slave ignore; but before }; I needed to insert allow-recursion { [MY SUBNET]/27; };. This instructs BIND to only honour recursion requests from servers inside my datacenter. Using allow-recursion ( would limit it to only that server. That's all there is to fixing that issue![1]

One little number

I have been working with CentOS 6 in my lab. Every new VM, every hardware install, everything has been CentOS 6 for so long that I forgot I even still have 5.x units in the field. I had gotten used to BIND whose version was somewhere north of 9.8. The edge scrubber, however, has been in place and doing yeoman's work since long before CentOS 6 came out.

I made an assumption during an application configuration that led to one of my servers being used as part of the largest denial of service attack the internet has ever seen. A service I rely upon – Spamhaus – was inconvenienced due to my negligence. I am incredibly, incredibly sorry; I hope that helping others avoid the same mistake will begin to atone for this administrative misdeed.

[1] The keen eye will notice two other flaws in my server design. The first is that BIND isn't chrooted. This is because the spywaredomains.zones file from malwaredomains isn't really designed with RedHat-based operating distros in mind. If you were to chroot bind you'd have to post-process the zone file to cope with the path differences. Since I'm not doing shared virtual hosting and use fail2ban. I figure I can probably get away without it.

The second is that DNSSEC isn't enabled. I deserve 50 lashes with a wet noodle for that; but I've been lazy and putting off the upgrade to CentOS 6 on this system which would enable that by default. ®

Sponsored: What does the next-generation data centre look like?