DIY: Defending Against A DDoS Attack
Proactive self-defense can make DDoS attacks less painful and damaging
There's no way to prevent a distributed denial-of-service (DDoS) attack, but there are some do-it-yourself techniques and strategies for fighting back and minimizing its impact.
DDoS victims can "tarpit," or force the attacking bot to drastically scale back its payload, enlist the help of the botnet hunter community, or even get help to wrest control of the botnet. Joe Stewart, a researcher with SecureWorks' Counter Threat Unit, says these self-defense techniques are little known or used today by victims of DDoS attacks, but they offer an alternative to purchasing a commercial DDoS product or service and working with ISPs to try to stop an attack.
More Security Insights
- 10 Steps to Cleaning up Active Directory
- The Active Directory Management and Security You've Always Dreamed of
- Innovations in Integration: Achieving Holistic Rapid Detection and Response
- COBOL in the Big Data Era: A Guide
"You can't prevent someone from launching the attack, but you can do a better job at mitigating it through technical measures," Stewart says. Tarpitting doesn't work in every case, he says, but it's easy to deploy and doesn't cost anything.
"Just being able to respond better to these attacks is something that requires relationship-building with people who have pieces of the puzzle," such as the research community, he says.
Tarpitting works against HTTP-based attacks, which researchers say make up the majority of DDoS attacks today. HTTP-based DDoS attacks are often more effective than SYN flood DDoS attacks, and it's easier to max out the Web server's connections or CPU/memory than to overload the pipe with a SYN flood, experts say.
The tarpit method works with TCP/IP features embedded in Linux, namely the NetFilter feature, according to Stewart, and can be used with a Windows server with the help of a tarpit toolkit, such as LaBrea. Tarpitting basically forces the bot to send the victim's server less traffic. "You use it to say to the attacker, 'I'm so congested that you can't send me any more than 1 byte before I respond to you,' for instance," Stewart says. "The attacker gets in a loop trying to send 1 byte and waiting for a response [he] never gets."
And unless the botnet operator is closely monitoring his bots, he won't notice the slowdown. The only clue that the DDoS attack was foiled? Its target didn't go down as the attacker had expected, Stewart says.
Stewart says when he tested tarpitting against an attack bot, he found another interesting side effect of the defense method: One bot's CPU hit 100 percent, rendering the system unusable. "It almost reflected the DDoS attack back onto them. In their attempt to maintain all these connections and retries, it started using up all the CPU time on the system," Stewart says.
Jose Nazario, manager of security research for Arbor, says he sees few DDoS victims using these techniques today. "Unfortunately, it's pretty rare. It's valuable," he says. "The [tradeoff] is that it can have a negative impact on legitimate PC users [who are bot-infected]. After a while, they can't make any requests at all."
The safest defense against DDoS attacks is to recruit the help of researchers with expertise in botnets. Stewart recommends IT security teams get out and meet their peers and researchers and attend ISSA and InfraGuard meetings, for instance. They key is getting help in tracking down the offending botnet's command and control (C&C) servers, he says. "It could be something as simple as getting a hosting provider to take down a C&C by providing them proof that a host [using their service] was attacking you," he says.
And there are some researchers willing to venture into a grey legal area and actually go in and take over a botnet, he says. "Gaining unauthorized access to an infected computer is not something [SecureWorks] would do here," he says. "But there are some other researchers who've shown they are willing to take over botnets and issue them commands. If you're under attack, it's a kind of self-preservation."
Stewart says C&C servers are often vulnerable themselves to common Web attacks, like cross-site scripting and SQL injection. "They are usually sloppily programmed," he says. "And you can get a lot of knowledge from a SQL injection [vulnerability] in their script. But legally, this is probably not a good idea."
Meanwhile, some security experts like HD Moore have used more aggressive methods to fight a DDoS attack. Moore, creator of Metasploit, had a little fun at his DDOS attackers' expense earlier this year, turning the tables on the botnet that hammered away at Metasploit's servers. Moore changed DNSes in an attempt to evade the attackers, and also tried using Google Sites' Web hosting to mitigate the DDoS, but once Google Sites hit its page limits, he had to abort that tack.
He was able to eventually narrow down the C&C domains after enlisting the help of botnet researchers. The researchers black-holed one of the domains, and Moore then executed a "reverse" on the other two C&C domains, pointing the traffic that was flooding his Metasploit site back onto the attackers' domains so they were DDoS'ing themselves.
But these techniques are bit too technical and risky for most enterprises. SecureWorks' Stewart, who was one of the researchers who helped Moore find the culprit C&C domains, says it would be possible for an enterprise hit by a DDoS to follow Moore's lead by changing its IP address to that of the C&C's IP. "If the bots are attacking you by looking up your host name, you can change your IP address to the C&C IP once you learn where it is. This is easy, but causes [your site] to be down still, and causes your legit traffic to visit a botmaster-owned site -- a little scary if it comes back up before you change the DNS back," he says.
He says it's best to use legitimate abuse-reporting channels in the security community to help take down a botnet.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.