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 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 Mar 4th 2011 |
Thread locked Subscribe |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
(D)DoS makes a handy diversion, if you're looking to do other things.
|
Sam 3 Posts |
Quote |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
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 |
Quote |
Mar 4th 2011 1 decade ago |
@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 |
Quote |
Mar 4th 2011 1 decade ago |
@MarkH, what would be some "baseline" mitigation measures that an ISP "should" be able to take in response to a DDoS?
|
Mark 2 Posts |
Quote |
Mar 5th 2011 1 decade ago |
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 |
Quote |
Mar 5th 2011 1 decade ago |
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 |
Quote |
Mar 5th 2011 1 decade ago |
@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 |
Quote |
Mar 7th 2011 1 decade ago |
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 317 Posts ISC Handler |
Quote |
Mar 7th 2011 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!