In case you haven’t been paying attention Botnet DDoS attacks passed the 40 Gigabits/sec mark in 2008 according to Arbor Networks. The shear size of today’s Botnets has reached into the mind-boggling realm of 1.9 million bots in a single Botnet. Couple that with the fact that Botnet DDoS attacks are one of the hardest assaults to defend against and you have a real nightmare scenario on your hands. This is why DDoS attacks are the most common method employed by extortionists to attempt to hold online merchants hostage for ransom. It's big business for criminals and business is good.
Here is a common scenario: bad guy employs a Botnet army to saturate and take out of service something that is of value to you. The targets range from just a DDoS to saturate one critical server to saturating your entire connection to the Internet effectively taking down all your Internet service. In some cases the bad guy will launch his attack first, take down the web services, and then ask for the ransom money. Other times the bad guy will just send in the ransom request with the threat that if it is not met by x days they will take their website down.
Of course none of this is new to you right. But have you ever thought about what you and your company would do if you got hit (or hit again) with a Botnet DDoS attack? How prepared are you to defend against this type of attack? Many companies (both large and small) deal with the issue by explaining it away with arguments like, “we don’t have anything a hacker would want” or “we are to small of a target to be worth the trouble”. In some cases this turns out to be fairly true, the risk of a DDoS attack is just not worth the security investment. But in many cases this line of thinking is dangerously wrong and the risk is actually higher than perceived. If I think about it from a bad guy perspective, I’m looking for one of two things, money or fame. If you can provide either or both of those then you are a target of opportunity.
So, let’s get down to it. How can you fight off a Botnet DDoS attack? Well, the answer varies depending on the type of DDoS attack you are having, your network infrastructure, security tools you have available, and other variables. Even though there are so many variables to how you defend against DDoS in your particular environment, I still think there is value is highlighting a few of the more popular tactics. Here are some tips that I have seen work with some success in the past. Others are brand new techniques to me but seem to offer up a compelling solution. I’ve list these defense tips in no particular order. But feel free to let us know what you think the order of effectiveness should be.
DDoS Prevention Offerings from your ISP or DDoS service
This defensive tactic is usually the most effect of the bunch and of course (typically) the most expensive as well. Many ISPs offer some form of in the cloud DDoS protection for you Internet links. The idea is that the ISPs will scrub/clean your traffic before allowing it onto your Internet pipe. Since this defense is done in the cloud your Internet links don’t become saturated by a DDoS attack. At least that’s the goal anyway. Again no silver bullet. This service is also offered by 3rd party in the cloud DDoS prevention services. They work by redirecting your traffic to them during a DDoS attack. They clean it and send it back to you. This all happens in the cloud so your Internet pipes don’t become overwhelmed. A few examples of ISP that offer DDoS services are AT&T's Internet Protect and Verizon Business's DoS Defense Mitigation.
RFC3704 Filtering
Basic ACL filters. The main premise of RFC3704 is that packets should be sourced from valid, allocated address space, consistent with the topology and space allocation. To this end there is a list of all unused or reserved IP addresses, those you should never see coming in from the Internet. If you do see them then it is positively a spoofed source IP and should be dropped. The name of this list is the bogon list You should check with your ISP to see if they will manage this filtering for you in the cloud before the bogus traffic enters (and fills) you Internet link. A bogon list changes pretty frequently, about once a month, so if the ISP won’t do it for you then you’ll have to manage your own bogon ACL rules (or find another ISP). This updating could be scripted as well.
Jamey Heary, CCIE No. 7680, is the author of the Cisco NAC Appliance: Enforcing Host Security with Clean Access book by Cisco Press. Jamey is a seasoned security technologist with over 15 years in the IT field with 10 years focused on IT security. His areas of expertise include network and host security design and implementation, security regulatory compliance, and routing and switching. His other certifications include CISSP, CCSP, and Microsoft MCSE. He is also a Certified HIPAA Security Professional. Jamey is currently a Security Consulting Systems Engineer with Cisco, though the opinions expressed here are his own. Jamey is a member of Network World's Cisco Subnet blog community.
great article
Great article. Thinking that because my business is not too popular is the worst thing that you can do to damage your business continuity plan. Do you know that from the underground market (like RBN) you can buy a botnet C&C with a pretty simple to use web interface for 2 days , under 400 USD (also with 24 hours tech support) ? just enter the ip address of the victim and then blown up their whole internet connectivity. very small garbage packets from infected hosts distributed from US to Uganda that can overvelmed even 100Mbps bandwidth.
It think today DDOS attack can only mitigated from upstream service provider but as Jamey noted the other steps can be useful in some case.i just want to add a few resource to this great article that maybe can help.
1- Unused IP Address space that maintained by IANA and constantly updated:
http://www.iana.org/assignments/ipv4-address-space/
(look at the Status as UNALLOCATED )
2- Drop malicious traffic from bad reputation IP address , include C&C , RBN , … :
http://www.emergingthreats.net/fwrules/
this provide IP packet filter for Linux-Netfilter , Cisco PIX/ASA and IPF
3- Use Still valuable ACL on your Internet Edge to Drop risky services and protocols. for example most (to the modern one) C&C use IRC to communicate with Agents. drop the connections to/from that ports can help (not really stop DDOS attack , but can prevent your internal infected hosts from participating in Botnet )
deny tcp any any range 6660 6669
deny tcp any range 6660 6669 any
you will find interesting new Cisco Techwise TV that talk about new strategy regarding to the increasing threat of Botnet.
http://www.cisco.com/en/US/solutions/ns340/ns339/ns638/ns914/html_TWTV/twtv_episode_45.html
nice additions
Thanks Ali for the great reference additions.
-jamey
Another useful resouece
i forget it in the last post.this is a great site regarding the current topic.
http://www.team-cymru.org/Services/Bogons/
Who Pays the Ransom?
According to an item on this site:
http://www.asiacxo.com/pastissue/article.asp?art=26061&issue=154, "...two years ago...hackers targeted dozens of major international sports betting firms...timing their attacks to coincide with lucrative sporting events...the culprits then demanded up to US$50,000 to stop further sabotage."
According to this article, "Some are believed to have given into the criminals’ demands until, eventually, investigators traced the attack back to Russia and arrests were made."
And I guess that's my question. How is the payment of a "ransom" accomplished in such a way that the recipients can't be tracked. Sometime, somewhere, real money has to change hands. And when that happens, it is possible to catch the culprits.
But the overall impression I'm getting is that almost no one pays any ransom. DDoS attacks are troublesome, but as the article notes, there are ways to work around them.
But it's like spam--email to your accounts may be filtered, and your users may never see the junk, but it's out there, slowing everything down.
money laundering
Thanks for the comments and info.
here is a site that talks about some money laundering methods
http://money.howstuffworks.com/money-laundering1.htm
-Jamey
uRPF
I have found that IP Source Guard requires a fair amount of maintenance and tuning. A simpler solution is to use uRPF on edge VLAN interfaces. This isn't quite as complete as IPSG since a host can still spoof another IP address in its own subnet, but it stops the majority of spoofing problems.
Reference:
http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html
absolutely
uRPF can be a powerful tool to limit IP spoofing internally.
If you have a need to enforce DHCP addresses on clients and prohibit static address assignments on clients then IP source guard can do that as well.
-Jamey
Great inputs
We are a leading webhosting company in the US. We found that the Cisco solution is too expensive for most of us. IntruGuard has a product range that we use for providing a DDoS scrubbing solution to our customers. IntruGuard appliances provide the capability to clean packets to and from bogon addresses, hardware based SYN proxy, connection limiting, botnet flood mitigation etc. I've used other products for DDoS mitigation with much nicer management, and reporting tools, but none of those products have come close to the actual detection and mitigation capabilities built into this product.
Rule #1 Use the right equipment Juniper!
If you appreciate sleep and hair.
See the following link for full thread:
https://puck.nether.net/pipermail/juniper-nsp/2009-February/012591.html
"After doing further investigation, I found that in-fact my Cisco-vxr
Npe-g2 and g1 in the path (between M7i and customer router) suffered
the Dos and due to cpu saturation the bgp flapped. Earlier I did not
noticed because the cpu utilization graph of Cisco showed only 50% in
npe-g2 and 80% in npe-g1 and straightened perhaps it was not responding
mrtg polling, however "show proc cpu history" showed the different
story.
M7i was not affected...bravo Juniper..!
Thanks everyone.
Regards,
Samit"
This is a fairytale story
This is a fairytale story from a Juniper fanboy. There must be an explanation for this behavior. The Cisco routers were probably misconfigured, control plane policing wasn't enabled on a software processed router, etc. Cisco is the #1 networking company for a reason so the engineer didn't know what he was doing.
Post new comment