A very common action is to blackhole ddos traffic upstream by sending a
bgp route to the next AS with a preestablished community indicating the
traffic must be sent to Null0. The route may be very specific, in order
to impact as less as possible. This needs previous coordination between
providers.
Regards.
De: rdobbins@arbor.net
Fecha: 08/12/2010 10:53
Para: "North American Operators' Group"<nanog@nanog.org>
Asunto: Re: Over a decade of DDOS--any progress yet?
One big problem (IMHO) of DDoS is that sources (the host of
botnets) may be completely unaware that they are part of a DDoS. I do
not mean the bot machine, I mean the ISP connecting those.
The technology exists to detect and classify this attack traffic, and
is deployed in production networks today.
And of course, the legitimate owners of the botted hosts are
generally unaware that their machine is being used for nefarious
purposes.
In the other hand the target of a DDoS cannot do anything to stop
to attack besides adding more BW or contacting one by one the whole
path of providers to try to minimize the effect.
Actually, there're lots of things they can do.
I know that this has many security concerns, but would it be good
a signalling protocol between ISPs to inform the sources of a DDoS
attack in order to take semiautomatic actions to rate-limit the traffic
as close as the source? Of course that this is more complex that these
three or two lines, but I wonder if this has been considerer in the
past.
A less common action is to use flowspec (if you have some Juniper gear) to drop only the attack and hopefully not any legitimate traffic.
What is really missing atm is a way to filter flowspec announcements (limit the number and make sure they are for routes the peer is announcing). Until this is sorted I believe flowspec will be a marginal solution.
But my point is still valid, Flowspec is great if you are are a backbone and are performing the filtering, or if you want to filter outgoing traffic. If you are a smaller network, you need the filtering to be performed by your transit provider, as your uplink will otherwise be congested. So I will stand by my comment that flowspec would see a bigger uptake if T1 could accept the flowspec routes, which they will only do once they can filter them (to insure correctness and resource protection).
Actually, most DDoS attacks aren't link-flooding attacks - this hasn't been true for the last ~7 years or so.
I'm not saying it doesn't happen, because it does, and sometimes quite spectacularly - but in most cases, the attackers don't have to flood the link to achieve their desired goal.
I think the difference here is scale. packet-flooding attacks often do
fill links; if the links drop to 155mb/s or below. I've seen some gig+ DOS, but that is less common. The DOS I posted a flow capture link for wasn't that large, but enough to flood out the little DS3 going to the small town where the target DSL customers was.
This has been our recent experience as well. There are some pure app
attacks, to be sure, but we many blended attacks also. Bandwidth
(UDP/ICMP/SYN Flood) attack to distract with a app attack (GET/PUSH
floods) attempting to run underneath the radar. We regularly see SYN
floods these days > 20 Gb/s.
The thing to bear in mind is that app attacks *are* difficult to detect
as they are low bandwidth and make a full TCP connection. As a result
many IDS/Firewalls etc regularly miss these attacks.
Lastly there is usually always someone at the other end of these attacks
watching what is working and what is not. If the attack doesn't work
they will simply round up more bots to increase the attack bandwidth or
change the attack vector.
That may well be true. I'm an eyeball network and I can usually point at a user pissing someone off on IRC/Forums for DOS instigating. I probably deal with 1 large scale attack per year at most, though most likely my attacks are from smaller botnet owners.
I'm not saying that link-flooding attacks don't happen; they certainly do, and on very big links, sometimes.
But in the scheme of things, they don't happen nearly as often as they used to, as the attackers simply don't need to fill the links in order to accomplish their goals, in most cases.
It's also important to note that a lot of DDoS isn't directly perpetrated by those who wish the DDoS performed, but rather is hired out to botmasters who're paid to execute the attacks. Even if the person who is the motivating force behind the attack is paying in stolen credit cards or whatever, he doesn't want to pay for more than is needed to accomplish his goal.
I see a link-filling attacks with some regularity; but again, what I'm saying is simply that they aren't as prevalent as they used to be, because the attackers don't *need* to fill links in order to achieve their goals, in many cases.
That being said, high-bandwidth DNS reflection/amplification attacks tip the scales, every time.
Lastly there is usually always someone at the other end of these attacks watching what is working and what is not
This is a very important point - determined attackers will observe and react in order to try and defeat successful countermeasures, so the defenders must watch for shifting attack vectors.
I would say that > 99% of the attacks that we see are 'link fillers' with < 1% being an application attack.
thanks,
-Drew
This has been our recent experience as well. There are some pure app
attacks, to be sure, but we many blended attacks also. Bandwidth
(UDP/ICMP/SYN Flood) attack to distract with a app attack (GET/PUSH
floods) attempting to run underneath the radar. We regularly see SYN
floods these days > 20 Gb/s.
Another thing to be aware of--when you get hit with what seems to be
a "simple" flooding attack aimed at one point of your infrastructure...
start checking your logs at _other_ places in your network very, VERY
carefully.
There seems to be a trend of using larger-scale flooding, or other
simple types of attacks to get all the network people at an organization
rushing over to throw resources and energy at it...while the real target
of the attack is something completely different, on a different subnet, in
a different part of the company; and that attack is small, carefully focused
at its target, and is designed to be relatively quiet. The "big" attack is used
simply to ensure all the human energy is focused on the wrong place,
increasing the chance that what otherwise might caused raised eyebrows
and double-checking of logs/IDS alerts, etc. gets missed while everyone
is focusing on the"big" attack.
The thing to bear in mind is that app attacks *are* difficult to detect
as they are low bandwidth and make a full TCP connection. As a result
many IDS/Firewalls etc regularly miss these attacks.
Lastly there is usually always someone at the other end of these attacks
watching what is working and what is not. If the attack doesn't work
they will simply round up more bots to increase the attack bandwidth or
change the attack vector.
And, in what seems to be an increasing trend, what they are watching
for is *not* necessarily the result of the large botnet attack; they're checking
on the results of their targeted probes elsewhere in the network, or on the
outbound set of connections from a compromised machine within an
organization; after all, during a huge DDoS attack, with everyone focusing
on a set of uplinks being flooded with _inbound_ traffic, who is going to
notice the (relatively smaller) outbound spike of traffic as the compromised
machine sends out a copy of your internal intellectual property to the
miscreant recipients?
Matt
(speaking purely hypothetically, of course, and definitely not on behalf
of any institution or entity other than myself)
