Some language and math that come in handy when you talk about or fight Distributed Denial of Service…

Distributed Denial of Service: an attack that uses a number of attacking nodes that overwhelm the target with network, web, or application traffic.  DDoS implies 100 or more nodes attacking the same target, although just about everybody has their own threshold for what consitutes “distributed”.

Command and Control (C2): how the attackers get instructions to the attacking nodes.  This could be automated in the case of a botnet (and probably what defines a botnet if you think about it too hard) or done manually as in the case of some booter scripts, or, as in the case of hacktivists, done with IRC, flyers, manifestos, and forums.  Different C2 has different strengths and weaknesses.

Node: a unique IP address that is participating in a DDoS. Not to be confused with node.js.  =)

Lethality: The lethality of a DDoS is a function of the number of attacking nodes times the average bandwidth per node with efficiency multipliers for how high in the technology stack that the attack goes (layer 3/4 versus 5-7) and if the nodes all attack at the same time (determined by the quality of the attacker’s command and control (C2) ).  It really is a brute force numbers game for the most part.

Average Bandwidth:

• Home users in US: 1-2 Mbps
• Home users in South America, Africa, South Asia: .5 Mbps
• Home users in South Korea, Japan: 5Mbps
• Virtual Private Server: 100Mbps
• Core Routers: 1000Mbps and up

Number of Nodes: divide the total bandwidth of attack traffic received by the average node bandwidth to determine how many attacking nodes there are.  So, for example, a hacktivist army attacking a site and bringing 2Gbps of attack traffic has around 2,000-4,000 participants.

Recruitment: how fast the attackers (botnet via malware, hacktivists, homebrew botnet, etc) can add nodes to the attack.  This could also be correlated with rates of infection for botnets consisting of home PC users, rates of exploits for servers, number of hacktivists joining in the campaign, etc.

Attrition: how fast the attackers lose nodes.  This could be due to ISPs blocking node access due to detection of attack traffic or bandwidth caps, hacktivists headed off to work during the week, the end of a significant campaign, or the general lack of interest in the attack.

Rate of Growth or Decay of an Attack: total size of attacking nodes plus recruitment minus attrition.

Cute Bot Couple photo by Jenn and Tony Bot

• DDoS Planning: Business Continuity with a Twist
• DDoS and Elections
• Keeping Up With the DDoS Kids
• My Month of Entertainment
• The Rise of the Slow Denial of Service

I’ve noticed a trend over the past 6 months: DDoS traffic associated with elections.  A quick sampling of news will show the following:

• http://www.opendemocracy.net/od-russia/irina-borogan-andrei-soldatov/kremlin-and-hackers-partners-in-crime <-Russia
• http://www.theregister.co.uk/2012/03/26/hong_kong_vote_hack/ <-Hong Kong
• http://www.theregister.co.uk/2011/12/07/korean_election_ddos_row/ <-Korea
• http://www.cbc.ca/news/politics/story/2012/03/27/pol-ndp-voting-disruption-deliberate.html <-Canada (rybolov: yikes!)
• http://www.csoonline.com/article/700523/ddos-attackers-target-russian-election-webcams <-Russia again

Last week it picked up again with the re-inauguration of Vladimir Putin.

• http://en.ria.ru/russia/20120506/173265737.html
• http://www.washingtonpost.com/world/europe/peaceful-protest-turns-violent-in-moscow/2012/05/06/gIQAFti35T_story.html
• http://english.ruvr.ru/2012_05_06/73954450/
• http://www.rferl.org/content/independent_russian_daily_hit_by_dos_attack_kommersant/24571463.html

And then yesterday, Ustream and their awesome response: which, in the Rybolov-paraphrased version read something like: “We shall go on to the end. We shall fight in France, we shall fight on the Interblagosphere, we shall fight with growing confidence and growing strength in our blocking capabilities, we shall defend our videostreams, whatever the cost may be. We shall fight on the routers, we shall fight on the load balancers, we shall fight in the applications and in the databases, we shall fight by building our own Russian subsite; we shall never surrender!!!!1111” (Ref)

Afghanistan Presidential Elections 2004 photo by rybolov.

So why all this political activity?  A couple of reasons that I can point to:

• Elections are a point-in-time.  It’s critical for one day.  Anything that has a short window of time is a good DDoS target.
• DDoS is easy to do.  Especially for the Russians.  Some of them already have big botnets they’re using for other things.
• Other DDoS campaigns.  Chaotic Actors (Anonymous and their offshoots and factions) have demonstrated that DDoS has at a minimum PR value and at the maximum financial and political value.
• Campaign sites are usually put up very quickly.  They don’t have much supporting infrastructure and full/paid/professional staffing.
• Elections are IRL Flash Mobs.  Traffic to a campaign site increases slowly at first then exponentially the closer you get to the day of the election.  This stresses what infrastructure is in place and design ideas that seemed good at the time but that don’t scale with the increased load.

So is this the future of political campaigns?  I definitely think it is.  Just like any other type of web traffic, as soon as somebody figures out how to use the technology for their benefit (information sharing => eCommerce => online banking => political fundraising), a generation later somebody else figures out how to deny that benefit.

How to combat election DDoS:

• Have a plan.  You know that the site is going to get flooded the week of the election.  Prepare accordingly.  *ahem* Expect them.
• Tune applications and do caching at the database, application, webserver, load balancer, content delivery network, etc.
• Throw out the dynamic site.  On election day, people just want to know a handful of things.  Put those on a static version of the site and switch to that.  Even if you have to publish by hand every 30 minutes, it’s better than taking a huge outage.
• Manage the non-web traffic.  SYN and UDP floods have been around for years and years and still work in some cases.  For these attacks, you need lots of bandwidth and something that does blocking: these point to a service provider that offers DDoS protection.

It’s going to be an interesting November.

• Keeping Up With the DDoS Kids
• DDoS Planning: Business Continuity with a Twist
• DojoCon DDoS Video
• The Rise of the Slow Denial of Service
• Apache Killer Effects on Target

Contrary to what you might hear this week in the trade press, FedRAMP is not fully unveiled although there was some much-awaited progress. There was a memo that came out from the administration (PDF caveat).  Basically what it does is lay down the authority and responsibility for the Program Management Office and set some timelines.  This is good, and we needed it a year and a half ago.

However, people need to stop talking about how FedRAMP has solved all their problems because the entire program isn’t here yet.  Until you have a process document and a catalog of controls to evaluate, you don’t know how the program is going to help or hinder you, so all the press about it is speculation.

• Reinventing FedRAMP
• NIST Cloud Conference Recap
• An Open Letter to NIST About SP 800-30
• The Guerilla CISO Rants: Don’t Write a System Security Plan
• Clouds, FISMA, and the Lawyers

So while I was at some conferences over the past couple of months, I had an awesome idea while sitting in a panel about data breaches, especially notification. While streaming conferences is pretty awesome for most content, I keep thinking that we need that as an industry we need the exact opposite: a track of the conference that is completely off-the-record.

Here in DC when we do smaller training sessions, we invoke the Chatham House Rule.  That is, the discussion is for non-attribution.  There are several reasons behind this:

• You don’t have to worry (too much, anyway) about vendors in attendance selling you something
• It won’t end up in the press
• It gets real information to people instead of things that are “fit for public consumption”

My local area has a hackers association (No linkie, if you have minimal skill you can find it) that meets to talk about mostly technical stuff and what folks are working on.  I find that more and more often when I do a talk there I do it “Off the Record” for a wide variety of reasons:

• I don’t want the attackers to get more effective
• I have half-baked ideas where I want/need feedback on if they are completely off-base
• The subject matter is in a legal gray-area and I’m not a lawyer
• I talk “on the record” all day every day about the same things
• I can “test-drive” presentation material to see how it works
• I can show nuts and bolts

So, the point of all this is that maybe we need to start having more frank discussions about what the bad guys are doing “in the wild” if we want to stop them, and that involves talking with peers from other companies inside the same industry to see what they are getting hit with.

Chatham House Rule photo by markhillary.

• Massively Scaled Security Solutions for Massively Scaled IT
• Metricon 5 Wrapup
• Civilians Ask “What’s With All the Privacy Act Kerfluffle?”
• Privacy Camp DC on June 20th
• Where is Rybolov?

Job announcement is here.  Share with anybody you think can do it.

• Radio Nigel
• Why You Should Care About Security and the Government
• Help the Government, Become Literate
• SP 800-53A Now Finally Final
• Wanted: Some SCAP Wranglers

Ah yes, you now know how I spend my Saturday mornings lately.

• DDoS Planning: Business Continuity with a Twist
• The Rise of the Slow Denial of Service
• Training the Apache Killers
• Oh to be a Program Manager
• A Little Story About a Tool Named #RefRef