Tag Archives: iptables and ddos

Protect your server from DDoS attacks – Part 2 !!

We have been talking about DDoS attacks directed at the web-server all this
while  ( http://letushare.com/protect-your-server-from-ddos-attacks )

Another headache would be when these attacks are directed at our DNS services,
which is often called as DNS Amplification Attacks.

In Simple words, the attack can be explained as follows :

Someone makes an enquiry to you, on how to reach a particular destination. You are not actually sure of the location either, so you ask your friends nearer to you, and if you don’t get an answer from them, you are determined to somehow get an answer and you start inquiring
further until you get one. ( Basically you do not know this ‘someone’ who requested your help)

And this ‘someone’ has not stopped there. He has asked this same question to
lots many other people whom like you are determined to get an answer. He would
conclude by saying, if you get an answer, please ring me to 111 – a fake number of
some unknown poor guy.

Similarly, an attacker spoofs IP addresses ( he might spoof it to an IP to which
he would like to carry a DDoS attack – called as the target – like the fake 111 number ) and sends a request to your DNS server asking to resolve a domain. Your DNS server would not have any details about it in your local db’s. So it goes around the internet trying to resolve the domain and as a result the request-queries and the reply-queries increase beyond a limit as the attacker sends more and more request queries.

Now, remember your server might be 1 in 10000 out of which the attacker would direct the reply’s to a target. ( If source IP of the DNS query was spoofed to that of the target’s IP )

So basically, this sort of DDoS attacks, not only affects the ‘target’ but also all the
DNS server’s participating in this attack, as they are flooded with queries ( request and reply )

Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. In most attacks of this type, the spoofed queries sent by the attacker are of the type, “ANY,” which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker is able to increase the amount of traffic being generated by these DNS services and in the end- the amount of traffic directed at the target would be huge.

So, how can we prevent this from happening ?

Going back to our previous illustration, when that ‘someone’ asked you for a help,
its you who sought to find an answer. You could have said :

“Im sorry, I dont know the route to that destination. Neither do i know you, so i cant spend
my time/energy in assisting you.

This is where you can make your DNS server a closed resolver.

More on this is found at the page, http://letushare.com/169/

And suppose, consider this, your DNS server is closed, still it would receive the
queries from the attacker and your server would have to reply to those DNS queries. Just that
it is not a part of the attack. These replies too might hinder your services if too
much requests are being directed to your server.

Here you can use iptables to set a rate-limit on the queries reaching your DNS port.

First make sure the recent module is loaded in the server
This module is needed to get this particular aspect of iptables working.

First rule is set to move all the packets received in port 53 to a new chain


# iptables -N block ( create a new chain )
# iptables -A INPUT -p udp --dport 53 -j block

Then,

# iptables -A block -m recent --set --name DNSQF --rsource ( creating a db DNSQF to capture the packets )

# iptables -A block -m recent --update --seconds 5 --hitcount 15 --name DNSQF

--rsource -j DROP ( set the rule for the db DNSQF which stores recent IPs )

The above rule implies to drop every packets after the 15th one, in a time-frame of 5 seconds.

Availing these rules in iptables, can in way help to reduce the traffic in your server,
when DNS queries are made to your server, even when it is a closed resolver.