Having researched this in-depth after reading a rather cursory article
on the topic (http://grc.com/dos/drdos.htm), only two main methods come
to my mind to protect against it.
By way of quick review, such an attack is carried out by forging the
source address of the target host and sending large quantities of
packets toward a high-bandwidth middleman or several such.
To my knowledge the network encompassing the target host is largely
unable to protect itself other than 'poisoning' the route to the host in
question. This succeeds in minimizing the impact of such an attack on
the network itself, but also acheives the end of removing the target
host from the Internet entirely. Additionally, if the targetted host is
a router, little if anything can be done to stop that network from going
down.
One method that comes to mind that can slow the incoming traffic in a
more distributed way is ECN (explicit congestion notification), but it
doesn't seem as though the implementation of ECN is a priority for many
small or large networks (correct me if I'm wrong on this point). If ECN
is a practical solution to an attack of this kind, what prevents its
implementation? Lack of awareness, or other?
Also, are there other methods of protecting a targetted network from
losing functionality during such an attack?
This type of DRDOS (Distributed Reflective Denial of Service Attack) is well commonly-known to both network operators, and as well as many script-kiddies.
By forging the source IP address of the attack to the victim's IP, and attacking internet backbone routers, this creates an immediate, devastating, yet very effective attack. Backbone routers, seeing this as legitimate packets simply reply back to the victim.
I guess the question is, what are the internet backbones doing these days to evade the outcome of reflected DoS attacks? Are they simply going to let their routers be the middleman to kick off innocent hosts?
SYN cookies and various other methods to control DoS attacks are only used by smart ISP's.. And considering most ISP's do not even care about egress filters, I don't believe any of these methods will work for quite some time to come.
Having researched this in-depth after reading a rather cursory article
on the topic (http://grc.com/dos/drdos.htm), only two main methods come
to my mind to protect against it.
By way of quick review, such an attack is carried out by forging the
source address of the target host and sending large quantities of
packets toward a high-bandwidth middleman or several such.
To my knowledge the network encompassing the target host is largely
unable to protect itself other than 'poisoning' the route to the host in
question. This succeeds in minimizing the impact of such an attack on
the network itself, but also acheives the end of removing the target
host from the Internet entirely. Additionally, if the targetted host is
a router, little if anything can be done to stop that network from going
down.
One method that comes to mind that can slow the incoming traffic in a
more distributed way is ECN (explicit congestion notification), but it
doesn't seem as though the implementation of ECN is a priority for many
small or large networks (correct me if I'm wrong on this point). If ECN
is a practical solution to an attack of this kind, what prevents its
implementation? Lack of awareness, or other?
Doesn't ECN depend on 'well behaved' traffic? In other words, wouldn't it
require the hosts sending traffic to slow down? So... even if the hosts
slowed down, 10,000 hosts still is a high traffic rate at the end point.
This type of DRDOS (Distributed Reflective Denial of Service Attack) is
well commonly-known to both network operators, and as well as many
script-kiddies.
By forging the source IP address of the attack to the victim's IP, and
attacking internet backbone routers, this creates an immediate,
devastating, yet very effective attack. Backbone routers, seeing this as
legitimate packets simply reply back to the victim.
I guess the question is, what are the internet backbones doing these
days to evade the outcome of reflected DoS attacks? Are they simply
going to let their routers be the middleman to kick off innocent hosts?
SYN cookies and various other methods to control DoS attacks are only
Because syn cookies are available on routing gear??? Either way syn
cookies are not going to keep the device from sending a 'syn-ack' to the
'originating host'.
Because syn cookies are available on routing gear??? Either way syn
cookies are not going to keep the device from sending a 'syn-ack' to the
'originating host'.
True… At least it will have some stop in the amount of attacks.
It is quite unfortunate that it is impossible to control the ‘ingress’ point of attack flow. Whenever there is a DoS attack, the only way to drop it is to null route it (the method you have devised) over BGP peering, but that knocks the victim host off the 'net…
] Because syn cookies are available on routing gear??? Either way syn
] cookies are not going to keep the device from sending a 'syn-ack' to the
] 'originating host'.
Agreed. SYN cookies also won't drain a pipe full of malevolent packets.
Any response the target is able to send during a TCP amplification
attack is a bonus prize, but is not required for the attack to succeed.
Sure, but this like all other attacks of this sort can be tracked... and
so the pain is over /quickly/ provided you can track it quickly Also,
sometimes null routes are ok.
Christopher L. Morrow wrote:
>
>
>>>
>>>
>>>Because syn cookies are available on routing gear??? Either way syn
>>>cookies are not going to keep the device from sending a 'syn-ack' to the
>>>'originating host'.
>>>
>>>
>>
>>True.. At least it will have some stop in the amount of attacks.
>>
>>It is quite unfortunate that it is impossible to control the 'ingress'
>>point of attack flow. Whenever there is a DoS attack, the only way to
>>drop it is to null route it (the method you have devised) over BGP
>>peering, but that knocks the victim host off the 'net...
>>
>
>
> Sure, but this like all other attacks of this sort can be tracked... and
> so the pain is over /quickly/ provided you can track it quickly Also,
> sometimes null routes are ok.
How quickly is quickly? Often times as has been my recent experience
(part of my motivation for posting this thread) the flood is over before
one can get a human being on the phone.
Once the call arrives and the problem is deduced it can be tracked in a
matter of minutes, like 6-10 at the fastest...
What kinds of mechanisms exist for keeping track of the origins of
something of this nature?
Normally that's not very productive as they are mostly owned boxes that
will be rebuilt and reowned in days
Doesn't ECN depend on 'well behaved' traffic? In other words, wouldn't it
require the hosts sending traffic to slow down? So... even if the hosts
slowed down, 10,000 hosts still is a high traffic rate at the end point.
Good point.
I suppose another basic but effective method of prevention would be egress filtering. An increasing minority of network providers are instituting it, but it doesn't seem like it will be a widespread thing in the near-term.
Normally that's not very productive as they are mostly owned boxes that
will be rebuilt and reowned in days :(
I agree, keeping track of the attacks would not be very useful nor helpful. I bet if more ISP’s would implement egress filtering on their border routers, it’d help quite a bit. Of course, egress filters don’t solve the issue. But considering most script kiddies’ intelligence level is limited, it will help at least a bit. The problem with egress filtering is that it’s mostly applicable at the end tier2+ level, not at the backbones, which means a lot of ISP’s who are oblivious on what it is (or some cases where egress filter breaks their network setup).
Yes, but *YOUR* crew has a reputation for having a clue. I'm willing to
bet that "once the call arrives" is a challenge for a lot of smaller ISPs
that don't even *HAVE* a security team, and "the problem is deduced" is
a challenge for the ones that have a team that don't have a clue.
We see a *LOT* of postings here "anybody know a clueful at XYZ, we've been
DDoS'ed for 36 hours"....
I suppose another basic but effective method of prevention would be egress filtering. An increasing minority of network providers are instituting it, but it doesn't seem like it will be a widespread thing in the near-term.
Yes, but egress filtering is only effective by far. Anyone can forge the source to an IP address that belongs to one of the /16's a provider advertises.
It will help of course, but really not The solution... Or is there one?
>
> > How quickly is quickly? Often times as has been my recent experience
> > (part of my motivation for posting this thread) the flood is over before
> > one can get a human being on the phone.
>
> Once the call arrives and the problem is deduced it can be tracked in a
> matter of minutes, like 6-10 at the fastest...
Yes, but *YOUR* crew has a reputation for having a clue. I'm willing to
We appreciate the kind words
bet that "once the call arrives" is a challenge for a lot of smaller ISPs
that don't even *HAVE* a security team, and "the problem is deduced" is
a challenge for the ones that have a team that don't have a clue.
This gets down to something I've harped on for a while now... if you drive
a car you must have a license and pass a test. If you run a network on the
internet you really should have 24/7 security clued person(s) available to
stop/track/mitigate security issues.
We see a *LOT* of postings here "anybody know a clueful at XYZ, we've been
DDoS'ed for 36 hours"....
Yup, and its a shame that that is the case Perhaps they should become
UUNET customers and then they can just call us? People move for cheap
bandwidth alot, I wonder how the value proposition works out when you are
down and paying SLA's to your customers due to a hosted dalnet server
getting attacked for 36 hours?
My previous experience with UUNET security team was excellent dealing with DoS.
I am not here to point fingers, but my DoS-response experience with various Tier-2/3 level ISP’s was like talking to some K-12 teacher who barely knows what internet is. It really takes hours to get thru and reach a competent engineer on the phone. And that’s the major frustration of a LOT customers getting DoSed/DDoSed/DrDoSed off the planet everyday.
>
>Normally that's not very productive as they are mostly owned boxes that
>will be rebuilt and reowned in days
>
I agree, keeping track of the attacks would not be very useful nor
helpful. I bet if more ISP's would implement egress filtering on their
border routers, it'd help quite a bit. Of course, egress filters don't
solve the issue. But considering most script kiddies' intelligence level
Egress filters are a distraction... today you don't have to spoof. These
are the red herring of 'security'.
THOUGH, all that said, having all networks, CUSTOMER NETWORKS, filtered as
close to end systems as possible would be a nice thing As Rob Thomas
points out 80% (or some huge number) of attacks are spoofed source
attacks. Every leaf network should be able to do the minimum urpf strict
on all ether or gig link... that way you don't even have to take the hit
of a acl to process the inbound traffic
This is most definitely best done as close to the end machines as possible
though, the traffic loads there are just much more managable... and it
reduces the possible spoofage to the lowest limit possible.
is limited, it will help at least a bit. The problem with egress
filtering is that it's mostly applicable at the end tier2+ level, not at
the backbones, which means a lot of ISP's who are oblivious on what it
is (or some cases where egress filter breaks their network setup).
Hmm, but the smaller the network the easier to filter it is... right?
Yup, and its a shame that that is the case :( Perhaps they should become
UUNET customers and then they can just call us? :) People move for cheap
bandwidth alot, I wonder how the value proposition works out when you are
down and paying SLA's to your customers due to a hosted dalnet server
getting attacked for 36 hours?
>
>
>>
>
> Good point.
>
> I suppose another basic but effective method of prevention would be
> egress filtering. An increasing minority of network providers are
> instituting it, but it doesn't seem like it will be a widespread thing
> in the near-term.
>
Yes, but egress filtering is only effective by far. Anyone can forge the
source to an IP address that belongs to one of the /16's a provider
advertises.
filter close to the end host, this limits (mostly) to the local /24 or /25
or /2(>5)...
It will help of course, but really not The solution... Or is there one?
haha, there isn't one since even with no spoofing you can muster an
army of 100,000 IIS servers still scanning for nimda
Of course, egress filters don't
solve the issue. But considering most script kiddies' intelligence
level
is limited, it will help at least a bit. The problem with egress
filtering is that it's mostly applicable at the end tier2+ level,
not at
the backbones, which means a lot of ISP's who are oblivious on what
it
is (or some cases where egress filter breaks their network setup).
On the subject of "help a bit", if service providers were to require,
by default, either an egress filter (correctly configured) on the CPE
router or an ingress filter on their own customer aggregation router
it might do some good ...
In this industry, anybody who advertises The Solution should automatically
be considered a snake oil salesman. There's no One Great Answer, because
there's more than one question. There's a LOT of things that would help:
Ingress filtering
Egress filtering
Clued incident response teams
Systems not shipped insecure by default.
etc etc etc. You've heard them all, I've said them all, they all address
parts of the problem. Nothing addresses all of it.
Ingress/egress filtering would help in some cases of a DDoS packet flood.
Ingress/egress filtering doesn't do squat when Nimda is on a burn.
Also,