Prevent DNS Cache DDoS

Note to lawyers, lobbies, music, film and entertainment companies, every ACTA, CISPA, SOPA and Intellectual Property defenders before freedom:

Every mention, accusation or potential offensive words direct or indirect have the word allegedly implied.

DDoS Attacks Against BIND DNS received

Introduction

 

    First of all, a little explanation of why I think I started to receive the attacks.

    For the very first time, I used The Pirate Bay to download a film contained in one of their torrents.

    Also, I have a small server inside my home network, which is accesible to outside but shares my home internet bandwidth.

    Right after finishing the torrent download, I started to receive massive DDoS DNS Cache attacks which were flooding my upload/download bandwidth as well as the BIND log (repace X with attacker IP I will make public later):

Jul 5 14:34:12 SkyNet named[2055]: client X#53: query (cache) 'ripe.net/ANY/IN' denied

Facts

 

1. I am running 5 years this personal server, and never received a massive DNS DDoS. Only received some SSH brute force login attempts which are successfull banned via fail2ban.
2. The intents to block The Pirate Bay: Successfull (UK, USA, Microsoft Messenger, etc), and some unsucessfull ones (Holland) and the effort to block the whole torrent service
3. ACTA rejected by European Parliament (where I live), making them fail.

Charges

 

    I don't believe in coincidences, but specially in these cases, where it would be too much coincidence, so I make my guess (accusation): Hollywood, and their friends are trying to stop/reduce torrent usage via other methods: Disturbing, attacking, and flooding torrent users, but of course from behind, by using botnets, infected small servers, etc without showing their faces.

Evidences

 

    Since I got fed up of this issue, I will post publicly IPs participating in this attack to let the world know who was causing this. In case of dynamic IPs, their user may not be responsible of the attacks, but I found some static IPs pertaining to servers which are direct responsibility to their owners:

IPs and hostnames participating in this DDoS event
IP/Hostname	IP/Hostname	IP/Hostname
202.1.207.129	173-212-220-30.static.hostnoc.net	50.87.103.112
31.222.72.2	aa.84.344a.static.theplanet.com	31.222.72.4
212.102.11.13	stats.msfayed.arvixevps.com	217.173.81.25
31.222.74.3	d4.67.354a.static.theplanet.com	31.222.66.3
174.37.201.154	mail.silverstructure.com	66.110.113.38
164.138.25.100	host.colocrossing.com	31.222.68.2
159.253.176.4	srv-s144.antiddos.eu	31.222.72.3
212.76.68.14	31.222.68.4	202.1.207.129
159.253.176.3	159.253.176.2	31.222.66.4
213.5.170.10	31.222.74.4	31.222.68.3
31.222.66.2		193.5.111.13

 

Protection

 

    This kind of attacks can be blocked by using and configuring fail2ban properly:

Currently, fail2ban have a issue flooding sendmail and preventing further actions when sendmail does not respond due to upload bandwidth consumption or some other cause.

This way, I made a simple sendmail-buffered.conf for fail2ban which will only send mails when X IPs are already banned.

Also, even with this enabled, fail2ban was unable to completelly stopping the attack, since it only blocked named default port (53), and somehow, some packets were still reaching me. So I modifyed default iptables-all.conf too.
To configure fail2ban properly, I created new rules and actions, based on current existing ones, but tuned to prevent this attack more efectivelly.

    Place those files inside fail2ban's action.d folder:

1. sendmail-buffered.conf
2. iptables-all.conf

    Once done that, just configure your jail.conf properly to use new rules.
For example:

[named-refused-tcp]


enabled = true
filter = named-refused
action = iptables-allports[name=Named, protocol=tcp]
  sendmail-buffered[name=Named, dest=YOU@YOURMAIL.com, sender=YOU@YOURMAIL.com]
logpath = /var/log/named/security.log
ignoreip = YOUR_LOCAL_NETWORK_ADDRESS_MASK

    Please note that, with these protections you will not stop the attack, since IP packets are still reaching your server, however, your upload bandwidth and your nameserver will be secured.