Threat Level: green Handler on Duty: Tom Webb

SANS ISC: DDOS, the new black? - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
DDOS, the new black?

In the last few weeks, maybe even months we've been seeing an increase in the number of Distributed Denial of Service (DDOS) attacks on different sites. Today, according to Ahnlabs in Korea, a number of government sites are under attack. Yesterday it was word press, and recently we also had sourceforge and no doubt a number of others that I've forgotten to mention. 

So is DDOS the new black?   We know that the majority of the malicious files and traffic we see are somehow related to making money, but realistically I can't quite see how this is doing the trick. How is money being made? Are the current attacks going to serve as examples? Give some money or else?  I don't know how effective that would be as most of the organisations seem to be dealing with the DDOS attacks relatively well.  

So why are we seeing these increases?  Are they being reported more?  Are they easier to do?  Are they test runs for something better later on, or maybe even nation states testing their processes.  Let us know if you've been under attack, recently.  I'd be interested to know how you dealt with it and if you have some packets you can share, even better.  If you know why you were targeted I'd be interested to know.  

Now for dealing with a DDOS attack. 

The best will be to stop the packets from reaching you in the first place.  To stop them as far away from your environment as possible, especially if link saturation is the problem.  This will likely need the cooperation of your ISP. You will find some are more willing to help you deal with an attack than others.  

If you manage to identify a particular characteristic of the packets being sent, then you might be able to get a firewall, router, IDS, or IPS to deal with the traffic.  These types of devices will be better at coping with this than your web or mail server.  Check you firewalls, many have the capability to drop traffic based on certain thresholds or characteristics and they may be enough to 

But lets put this in the context of an incident handling process. Hopefully you remember the six steps:

  • Preparation
  • Identification
  • Containment
  • Eradication
  • Recovery 
  • Lessons Learned

Preparation

This will be the most important step.  Firstly you will need to decide what you are going to do in the event of a DDOS attack on your infrastructure.  Will you pull the plug yourself and just ride it out? or will you take steps ab and c to deal with the attack. Best to sort this out before it happens rather than whilst it is happening. 

Make sure  you understand what your ISP will and won't do for you in the event of a DDOS attack on your sites.  

If you have an approach to deal with the DDOS, make sure it is documented.  Nothing worse than having to figure things out whilst the attack is underway. 

Have the capability to grab packets in place.  They will be invaluable.

Identification

How do you identify an attack?  Often it is because someone receives a phone call saying "xyz is very slow/unavailable".  You may have an IDS/IPS/Firewall throwing up alert. So that is how you notice. 

What to do next.  Well hopefully you have managed to capture some packets, or at a minimum log records. You will need to look at these and see if you can identify a common factor. 

Containment

Using the information discovered, you may be able to configure an upstream device to drop the malicious packets. Your ISP or a vendor may be able to help mitigate the attack and contain the damage done. 

You will likely also need to examine the targets to ensure they have not been compromised. l 

Eradication

If the targets have been compromised you will need to deal with those.  Your incident handling plan, developed in the preparation stage, should have enough information to allow you to deal with this new issue.

Often when the attack is not successful it will drop off, so I guess it is self eradicating. 

Recovery 

Once the attack is over, determine what else may need to cleaned, replaced, hardened.

Lessons Learned

Standard practice after any incident is the lessons learned.  Go through the attack, see where you went wrong and where you went right. Develop an approach to deal with 

 

I've made a start, if you can add to it let us know via the contact form or comments. 

Cheers 

Mark H.

Mark

391 Posts
ISC Handler
I think the money comes partly from selling DDoS attacks - somebody has a grievance against a company or site, and the big hacker networks will DDoS it for you if you can pay their asking price.
Lee

21 Posts
(D)DoS makes a handy diversion, if you're looking to do other things.
Sam

3 Posts
I understand perimeter defenses can get expense, but it amazes me how many networks allow the threat or attack to be taken directly to the server without any perimeter defense. It looks like a lot of budget Internet hosting providers do this.
Matt Guza

5 Posts
The most effective DDoS attacks we saw in 2010 are short-term high-rate UDP floods against infrastructure devices that fall over when handling conns/sec. By the time the upstream can mitigate for you the attack is over, which I think is odd.

In examining the traces after the fact, we saw that they would attempt to touch a different port every packet. I thought it rather clever.
Matt Guza
1 Posts
If it is a DDOS your ISP would have hardly any control to stop the attack which means that the only line of deffence are your perimeter security devices.If so what to learn from the "Lessons Learned Phase" Correct me if am wrong.

Reagrds:Haren
hcbhatt

14 Posts
Most ISPs have a LOT of control of their network and can in most cases filter the attack upstream. It requires a lot of work and therefore is a product they sell (ddos mitigation isn't cheap).
donald

206 Posts
ISC Handler
WHAT IF the DDOS was throwing thousands or millions of "GET" requests to your public webserver. There really is no work around as you have a public site. You cant change the port because its just a basic http request. Your DNS will point to your new port. Your website will be down. No other way around it. Not that I know of.
dec0der

7 Posts
All good comments thanks.
@dec0de HTTP in someways is easier, much more to identify and unless you have resources available that can browse the site simultaneously. If you are using a tool to generate the traffic there will be something specific that can be blocked. And for it to be effective it has to complete three way handshakes. That allows you to block parts of the internet you do not normally deal with.
Mark

391 Posts
ISC Handler
@Haren, Your ISP will have control as it must traverse their network. If it is server resource exhaustion then they may not care. But if it is bandwidth exhaustion, they likely will as it will impact their infrastructure as well.
As Don says though. DDOS mitigation by the ISP will cost, but if they say they can't do anything at all, well ....
Mark

391 Posts
ISC Handler
@MarkH, what would be some "baseline" mitigation measures that an ISP "should" be able to take in response to a DDoS?
Mark
2 Posts
Inserting stateful devices such as IDS/IPS/ and/or stateful firewalls into the network is in fact the worst possible thing one can do during a DDoS attack; the state-tables on even the largest stateful devices can be overwhelmed far more quickly than the naked servers themselves.

Network access policy should be enforced via stateless ACLs running in hardware-based routers/layer-3 switches which can handle millions of packets-per-second (mpps); source-based remotely-triggered blackholing (S/RTBH) via hardware-based routers/layer-3 switches can be a very effective reaction tool. Intelligent DDoS mitigation systems (IDMS) which are specifically designed to deal with DDoS attacks without carrying large amounts of state may also be helpful.

Here's a link to a .pdf presentation on the 2009 RoK/USA DDoS attacks which contains a good summary of best current practices (BCPs) for maintaining availability in the face of attack:

https://files.me.com/roland.dobbins/k54qkv

Here's a link to a .pdf NANOG presentation which also discussed the harmful aspects of inserting stateful devices in front of servers:

http://www.nanog.org/meetings/nanog48/presentations/Monday/Kaeo_FilterTrend_ISPSec_N48.pdf

Here's a link to the Arbor 2010 Worldwide Infrastructure Security Report, which notes that 49% of responding IDC operators have experienced an outage of stateful firewalls and/or 'IPS' devices during DDoS attacks:

http://www.arbornetworks.com/report

Also, the global operational security community has generally recognized this six-step methodology for handling security incidents:

1. Preparation.

2. Detection/Identification.

3. Classification.

4. Traceback.

5. Reaction/Mitigation.

6. Post Mortem.

Mark
2 Posts
Apparently, the commenting system is configured to post only an alias if one is specified, rather than one's full registration information. Apologies; it was me who made the previous post attributed only to 'null0', sorry for the unintentional obfuscation!
Mark
2 Posts
@Roland Dobbins:
Is there any documentation on the six-step IH methodology you just mentioned? Is this some kind of "standard" or just an overall recognized "best practice"? Thanks!
Mark
2 Posts
This is the methodology taught by SANS and this methodology or something similar is used by many in the security industry.

There used to be a book called Incident Handling Step by Step that laid it out, but I believe it is out of print. There is a good summary whitepaper at giac.org/resources/whitepaper/network/… and a number of good papers utilizing this methodology in the SANS Reading room at sans.org/reading_room/
Rick

290 Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!