Tips on Responding to DDoS Incidents (Updated)

Published: 2008-12-01
Last Updated: 2008-12-02 14:20:44 UTC
by Lenny Zeltser (Version: 5)
0 comment(s)

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.

DDoS Incident Cheat Sheet Preview

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:


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}"


-- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

0 comment(s)

2 Cheat Sheets for Incident Handling

Published: 2008-11-19
Last Updated: 2008-11-25 13:31:14 UTC
by Lenny Zeltser (Version: 3)
0 comment(s)

"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.

 Security Incident Survey Cheat Sheet - Preview

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.

Initial Security Incident Questionnaire - Preview

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.

0 comment(s)

An Ad for DDoS Services - Network, Phone, Competition

Published: 2008-11-19
Last Updated: 2008-11-20 03:57:24 UTC
by Lenny Zeltser (Version: 1)
1 comment(s)

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.

1 comment(s)

Are We Doomed?

Published: 2008-11-19
Last Updated: 2008-11-19 22:38:10 UTC
by Lenny Zeltser (Version: 4)
0 comment(s)

In no particular order:

We Are Doomed

There is Hope 

  1. Bot networks seem to be growing in size.
  2. Many web developers don't understand XSS, CSRF and SQL injection-type vulnerabilities.
  3. Anti-virus vendors are starting to send signature updates several times per hour.
  4. It takes a reboot to update Adobe Acrobat and updating VMware Workstation requires a 330MB download.
  5. Criminals are becoming more aggressive about protecting their enterpises via DDoS.
  6. Targeted attacks easily bypass organizations' defenses.
  7. DNS remains a weak link.
  8. Passwords suck.
  9. Wi-Fi is becoming more common, even though securing it remains a challenge.
  1. Prescriptive compliance requirements (e.g. PCI DSS) are making it harder to ignore IT security.
  2. Security technologies are becoming smarter (e.g., web application firewalls).
  3. Anti-virus vendors are paying more attention to behavioral protection and performance.
  4. The community's expertise in analyzing malware is becoming more sophisticated.
  5. Search engines are starting to warn users about potentially malicious sites.
  6. The law enforcement seems to be getting better at catching alleged cyber-criminals.
  7. It may be getting harder to host malicious sites on a large scale.
  8. Running out of steam here... Is the "Doomed" column winning?

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.

0 comment(s)

Security Awareness Training is Boring

Published: 2008-11-19
Last Updated: 2008-11-19 15:19:47 UTC
by Lenny Zeltser (Version: 2)
0 comment(s)

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.


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 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.

0 comment(s)


eweew<a href="">mashood</a>
dwqqqwqwq mashood
[ |]
What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission

Diary Archives