Protect dns server from ddos

DNS Servers are difficult to mitigate. Mostly because they use UDP. Most services ( http, https, email, ssh ) rely on TCP. TCP uses a three way handshake this means that every communication has to follow a certain procedure. This allows us to filter out fragments or faulty handshakes.

800px-Three-way-handshake-exampleUDP in contrast  you can image it better as a flood of packets. When data is sent using udp, it is seperated into several packages which are simply sent, they find their own route through the internet and arrive at the destination. Whereas with TCP it starts at the beginning of the file and reads and sends part after part, UDP packets from the beginning of the file can arrive later then parts from the end of the file.

 

1.) Find out a way to mitigate high volume attacks.

We at https://internetz.me have a Firewall located on the router’s edge.

network_core_switch_server

We can allow every client up to 20 stateless firewall configurations per ip.  In the above example you can see how our old network was designed ( simply put of course there is more redundancy ). But you can see this shows France and at the bottom of the image you can see all countries that are france’s neighbours – so if there is an ddos, the traffic must go through these countries first. Then it hits the core routers of the datacentre. With our current infrastructure we can handle almost 500GBit/s of ddos traffic.

So at the core router’s is where the magic is happening and let me explain you why it is so important to have the attack traffic blocked there. The core routers are big routers, they can forward a lot of traffic – in this example its 80GBit/s. The switches behind them can handle up to 10GBit/s and the servers have 1Gbit/s NICs. For an attacker to harm  the system a flood of 1GBit/s would be enough to clock up the switchport of a server. If we now block the malicious traffic on the router’s edge it doesn’t evne enter the datacentre and our services will remain up and running. Of course this blocking needs to be done on every “door” of the datacentre, basically any where data comes in.

 

2.) The more silent you become the more you are able to hear.

Some of you may know this quote from backtrack. But it is true you can find the needle easier if your haystack is smaller. To demonstrate this i took a look at a default cpanel servers, which are not known to be lightweight and small but a bit more clumsy then a simple bind configuration – but since its easy to setup – people will continue to use it. So how do we start? With a simple portscan to see what we see thats running on this box. For the scope of this tutorial the dns server will have the public ip 1.1.1.1

Code:
sudo nmap -sS -v -Pn 1.1.1.1

PORT     STATE  SERVICE
21/tcp   closed ftp
22/tcp   open   ssh
25/tcp   open   smtp
26/tcp   closed rsftp
53/tcp   open   domain
80/tcp   closed http
110/tcp  closed pop3
143/tcp  closed imap
443/tcp  closed https
465/tcp  open   smtps
993/tcp  closed imaps
995/tcp  closed pop3s
3306/tcp open   mysql
8080/tcp closed http-proxy

Now we install some kind of firewall. The most easy to use client would be “ufw” or you could use “csf/lfd” which also includes a daemon that monitors certain directories and informs you via email. Or you use bastille firewall which integrates nicely with ispconfig. This should become a dns server, so all we should see is port 53 from the outside. You now may say “but i need ssh” then i say “yes sure you do”, but not on port 22 – go inside your /etc/ssh/sshd_config and change the port to a high value. Nmap and other portscanners also dont manually check every port they only check well known ports. so your are better of setting your ssh port to somewhere between 10000 and 65000. Remember the max value for your ports is 2^8.

 

3.) Start reading your logs

Now that we have blocked high volume traffic and made only port 53 available to the public – this will be the most likely point of attack. Now it is VITAL to understand your dns server, know where the log files are and are prepared

A few weeks ago i published an article with a simple bash script . In case of a ddos attack, or a certain amount of packets on your interface, the script will start a tcpdump, sort the data and sent it to you via email.

You then already know the type of attack, and roughly the volume which allows you to start ways of mitigating the attack.

 

4.) Block higher level attacks.

I already mentioned csf/lfd which acts as a firewall/watchdaemon duo and informs you, when attacks, portscans and such things occur. You can also use fail2ban which is another log reading daemon. Fail2ban looks for repeating events such as login bruteforce attacks and blocks users based on those events using iptables. Fail2ban can also be used effectively to block users that are abusing the dns servers. or ban attempts of dns reflection attacks.

 

5.) Get to know your Service

Figure our what dns servers are usually speaking to your dns server, whitelist those servers. I already told you in 3. and 4. thats its important to understand your setup, and to determine the type of ddos etc. This does not have to be a boring thing. I used logstalgia in combination with csf/lfd to generate videos from the logs of ddos attacks. And it generated some beautiful videos 🙂

 

One Response

  1. ddosed right now December 11, 2015

Leave a Reply

Your email address will not be published.

Powered by themekiller.com