I am a developer, and I am trying to get an insight into what could I do to enable my application to withstand a DNS amplification kind of attacks. Would such prevention methods help against DOS type attacks as well? What are the industry best-practices, guidelines for detection, prevention, weathering of such attacks. Are there are any common pitfalls?
-
2Are you talking about being the target of the DoS or the cannon? Also, is your application accepting DNS requests and resolving them or does it simply use the DNS server that is part of the attack?– LadadadadaMar 12, 2012 at 19:45
-
1Yes, the question assumes that my app is being attacked. My app is simply using the DNS server being attacked/ being used for the attack.– PriyeshjMar 12, 2012 at 22:54
Add a comment
|
2 Answers
Detection
The goal of a reflected DNS attack is to send large volumes of network traffic at a host in order to cause legitimate traffic to be dropped. It is chosen when the attacker doesn't control enough bandwidth himself to exceed the target's bandwidth. It is largely irrelevant whether the target is running a DNS server or not as the damage is usually already done by the time the packets reach the server.
The first symptom you will see is that your server is unresponsive over the network. If you have an out-of-band connection (such as physically sitting at the keyboard in front of it or using an iLOM, ALOM, iDrac, whatever) the server will probably have a low load.
If you suspect a reflected DNS attack, you can use tcpdump to look for a large number of DNS responses arriving that you didn't ask for. Keeping track of requests and responses can be difficult but if you aren't making any requests, then all the responses are part of the attack.
tcpdump -A -n dst port 53 and not host <local IP address>
The -n option is important here because it tells tcpdump not to do DNS lookups, which under this kind of attack will time out. The <local IP address> should obviously be replaced with your outbound IP address.
Survival
If you are actually running a name server, source port randomisation may help reduce the load these bogus responses cause. Dan Kaminsky headed up a collaboration a few years ago that made this a standard part of every modern name server.
Some stateful firewalls can track UDP "sessions". Configuring your firewall to drop anything inbound on port 53 that's not part of an established session could stop the bogus responses from reaching a valid service on your machine, meaning that the packets would not have to be processed. A DROP rule is better than a REJECT rule here because a REJECT rule actually sends an ICMP response to the name server sending you the bogus DNS response (which uses up more bandwidth) whereas the DROP rule just stops everything right there and doesn't waste any extra bandwidth.
Still assuming you are running a name server, make sure caching is turned on and working. (Actually, do this now anyway. The upstream servers will thank you.)
Unfortunately, these three things are pretty much a drop in the ocean if your hosting provider's bandwidth has been exhausted, which is often the case.
The two most successful strategies for surviving a bandwidth-based DoS are
- Having more bandwidth than the attacker.
- Hiring someone who does.
If the bottleneck is within your hosting provder's network, they may be able to filter the traffic further out as long as you can give them something concrete and precise such as "drop all inbound UDP packets with destination port 53".
If it's outside or at the edge of their network or if they just can't filter that much traffic, the next step is a company that specialises in mitigating DoS attacks. There are numerous choices these days and I can't really recommend any of them without personal experience. There's a quick list over on ServerFault. The general consensus is that they're expensive but often less so than the downtime or the extortion request that immediately follows the attack.
Something also to be wary of if you do come under attack, I have heard reports that sometimes the DoS is simply a diversion before/after/while the attackers sneak in and steal the data.
answered Mar 12, 2012 at 23:47
-
Great answer! Small nitpicks on a few secondary points: Source port randomization doesn't help stop DNS amplification attacks. Also, usually the purpose of a DNS amplification attack is to send more traffic than your pipe to the Internet can sustain. Setting a firewall policy to drop those packets once they arrive at your site is too little, too late: the packets have already gone through your pipe and congested it. I think you've nailed it when you say "these three things are a drop in the ocean". If it were me I'd probably drop the 3 preceeding paragraphs as irrelevant most of the time.– D.W.Aug 21, 2012 at 6:49
Take a little amount of time and visit this site: http://bindguard.activezone.de
This tool was developed to discard DNS attacks to your named (BIND). More information can you get on the page above. No firewall rules are needed.
(disclosure - I am affiliated with bindguard)
