Tips on Responding to DDoS Incidents (Updated)
The incident handling cheat sheets in an earlier diary applied to many types of security incidents. Some situations, such as distributed denial-of-service (DDoS) attacks, benefit from specialized guidelines. After soliciting tips from our readers and fellow ISC handlers, I compiled the following cheat sheet to help organizations during a DDoS attack.
The cheat sheet captures advice for battling a network DDoS attack on your infrastructure. The link points to the HTML version of the cheat sheet. That page includes the printable 1-page PDF version, and the Word version of the file you can customize for your needs.
What do you think? Any corrections or additions? Pointers to useful resources? Let us know.
Thanks for the insights to our readers and ISC handlers, including: Daniel Fairchild, Chris Lemieux, Peter McLaughlin, Jose Nazario, Donald Smith, and Jim Tuttle.
Additional feedback from our readers:
Adam Jarvela wrote: "From the datacenter perspective it's important to identify the specific destination of the attack... . I'm a fan of the old method of starting at the core and following the traffic to the aggregate and eventually to the distributor. From the distributor it's usually pretty easy to identify the destination of the attack..." "Recently, we had a very odd attack on ip protocol 255. Not the first time we've seen this, but by being able to identify the specific attack you can create an attack specific filter instead of blackholing the entire server/IP/subnet..."
Andrew wrote a shell script that, when ran on the DDoS'ed Linux web server "would terminate connections exceeding a set value (10 in this example) from the same source IP. Although not ideal, however does hopefully prevent the web server from falling over (exceeding sockets thresholds) whilst one is assessing the DDoS situation." Here's Andrew's script:
#!/bin/sh
PATH=$PATH
while true; do
sleep 60
UNIQ=`netstat -tpn | grep -i established | awk '{print $5}' | cut -d':' -f1 | uniq`
for IP in $UNIQ; do
WC=`netstat -tpn | grep $IP | wc -l`
if [ ${WC} -gt "10" ]; then
PID=`netstat -tpn | grep $IP | awk '{print $7}' | cut -d'/' -f1 | sort -n`
KILL=`echo $PID | cut -d' ' -f10-`
kill -s 9 $KILL
logger -sp daemon.notice -t Web_Server "Established threshhold exceeded for IP ${IP} and PID ${KILL}"
fi
done
done
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
2 Cheat Sheets for Incident Handling
"People only see what they are prepared to see." -- Ralph Waldo Emerson
Maybe your system just got hacked. You don't know for sure yet, but you need to quickly qualify the potential incident. You also need to ask questions to make sense of the situation and determine how to proceed. It's easy to make mistakes in the heat of the moment; it's hard to find time to prepare in advance. Here are two cheat sheets that may help.
In each case, I link to the HTML version cheat sheet. That page includes the printable 1-page PDF version, and the Word version of the file you can edit for your needs.
Security Incident Survey Cheat Sheet for Server Administrators
This cheat sheet captures tips for examining a suspect server to decide whether to escalate for formal incident response. Its steps attempt to minimize the adverse effect that the initial survey will have on the system, to decrease the likelihood that the attacker's footprints will be inadvertently erased.
Initial Security Incident Questionnaire for Responders
This cheat sheet lists the questions the incident handler should consider asking when taking control of a qualified incident. It's too easy to forget an important question when trying to think on your feet.
How Else to Make Incident Response Less Stressful?
Thanks to everyone who already offered feedback on these cheat sheets. If you have suggestions for improving them, please let us know.
For additional tips on incident handling, see the summary of the suggestions we published in October. Yeah, I should have written this diary last month.
Update: ISC reader Tor Vigesdal shared the following tip for surveying a potentially compromised Windows server:
xcopy \\server\share$\*.* /S /L /H /D:mm-dd-yyyy | more
/L is "Displays files that would be copied."
/H is "Copies hidden and system files also."
"Use todays date to get a list of all files modified today. Run it remotely to avoid logging on to a system that doesn't feel right. If you proactively run the report daily you can compare with yesterday's file to identify file changes that are not 'normal'.
One could have hoped they allowed you to use %date% in the /D parameter, but that does not work for all of us. It fails if your regional date format is not identical to the US format."
Update: A related diary offers tips on responding to a DDoS incident.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
An Ad for DDoS Services - Network, Phone, Competition
The oldfashioned way to launch a network DDoS attack involved building one's own bot network that would flood the victim with unwanted traffic. However, the illicit marketplace for such services has matured, allowing a person to purchase DDoS services on demand, effectively renting a botnet for the event.
Here's one ad for such services. It's in Russian; the translation follows.
The ad scrolls through several messages, including:
"Will eliminate competition: high-quality, reliable, anonymous."
"Flooding of stationary and mobile phones."
"Pleasant prices: 24-hours start at $80. Regular clients receive significant discounts."
"Complete paralysis of your competitor/foe."
Perhaps the most interesting aspect of the advertised service is the offer to flood the victim's phones. We often think of network-based DDoS attacks, but phone-based DDoS could be as devastating. If the service can, indeed, target stationary (landline) phones, then we're not just talking about SMS-based floods. These would probably be actual phone calls, probably initiated using VoIP, maybe via stolen Skype accounts with dial-out credits. Anyone knows more about such phone attacks?
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
Are We Doomed?
In no particular order:
|
|
|
|
|
We Are Doomed
There is Hope Any suggestions for the lists above? We'd love to hear them. It's probably easier to come up with the items for the "Doomed" column, but consider what we can build upon to tip the scales in the defenders' favor.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny teaches a SANS course on analyzing malware.
Security Awareness Training is Boring
I love the directness of Marcum Ranum's perspective on security awareness training. "If it was going to work, it would have worked by now," he wrote. Indeed, whenever I perform social engineering testing, too many people willingly give up sensitive data, click on a link or launch that fateful attachment.
Maybe the problem with many security awareness programs is that they are borning. Come up with something unusual and personally-relevant to the attendies, and I bet the audience will remember your message. Below are some tips and a video clip.
Select a Different Format
Call your annual security awareness session a "Security Awareness Session," and you're guaranteed to hear sighs and excuses for not being able to attend. How about something in a less standard format? Thinking out loud here:
- Add a security "commerical" interruption to an unrelated meeting or a conference call.
- Create a challenge for people to report unsafe IT practices they observe. Without identifying the offenders, but with prizes.
- Sponsor a bagels and donuts breakfast with a 10-minute data security discussion.
- Create a drawing for a prize. The cost of entry is a tip on improving IT security.
Of course, the format will depend on your corporate culture, but the idea is to take a less ordinary approach to spreading your message.
Make the Message Personally-Relevant
People tend to care about their well-being more than the well-being of their company. To make your message heard, make it useful for your colleagues as individuals, be it in the context of phishing for email credentials, on-line financial fraud, or spyware. By helping them protect their personal data on-line, you will show them how to act when corporate IT assets are threatened.
Example: A Video Clip
How about peaking the employees interest in your program with a short video clip? I found a service called Animoto that will let you upload a bunch of photos, and automatically generate a nice-looking videos from them. (30-second videos are free.)
Here's an example I created using generic photos I found via EveryStockPhoto. For best results, use the photos specific to your company or industry. (For attribution purposes, here's the list of the Creative Commons images I used from Flickr: 1, 2, 3, 4.)
My video clip attempts to entice the audience to sign up for a hypothetical security awareness session. Of course, you can also use a more specific video to spread your particular security awereness message.
For additional tips about security awareness training, see the summary of the diaries we published about a year ago on this topic.
Updates:
If you don't feel like making your own video, you can find some you can use on YouTube. For instance, Mike wrote in to point out the security awareness video "Duhs of Security" created by the Commonwealth of Virginia. It's available on YouTube and as part of an information security toolkit. I like that the video has goofy characters--they make it more fun. I would prefer if it were shorter, but longer videos are useful for some training forums.
Fellow ISC handler Andre Ludwig also pointed out a few fun security awarenes videos, available from Antispam.br. These are in Portuguese with English subtitles.
-- Lenny
Lenny Zeltser
Security Consulting - SAVVIS, Inc.
Lenny will be presenting at the SANS D.C. conference in December.
Comments