I've promised my editors that for once, I would refrain from making admins suffer the earbug of the tune from that 1960's CBS show about passengers and crew shipwrecked on that other island, as well as summoning highly absorbent cartoon characters and their friends "under the sea" in order to prevent any potential copyright claims since SOPA seems to be on many minds right now along with plenty of drama afoot.
However, I have had strange dreams of uploading "Pirate Bay" links to senate.gov to see if they'd take their own site down.
I'm an old guy myself, and have actually paid for all of the music and videos I own. And I often question why, given what passes for "entertainment" these days. I was a partner in a security software business as well only to find that so many copies of our software had been pirated that our bandwidth costs for updating all the freeloaders exceeded our gross sales and that put us under. Thus I'm acutely aware of all the political issues involved, as well as the motivation for the counterattacks.
I also did my time as a network administrator for a state agency back in the days when Novell didn't know what to do with TCP/IP and so I had to add this newfangled thing called "Linux" alongside our Novell servers in our glass room so we could talk to milnet also. It got too comfortable, and securing it was pretty easy.
I got so bored in that glass room that I preferred to secure the REAL problem: our users. And so for the rest of my career, I focused on the "stupid" in the house and hired people to get trapped in the glass cage waiting for that inevitable halon dump to occur when a power supply in one of the boxes had its next meltdown.
For all those years, and all those vouchers to send off the server guys for Special High Intensity Training, I assumed that they actually paid attention in class. To my regret over the years, it seems as though we're no more secure than we were years ago and that frustration is what I often write about here. This time will be no different.
With DDOS attacks on a massive scale, and the crew gone over the side, I've decided to accidentally fall into the lifeboat along with the missing admins and since we're apparently trying to avoid the coast guard, I'll take this opportunity to break open that box of books and offer some of the training you guys and gals missed when you were on shore leave.
I'm going to provide a lot of links as well here, so plan on spending a good amount of time on the required reading that managers of all those "tango downs" should have done prior to the mass attacks on sites that should have had the capacity and expertise to have survived yesterday.
First, let's try to identify what we're up against. I'm not going to bother with definitions of DDOS attacks, everybody should know all about that by now after last year. We all know about the Lulzers and their "Low Orbit Ion Cannon" (LOIC) but that was just a toy.
Better yet, the author of LOIC built in a tattletale which allowed the authorities to hunt down those who used it. I lol'd when I first analyzed it in our lab. But that's not the only toy out there, and "Anonymous" has its hands on much better toys with anonymity features built in to hide their tracks in many cases.
Dealing with an attack originating from LOIC tools isn't all that difficult to handle. Iptables can be programmed with hashlimit, and MySQL can also be modified to knock down the attack as described here. ISC did a writeup about it back during the WikiLeaks attacks.
Since LOIC is "yesterday's news" though, the kids have come up with other tools more likely involved in the high power DDOS' we saw yesterday. These tools include last year's "improvements" known as Slowloris, which ties up servers with incomplete requests and then holds the incomplete connections open until the server saturates, and Keep-Dead DoS which abuses the "HEAD" request instead of get/post.
The "advantage" to these tools is that they attack the server rather than the router in effect causing it to eat up its CPU time and freeze.
But those tools were merely handmaids in waiting for what was apparently used in yesterday's attacks, a tool called "#Refref" (download removed, the author and "anonymous" are in a spat over the author now requiring a "donation" so the link to it is currently offline). A description of the tool was written up last September when it was released. THIS is the attack we're looking at now.
A decent article on how to prevent #Refref from overwhelming your SQL backend can be found here.
So ... what do we do? READ!
- How to protect Apache against DOS,DDOS or brute force attacks using mod_evasive and mod_security and mod_qos on Linux
Rules of mitigating DDOS attacks from my own experience of yore:
1. Delay the next request from a destination to the same server for a while.
2. Never let your SQL backend do much iteration from an outside request.
3. Make sure that your rules are up to date.
And if I've missed anything, please feel free to add to the comments. It's always better to FIX the problem than to whine about it.
As for me, back to my own job of protecting you guys from your users. I find it simply amazing that simple DDOS attacks are so effective. Somebody might want to walk back to that glass room and check to see if the inhabitants died in a halon dump that nobody noticed.
About the Author: Kevin McAleavey is the architect of the KNOS secure operating system ( http://www.knosproject.com ) in Albany, NY and has been in antimalware research and security product development since 1996.