subject:"Effective ways to deal with DDoS attacks\?"



On Wed, 1 May 2002, Pete Kruckenberg wrote:

 There's been plenty of discussion about DDoS attacks, and my
 IDS system is darn good at identifying them. But what are
 effective methods for large service-provider networks (ie
 ones where a firewall at the front would not be possible) to
 deal with DDoS attacks?

I'm working on something that should provide a solution to this for at
least some subset of all attacks.

Basically, it works like this: when you identify the target of the attack,
you have traffic for those target addresses rerouted to a filter box.
This filter box then contains source address based filters to get rid of
the attacking traffic.

The idea is that a service provider could install one or more of those
filter boxes (standard routers or multilayer switches) and have customers
use standard BGP mechanisms to get the filter boxes to clean up the
traffic. This should work as long as the number of source addresses is
relatively limited, say below 20,000.

If anyone is interested in testing such a setup in a real network, contact
me off-list. My goal is to evaluate how well this works and then write up
an article for the benefit of the networking community.

Iljitsch van Beijnum

Re: Effective ways to deal with DDoS attacks?



On Thu, 2 May 2002, Avleen Vig wrote:

  Basically, it works like this: when you identify the target of the attack,
  you have traffic for those target addresses rerouted to a filter box.
  This filter box then contains source address based filters to get rid of
  the attacking traffic.

 Two questions:
   1) How do you plan on determining what an allowed src address and what
  isn't?

allowed?

   2) Secondly, how would you deal with spoofed src addresses where the src
  address is rarely repeated in the attack?

If that is the case, this solution won't help. Unfortunately, it is
impossilbe to prevent traffic with spoofed source addresses to come in
over transit connections. However, it is doable to make sure traffic
coming in from peers uses source addresses that belong to peers. So for
networks large enough to have a major part of their traffic coming in over
peering rather than transit, there are possibilities.

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread Jeff Workman





Stoned koalas drooled eucalyptus spit in awe as Christopher L. Morrow 
exclaimed:


 I use ebay as an example of course, I wouldn't want them harmed cause how
 would I be able to buy all that nice routing gear at bargain basement
 ^^^
Shouldn't this be s/I/WCOM/? :)

 prices without them? :)

I suspect that they'll be buying all the Cicso memory they can find on 
there now, to support the route boat they've introduced over the past two 
days.

WCOM 9:55am 2.425 +0.215 +9.73% 20,522,300

/me scrounges around in the couch cushions, looking for change to buy some 
WCOM.

-J

--
Jeff Workman | [EMAIL PROTECTED] | http://www.pimpworks.org

Re: Effective ways to deal with DDoS attacks?



On Wed, May 01, 2002 at 11:56:07PM -0600, Pete Kruckenberg wrote:
 
 On Thu, 2 May 2002, Richard A Steenbergen wrote:
 
  You have an interesting situation. I think rate limiting
  outbound RSTs would be the least offensive thing you
  could do, off the top of my head.
 
 What about just blocking out-going RSTs altogether from our borders?
 While this interferes with proper TCP functionality, would it actually
 interfere enough to cause noticeable problems? Would certainly be less
 of a burden on routers than rate-limiting.

If you really wanted to try you could probably get away with it, but 
you'll probably get complaints about broken behavior during peacetime.

I'd still advise a rate limit, say something on the order of 512Kbps or
less depending on your pipe, and outbound TCP RST. If this makes your
routers fall over, you need new routers.

-- 
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

RE: Effective ways to deal with DDoS attacks?



uRPF and Radware DoShield, one DoShield per link btw edge router and core
router.  Use IDS (yes there is a way to capture all your traffic and
anaylyze it, regardless of bandwidth, no it isn't one box) to identify a
signature, build a filter, config filter on DoShield, up to ~200Mb/s per
DoShield of filtering with zero impact to legit traffic.  Scale horizontally
(add more links each with a DoShield on it) based on your ingress traffic.

I've seen many suggestions on this list, this is the only thing that works
for huge (100Mb/s+) attacks.  eBay is likely the biggest target on the net,
this works for us 90% of the time.  Is the HW expensive?  Yes. (~$35k per
DoShield I think)  It works, it scales.  

There is no way a Cisco router can handle filtering attacks past a certain
point, nor is it capable of even filtering on some patterns in attack
packets.  Juniper is better, but still lacks some filtering capabilities.
Your router is a router, not a packet filter, give up trying to make it do
this until someone builds this into an ASIC on the router.

Email me off list for more info.

-Original Message-
From: Pete Kruckenberg [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 01, 2002 4:18 PM
To: [EMAIL PROTECTED]
Subject: Effective ways to deal with DDoS attacks?



There's been plenty of discussion about DDoS attacks, and my
IDS system is darn good at identifying them. But what are
effective methods for large service-provider networks (ie
ones where a firewall at the front would not be possible) to
deal with DDoS attacks?

Current method of updating ACLs with the source and/or
destination are slow and error-prone and hard to maintain
(especially when the target of the attack is a site that
users would like to access).

A rather extensive survey of DDoS papers has not resulted in
much on this topic.

What processes and/or tools are large networks using to
identify and limit the impact of DDoS attacks?

Thanks.
Pete.

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread measl




On Thu, 2 May 2002, Christopher L. Morrow wrote:
 On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:
 
 
  True DDoS attacks, fortunately, are rarer than most people believe.  If they
  were not, the Internet as we know it would look a lot more like a telephone
  system in USSR-at-it's-worst-days.  For example, of the two recent DDoS's I
  have been on the receiving end of, the first was generating a little over
  300mbit/sec (steady for a prolonged time), and the second went over that by a
  fair bit.  In both cases, we had core equipment (M20's and BSN5000's) fall
  over and die trying to work the events.  Additionally, our upstream peers
 
 Your M20 tipped over?? What were you doing? We regularly stop large
 (+100Mb-800Mb) attacks with less horsepower than this. Truthfully, a
 cisco is even capable of filtering (done right) at +200kpps...

I'm sorry, I was not clear here...  The M20 does great at simply pushing this
load to discard, but the overhead of what we were trying to do (extensive
filter lists to try and begin backtracing the actual skr1pt k1dd13
origin) was too much.  There is simply no good way to get back to the
ultimate source of truly distributed DoS attacks, which is, IMHO, the reason
these attacks are so prevalent - no fear of prosecution, no matter how much
collateral damage is inflicted.

  also had core equipment fall over, and we all came the [now obvious]
  conclusion that the only way to stop these attacks was to completely null
  route ourselves at our upstreams (they tried filter-fishing for specific data
  which may have helped our investigation, but when their routers started
  wheezing, we gave them the OK to just send us straight into the bit bucket
  till it was over...
 
 
 Hmm, this highlights the need to learn how to use the equipment, learn its
 boundaries and learn defenses inside these boundaries...

In the larger picture, my concern is with finding the source, so I can
prevent recurrence - a paradoxical problem considering that the short term
goal is to just stop the attack...

 
 -Chris
 
 

-- 
Yours, 
J.A. Terranson
[EMAIL PROTECTED]

If Governments really want us to behave like civilized human beings, they
should give serious consideration towards setting a better example:
Ruling by force, rather than consensus; the unrestrained application of
unjust laws (which the victim-populations were never allowed input on in
the first place); the State policy of justice only for the rich and 
elected; the intentional abuse and occassionally destruction of entire
populations merely to distract an already apathetic and numb electorate...
This type of demogoguery must surely wipe out the fascist United States
as surely as it wiped out the fascist Union of Soviet Socialist Republics.

The views expressed here are mine, and NOT those of my employers,
associates, or others.  Besides, if it *were* the opinion of all of
those people, I doubt there would be a problem to bitch about in the
first place...

Re: Effective ways to deal with DDoS attacks?



On Wed, May 01, 2002 at 11:29:46PM -0600, Pete Kruckenberg wrote:
 
 We do have a fairly aggressive security group that
 identifies compromised machines and assists customers in
 properly securing them. We can be fairly certain that the
 way these hosts are responding to this DoS attack is not as
 a result of being compromised, but a normal IP stack
 implementation.

Please please please please please tell me you are doing ingress filtering 
so the compromised boxes you host aren't spewing totally random source 
addresses on the internet.

Not that it matters though, it's still pretty difficult to find the box in 
question. DDoS programs have been auto-probing for the best src address 
method to use for some time now (almost since their birth). For example, 
say a box is compromised on a network which does ingress filtering. The 
packet program detects this, and instead of randomizing the IP with every 
packet, it picks a single random IP by spoofing the last octet. In the 
interesting environments (like a college dorm network) this gets past most 
peoples ingress filters, since they're usually not exactly providing layer 
3 all the way to the student. So when you send in a DoS complaint about 
1.2.3.182, the campus computer nerd looks it up, and goes to knock on that 
persons door. Little do they know that the actual compromised machine is 
1.2.3.97 spoofing it. You ever tried explaining this to the campus nerd? 
Not pretty!

-- 
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Re: Effective ways to deal with DDoS attacks?





On Thu, 2 May 2002, Hank Nussbacher wrote:


 At 01:49 AM 02-05-02 +0100, Avleen Vig wrote:

 As time goes by, tools are being developed (in fact they're used now) that
 completely randomize the TCP or UDP ports attacked, or use a variety of
 icmp types in the attack.
 So cuurrently the only way you can 'block' such attacks is to block all
 packets for the offending protocol as far upstream as you possibly can,
 but this is not ideal.
 
 If you're being attacked by a SYN flood, you can ask try to rate-limit the
 flood at your border (possible on Cisco IOS 12.0 and higher, and probably
 other routers too?)

 ACLs have been a good tool for the past number of years to stop DOS attacks
 but they suffer one very bad feature - they throw away the good packets
 along with the bad packets.  The same goes for CAR.  The same goes for
 taking a /32 and null routing it.  Consider Amazon being hit with a DDOS
 attack from random spoofed IPs to their web site.  You can't block on
 source IP since it is random.  If you block on destination IP - you end up
 taking Amazon off the network (the ultimate aim of the attacker) at a daily
 revenue loss of over $1M.

So, just filter and track quickly... move the block as far back as you
can. Have the customer remain agile also. :)

RE: Effective ways to deal with DDoS attacks?



I guess the 'filter box' can be a number of different things, based on your
needs and preferences.  At first glance CloudShield seems pretty beefy, am
reading more as we speak.

Yes, Juniper can be convinced to add things, we've asked for a few.  ;)
Part of the problem with asking for new things on an ASIC, takes time.
Anything they add in their code to help filter will likely not be done in
hardware, meaning potential impact.  I know some people need to filter on
their routers for various reasons, but my thoughts are to minimize this.  A
router that is working hard at just forwarding packets doesn't need to extra
overhead of looking deep into packet headers to figure out what to do with
packets.  Juniper is better at this, as are some Cisco products, but the GSR
is a crappy packet filter if you put enough traffic through it.  Yes certain
linecards are better than others, but the newer they are the more buggy they
are, and we're talking HW here, so bug fixes will be awhile.

The caveat to all this is obvious, these are big links and big routers, only
applies to high traffic networks..as that is the only place the expense is
justified.  uRPF, however, works on (almost) any CEF capable Cisco router.

Some may have already seen this, worth a look if not.  

http://www.cisco.com/warp/public/707/newsflash.html

There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type.  Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards.  Keep
in mind this is NOT a filter, so the impact is much less, it is simply a CEF
lookup, much more efficient than a filter.  This will get rid of a HUGE
percentage of spoofed packets that hit your network, and would also work
pretty well if you are the source of an attack.  There is some debate as to
whether you must not have ANY RFC1918 space for this to work.  We're trying
to find this out (not a priority), if I get info I'll post.



-Original Message-
From: Richard A Steenbergen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 9:23 AM
To: LeBlanc, Jason
Cc: 'Pete Kruckenberg'; [EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?


On Thu, May 02, 2002 at 08:54:05AM -0700, LeBlanc, Jason wrote:
 
 uRPF and Radware DoShield, one DoShield per link btw edge router and core
 router.  Use IDS (yes there is a way to capture all your traffic and
 anaylyze it, regardless of bandwidth, no it isn't one box) to identify a
 signature, build a filter, config filter on DoShield, up to ~200Mb/s per
 DoShield of filtering with zero impact to legit traffic.  Scale
horizontally
 (add more links each with a DoShield on it) based on your ingress traffic.
 
 I've seen many suggestions on this list, this is the only thing that works
 for huge (100Mb/s+) attacks.  eBay is likely the biggest target on the
net,
 this works for us 90% of the time.  Is the HW expensive?  Yes. (~$35k per
 DoShield I think)  It works, it scales.  

You might want to take a look at CloudShield (www.cloudshield.com), they 
have what can only be described as a pretty impressive looking box for 
this kind of stuff.

 There is no way a Cisco router can handle filtering attacks past a
 certain point, nor is it capable of even filtering on some patterns in
 attack packets.  Juniper is better, but still lacks some filtering
 capabilities. Your router is a router, not a packet filter, give up
 trying to make it do this until someone builds this into an ASIC on the
 router.

Thats what the IP2 does, match bytes in the headers and come back with a 
thumbs down or a thumbs up and a destination interface. It's really not 
that much harder to match the bytes for a dest port against a compiled 
ruleset and decide yes or no then it is to match the dest address against 
a forwarding table and decide which nexthop.

They CAN filter on anything in the headers, it's just a matter of
convincing them that the specific filter you want is something they should
add to their software language and microcode. I'm sure as a core router
vendor they must hear every feature request imaginable and not know which
ones to follow up on. If anyone from Juniper is listening, I can tell you
4 things to add which will stop all existing packet kiddie tools in their
tracks. But then again, I'd rather just have a language for bitmatching at
any offset. :)

-- 
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Re: Effective ways to deal with DDoS attacks?




On Thu, 2 May 2002, Vincent Gillet wrote:

 [EMAIL PROTECTED] disait :

   have been on the receiving end of, the first was generating a little over
   300mbit/sec (steady for a prolonged time), and the second went over that by a
   fair bit.  In both cases, we had core equipment (M20's and BSN5000's) fall
   over and die trying to work the events.  Additionally, our upstream peers
 
  Your M20 tipped over?? What were you doing? We regularly stop large
  (+100Mb-800Mb) attacks with less horsepower than this. Truthfully, a
  cisco is even capable of filtering (done right) at +200kpps...

 On Cisco boxes, it depends too much on Interface type, LC Engine, IOS, ...
 etc ...

In this you have my whole-hearted agreement :( But, this goes back to
'know you systems, know their boundaries'. All of the people that work
here (on our team) know what you can and can't do, we are effective in our
jobs because of this. Sure your random NOC worker or even level3/4 NOC
worker isn't going to know all the ins and outs of security thingy's on
your backbone equipemt, that's why you pay 5-7 people to learn it :)


 Beside, some features cannot run concurently (i remumber an ACL on GSR
 that make my netflow export stop  it tooks days to figure this out !!!)


Ha! :) try acl's on engine-2 cards with sub-interfaces! (like the triton
gig card... cause no one would ever sub-interface a gig interface, right?)

 ACL Implement on GSR is too a nightmare.
 We are operating more than 70 GSRs with very different interface, LC engine and IOS 
...


Just 70? your live is easy then :) Really though, this is, in my opinion,
the larges problem Cisco has to over come. They need to have the 'luxury'
that Juniper has: One IOS, One implementation of commands, same commands
everywhere... consistency I believe its called.

Its not, obviously, going to happen overnight, but to their credit folks
at cisco ARE working to make the security problem less of a problem. If
you are having trouble getting your sales folk from cisco to
listen/understand/pass-along-input you can look for their 'ISP Group'
which I'm sure Barry Greene will be happy to properly name and provide
contacts for, or perhaps they are in the sites he posted here before?

Re: Effective ways to deal with DDoS attacks?




On Thu, 2 May 2002, Iljitsch van Beijnum wrote:


 On Wed, 1 May 2002, Pete Kruckenberg wrote:

  There's been plenty of discussion about DDoS attacks, and my
  IDS system is darn good at identifying them. But what are
  effective methods for large service-provider networks (ie
  ones where a firewall at the front would not be possible) to
  deal with DDoS attacks?

 I'm working on something that should provide a solution to this for at
 least some subset of all attacks.

 Basically, it works like this: when you identify the target of the attack,
 you have traffic for those target addresses rerouted to a filter box.
 This filter box then contains source address based filters to get rid of
 the attacking traffic.

 The idea is that a service provider could install one or more of those
 filter boxes (standard routers or multilayer switches) and have customers
 use standard BGP mechanisms to get the filter boxes to clean up the
 traffic. This should work as long as the number of source addresses is
 relatively limited, say below 20,000.


Congrats on re-inventing the wheel :( This is what
mazuu/arbor/wanwall(riverhead now?) all do... this is also the way
CenterTrack(tm robert stone) was kind of supposed to work.

As near as I can tell this doesn't scale too well in a large network. This
is a shame, but its a reality. Additionally 20k sources max? that's not
nearly enough, how many addresses are in 0/0 ? you should atleast plan for
this contingency...

RE: Effective ways to deal with DDoS attacks?

Try a compiled ACL on a 3 port gigE for some fun.

-Original Message-
From: Christopher L. Morrow [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 9:48 AM
To: Vincent Gillet
Cc: Christopher L. Morrow; [EMAIL PROTECTED]; Pete Kruckenberg;
[EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?

On Thu, 2 May 2002, Vincent Gillet wrote:

 [EMAIL PROTECTED] disait :

   have been on the receiving end of, the first was generating a little
over
   300mbit/sec (steady for a prolonged time), and the second went over
that by a
   fair bit.  In both cases, we had core equipment (M20's and BSN5000's)
fall
   over and die trying to work the events.  Additionally, our upstream
peers

  Your M20 tipped over?? What were you doing? We regularly stop large
  (+100Mb-800Mb) attacks with less horsepower than this. Truthfully, a
  cisco is even capable of filtering (done right) at +200kpps...

 On Cisco boxes, it depends too much on Interface type, LC Engine, IOS, ...
 etc ...

In this you have my whole-hearted agreement :( But, this goes back to
'know you systems, know their boundaries'. All of the people that work
here (on our team) know what you can and can't do, we are effective in our
jobs because of this. Sure your random NOC worker or even level3/4 NOC
worker isn't going to know all the ins and outs of security thingy's on
your backbone equipemt, that's why you pay 5-7 people to learn it :)

 Beside, some features cannot run concurently (i remumber an ACL on GSR
 that make my netflow export stop  it tooks days to figure this out
!!!)

Ha! :) try acl's on engine-2 cards with sub-interfaces! (like the triton
gig card... cause no one would ever sub-interface a gig interface, right?)

 ACL Implement on GSR is too a nightmare.
 We are operating more than 70 GSRs with very different interface, LC
engine and IOS ...

Just 70? your live is easy then :) Really though, this is, in my opinion,
the larges problem Cisco has to over come. They need to have the 'luxury'
that Juniper has: One IOS, One implementation of commands, same commands
everywhere... consistency I believe its called.

Its not, obviously, going to happen overnight, but to their credit folks
at cisco ARE working to make the security problem less of a problem. If
you are having trouble getting your sales folk from cisco to
listen/understand/pass-along-input you can look for their 'ISP Group'
which I'm sure Barry Greene will be happy to properly name and provide
contacts for, or perhaps they are in the sites he posted here before?

Re: Effective ways to deal with DDoS attacks?



On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote:
 
 Yes, Juniper can be convinced to add things, we've asked for a few.  ;)
 Part of the problem with asking for new things on an ASIC, takes time.
 Anything they add in their code to help filter will likely not be done
 in hardware, meaning potential impact.  I know some people need to
 filter on their routers for various reasons, but my thoughts are to
 minimize this.  A router that is working hard at just forwarding packets
 doesn't need to extra overhead of looking deep into packet headers to
 figure out what to do with packets.  Juniper is better at this, as are
 some Cisco products, but the GSR is a crappy packet filter if you put
 enough traffic through it.  Yes certain linecards are better than
 others, but the newer they are the more buggy they are, and we're
 talking HW here, so bug fixes will be awhile.

I think you're misunderstanding how this works.

http://www.juniper.net/news/features/ipii/faq_ip2.html
http://www.juniper.net/techcenter/techpapers/200015-03.html

3. How does the Internet Processor II ASIC enable service providers to
upgrade functionality without upgrading hardware? Essentially, the
Internet Processor II ASIC contains logic that implements a number of
lookup algorithms, including trees, tables, firewall programs, and a way
to chain those individual lookups together in an arbitrary sequence. The
final answer to an entire lookup, then, is the result of all the matches
that were run. By implementing complex lookups as a series of fundamental
primitives, the ASIC can support almost anything for which an application
can be described. Since the ASIC implementation is so general, new
functionality can be enabled in JUNOS software upgrades without having to
swap hardware.

-- 
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

RE: Effective ways to deal with DDoS attacks?



On Thu, 2 May 2002, LeBlanc, Jason wrote:

 There are some limitations as to where uRPF works, SONET only on GSRs for
 example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
 think) regardless of interface type.  Impact should be minimal, as it simply
 does a lookup in the CEF table, if the route isn't there it discards.

It can do much more. You can use it to get rid spoofed source addresses
from customers and peers without the need to maintain large access lists.

 lookup, much more efficient than a filter.  This will get rid of a HUGE
 percentage of spoofed packets that hit your network,

If you just filter out anything that's not in the routing table, that's
about half the address space and it only works if the spoofers are stupid.
When you're looking at pure bandwidth that's still helpful, but it doesn't
really solve anything.

However, You can use unicast RPF as a very efficient source address
filter, by routing addresses to the null interface. This way you can get
rid of huge amounts of unwanted sources in a very clean way.

As long as we're asking for features: what I would like is a unicast RPF
check that allows everything that isn't routed to the null interface. And
of course unicast RPF period for all vendors who aren't Cisco.

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread Mark Turpin



On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this:
snip
 
 There are some limitations as to where uRPF works, SONET only on GSRs for
 example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
 think) regardless of interface type.  Impact should be minimal, as it simply
 does a lookup in the CEF table, if the route isn't there it discards.  Keep
 in mind this is NOT a filter, so the impact is much less, it is simply a CEF
 lookup, much more efficient than a filter.  This will get rid of a HUGE
 percentage of spoofed packets that hit your network, and would also work
 pretty well if you are the source of an attack.  There is some debate as to
 whether you must not have ANY RFC1918 space for this to work.  We're trying
 to find this out (not a priority), if I get info I'll post.
 

hmm... either you're being extremely vague, or you misunderstand how RPF works.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt5/scdrpf.htm

Its not checking cef to see if a route is there its making sure that a packet
received on an interface came in on an interface that is the best return path
to reach that packet.

thereby explaining why multihomed customers will get borked in the event of using rpf.

enjoy,
-mark
-- 
 Support your local medical examiner--die strangely.

Re: Effective ways to deal with DDoS attacks?



On Thu, 2 May 2002, Christopher L. Morrow wrote:

 Congrats on re-inventing the wheel :( This is what
 mazuu/arbor/wanwall(riverhead now?) all do... this is also the way
 CenterTrack(tm robert stone) was kind of supposed to work.

Thanks for the kind works.

Just to be clear: I'm not working on a _product_, just on a paper
explaining how to do this using standard components and protocols.

 As near as I can tell this doesn't scale too well in a large network.

If you have a router that can forward 10 Gbps into the right direction,
you can also have a router forward 10 Gbps in the wrong direction. That's
pretty much all it takes.

 This is a shame, but its a reality. Additionally 20k sources max? that's not
 nearly enough, how many addresses are in 0/0 ? you should atleast plan for
 this contingency...

The idea is to use unicast RPF. So you're only limited by the number of
routes a Cisco can hold. 20k per customer under attack should be doable
without too much effort, more should be possible, but filtering 0/0
defeats the purpose. Also, it can be done using a single line, so no
problem there.

RE: Effective ways to deal with DDoS attacks?



Thats how it we understood it to work (CEF lookup).  It checks for a route
in the table, obviously any real route would be in the CEF table.  I may be
wrong, but it doesn't actually send a packet to verify, the logical way to
check would be by checking CEF, as anything the router knows about that is
valid would be in CEF.  If I'm misunderstanding, please do send more info.

-Original Message-
From: Mark Turpin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 10:05 AM
To: LeBlanc, Jason
Cc: [EMAIL PROTECTED]
Subject: Re: Effective ways to deal with DDoS attacks?


On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something
like this:
snip
 
 There are some limitations as to where uRPF works, SONET only on GSRs for
 example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
 think) regardless of interface type.  Impact should be minimal, as it
simply
 does a lookup in the CEF table, if the route isn't there it discards.
Keep
 in mind this is NOT a filter, so the impact is much less, it is simply a
CEF
 lookup, much more efficient than a filter.  This will get rid of a HUGE
 percentage of spoofed packets that hit your network, and would also work
 pretty well if you are the source of an attack.  There is some debate as
to
 whether you must not have ANY RFC1918 space for this to work.  We're
trying
 to find this out (not a priority), if I get info I'll post.
 

hmm... either you're being extremely vague, or you misunderstand how RPF
works.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu
r_c/scprt5/scdrpf.htm

Its not checking cef to see if a route is there its making sure that a
packet
received on an interface came in on an interface that is the best return
path
to reach that packet.

thereby explaining why multihomed customers will get borked in the event of
using rpf.

enjoy,
-mark
-- 
 Support your local medical examiner--die strangely.

RE: Effective ways to deal with DDoS attacks?



It (rpf) can't stop a DoS, but it does cut down on some of the spoofed
packets, any reduction in the number of packets hitting whatever has to
filter or deal with the attack packets helps.  I don't have the stats in
front of me, but our findings were than urpf would cut enough out to be
worthwhile.

-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 02, 2002 9:58 AM
To: LeBlanc, Jason
Cc: [EMAIL PROTECTED]
Subject: RE: Effective ways to deal with DDoS attacks?



If you just filter out anything that's not in the routing table, that's
about half the address space and it only works if the spoofers are stupid.
When you're looking at pure bandwidth that's still helpful, but it doesn't
really solve anything.

However, You can use unicast RPF as a very efficient source address
filter, by routing addresses to the null interface. This way you can get
rid of huge amounts of unwanted sources in a very clean way.

As long as we're asking for features: what I would like is a unicast RPF
check that allows everything that isn't routed to the null interface. And
of course unicast RPF period for all vendors who aren't Cisco.

Re: Effective ways to deal with DDoS attacks?

On Thu, May 02, 2002 at 12:04:35PM -0500, Mark Turpin wrote:

On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this:
snip

There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF table, if the route isn't there it discards. Keep
in mind this is NOT a filter, so the impact is much less, it is simply a CEF
lookup, much more efficient than a filter. This will get rid of a HUGE
percentage of spoofed packets that hit your network, and would also work
pretty well if you are the source of an attack. There is some debate as to
whether you must not have ANY RFC1918 space for this to work. We're trying
to find this out (not a priority), if I get info I'll post.

hmm... either you're being extremely vague, or you misunderstand how RPF
works.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt5/scdrpf.htm

Its not checking cef to see if a route is there its making sure that
a packet received on an interface came in on an interface that is the
best return path to reach that packet.

thereby explaining why multihomed customers will get borked in the event
of using rpf.

RPF works by matching the source address of the packet against the CEF
table, in addition to the normal match against the destination address.
There are multiple modes of operation, ranging from is there a route
for the source address to the specific interface it come in on to is
there a route to the source address for ANY interface on the box The
former is used to stop your single homed customers from spoofing wildly
into the internet. The latter is usually used as a stopgap measure to
limit the number of spoofed packets coming into your network via transits.
The number you'd expect to filter is 50%, assuming the attacker in
question is using an evenly distributing random() function.

--
Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread Eric Gauthier



 http://www.cisco.com/warp/public/707/newsflash.html
 There are some limitations as to where uRPF works, SONET only on GSRs for
 example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
 think) regardless of interface type.  Impact should be minimal, as it simply
 does a lookup in the CEF table, if the route isn't there it discards.

We're running 6509's - both Sup1a and Sup2 - with 10, 100, and GigE links
in a large campus environment.  We did have some problems with the Sup2's 
running hybrid code, but the Sup1a's were fine.  When we switched over to 
native IOS about six months ago, both the Sup1a's and Sup2's handled it 
without a problem or performance hit, even on some of our campus Gigabit links.  
Its a nice feature but, as someone already pointed out, its based on routing 
table entries so there is NO PROTECTION if someone on a subnet is spoofing the 
IP of another system on the same subnet.  Having said that, we use it more so
that we can quickly track the source of an attack if its originating on our
network rather than as a means to protect ourselves from the big, bad
Internet.  Once we know the source, we know for sure what router interface
its originating from, so we just start snooping traffic from that interface to
find the offending MAC and go from there...

Another limitation that we've found with uRPF is that it doesn't 
live well with multihomed systems (i.e. a host with two NIC's - each on 
a different subnet) because of the way most OS'es handle their
default gateways.  For anyone who is interested in our experience, drop me 
a note off list.  If you have a solution for this multihoming problem, PLEASE 
email me off-list.

Eric :)

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread Aditya



In case no one has already posted it, you might check out the following
document:

  http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf

which talks about knobs for Cisco's RPF that will allow it to work with
multihomed situations. There is also stuff in there about how to propogate a
null route quickly for any _source_ prefix using IBGP (and no, an IGP like
ISIS or OSPF won't work) and RPF.

To back Jason up, Cisco's unicast RPF decides whether an interface is the
best by doing a CEF lookup.

Adi

On Thu, May 02, 2002 at 10:16:55AM -0700, LeBlanc, Jason wrote:
 
 Thats how it we understood it to work (CEF lookup).  It checks for a route
 in the table, obviously any real route would be in the CEF table.  I may be
 wrong, but it doesn't actually send a packet to verify, the logical way to
 check would be by checking CEF, as anything the router knows about that is
 valid would be in CEF.  If I'm misunderstanding, please do send more info.
 
 -Original Message-
 From: Mark Turpin [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, May 02, 2002 10:05 AM
 To: LeBlanc, Jason
 Cc: [EMAIL PROTECTED]
 Subject: Re: Effective ways to deal with DDoS attacks?
 
 
 On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something
 like this:
 snip
  
  There are some limitations as to where uRPF works, SONET only on GSRs for
  example (thanks Cisco).  I believe it will work on 65xx (SUP1A and SUP2 I
  think) regardless of interface type.  Impact should be minimal, as it
 simply
  does a lookup in the CEF table, if the route isn't there it discards.
 Keep
  in mind this is NOT a filter, so the impact is much less, it is simply a
 CEF
  lookup, much more efficient than a filter.  This will get rid of a HUGE
  percentage of spoofed packets that hit your network, and would also work
  pretty well if you are the source of an attack.  There is some debate as
 to
  whether you must not have ANY RFC1918 space for this to work.  We're
 trying
  to find this out (not a priority), if I get info I'll post.
  
 
 hmm... either you're being extremely vague, or you misunderstand how RPF
 works.
 http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu
 r_c/scprt5/scdrpf.htm
 
 Its not checking cef to see if a route is there its making sure that a
 packet
 received on an interface came in on an interface that is the best return
 path
 to reach that packet.
 
 thereby explaining why multihomed customers will get borked in the event of
 using rpf.
 
 enjoy,
 -mark
 -- 
  Support your local medical examiner--die strangely.

Re: Effective ways to deal with DDoS attacks?



On Thu, 2 May 2002, Richard A Steenbergen wrote:

 RPF works by matching the source address of the packet against the CEF
 table, in addition to the normal match against the destination address.
 There are multiple modes of operation, ranging from is there a route
 for the source address to the specific interface it come in on to is
 there a route to the source address for ANY interface on the box The
 former is used to stop your single homed customers from spoofing wildly
 into the internet.

You can do this for multihomed customers to: it's just that multihomed
customers can't use it for traffic coming from their transits (= you),
because uRPF breaks asymmetric routing.

RE: Effective ways to deal with DDoS attacks?





On Thu, 2 May 2002, LeBlanc, Jason wrote:


 Try a compiled ACL on a 3 port gigE for some fun.


Last I recall the IOS didn't even have 'ip access-group' in the config of
interfaces :( It took me like three hits of the 'tab' key at 'ip access-g'
before I realized it just wasn't there ;(

RE: Effective ways to deal with DDoS attacks?

2002-05-02 Thread Livio Ricciulli



We have been working on this problem for the last two years and
have productized a practical way to deal with DDoS. Given what I have
read today, I think most people on this list would
like it. If you send me email, I will send you a white paper that is much
more
detailed than what you can find on http://www.reactivenetwork.com.

Livio.

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread E.B. Dreger



RAS Date: Thu, 2 May 2002 12:23:01 -0400
RAS From: Richard A Steenbergen


RAS They CAN filter on anything in the headers, it's just a matter of
RAS convincing them that the specific filter you want is something they should
RAS add to their software language and microcode. I'm sure as a core router
RAS vendor they must hear every feature request imaginable and not know which
RAS ones to follow up on. If anyone from Juniper is listening, I can tell you
RAS 4 things to add which will stop all existing packet kiddie tools in their
RAS tracks. But then again, I'd rather just have a language for bitmatching at
RAS any offset. :)

And it wouldn't be that hard to have something to compile
rulesets into simply assembly, either:

movb 0x12(1,%ecx),%al
andb $0x34,%al
xorb $0x14,%al
jz some_destination

Oversimplified, yes.  But mask-then-test is one of the simpler
apps to write.  s/x86/chipofchoice/ and have fun.

Juniper being based on FreeBSD/x86, perhaps some kernel hooks
might be in order for those who wish to write their own code.


--
Eddy

Brotsman  Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.

Re: Effective ways to deal with DDoS attacks?

2002-05-02 Thread E.B. Dreger



ED Date: Fri, 3 May 2002 02:35:53 + (GMT)
ED From: E.B. Dreger


ED Juniper being based on FreeBSD/x86, perhaps some kernel hooks
ED might be in order for those who wish to write their own code.

And, were my head on straight, I'd have been thinking about the
ASIC in the line card, _not_ the central CPU...

/me needs sleep.


--
Eddy

Brotsman  Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.

Effective ways to deal with DDoS attacks?

2002-05-01 Thread Pete Kruckenberg



There's been plenty of discussion about DDoS attacks, and my
IDS system is darn good at identifying them. But what are
effective methods for large service-provider networks (ie
ones where a firewall at the front would not be possible) to
deal with DDoS attacks?

Current method of updating ACLs with the source and/or
destination are slow and error-prone and hard to maintain
(especially when the target of the attack is a site that
users would like to access).

A rather extensive survey of DDoS papers has not resulted in
much on this topic.

What processes and/or tools are large networks using to
identify and limit the impact of DDoS attacks?

Thanks.
Pete.

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread dies




http://www.secsup.org/Tracking/

UUNet uses that...others might as well, Shrug.

Quick, simple, effective tracking of DDoS attacks.

As for identifying attacks, quite honestly large ISP's are typically still
relying on customer notification.  I know that's how we do it.

On Wed, 1 May 2002, Pete Kruckenberg wrote:


 There's been plenty of discussion about DDoS attacks, and my
 IDS system is darn good at identifying them. But what are
 effective methods for large service-provider networks (ie
 ones where a firewall at the front would not be possible) to
 deal with DDoS attacks?

 Current method of updating ACLs with the source and/or
 destination are slow and error-prone and hard to maintain
 (especially when the target of the attack is a site that
 users would like to access).

 A rather extensive survey of DDoS papers has not resulted in
 much on this topic.

 What processes and/or tools are large networks using to
 identify and limit the impact of DDoS attacks?

 Thanks.
 Pete.

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread dies




Then you are pushing out /32's and peers would need to accept them.  Then
someone will want to blackhole /30's, /29's, etc.  Route bloat.  Yum!

Additionally you are creating a way to basically destroy the Internet as a
whole.  One kiddie gets ahold of a router, say of a large backbone
provider, takes one of their aggregate blocks (/16? /10? /8?) and splits
it into /32 announcements.

Anyways, some providers already allow you to set a community on a route,
and they will inturn blackhole it for you.  I believe Teleglobe does
this for some customers and I know UUNet does this for all customers.

On Wed, 1 May 2002, Wojtek Zlobicki wrote:


   What processes and/or tools are large networks using to
   identify and limit the impact of DDoS attacks?
 
  A great deal of thought is being expended on this question, I am certain,
  however, how many of these thought campaings have born significant fruit
 yet,
  I do not know.

 How about the following :

 We develop a new community , being fully transitive (666 would be
 appropriate ) and either build into router code or create a route map to
 null route anything that contains this community.  The effect of this being
 the distribution of the force of the attack.

 This aside, how effective would be using a no export community with ones
 peers (being non transitive, it would still distribute the force of the
 attack).

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Wojtek Zlobicki



 Then you are pushing out /32's and peers would need to accept them.  Then
 someone will want to blackhole /30's, /29's, etc.  Route bloat.  Yum!

I am in no way proposing discounting current filtering rules.  There are
alway two
different intersts one must consider, one that of the customer and two that
of the service provider.  If a large block must be filtered so be it.

Where are providers drawing the line ?  Anyone have somewhat detailed
published policies as to what a provider can do in order to protect their
nework as a whole.
At what point (strength of the attack) does a customers netblock (assuming a
/24 for
example) get null routed by whichever party.

 Anyways, some providers already allow you to set a community on a route,
 and they will inturn blackhole it for you.  I believe Teleglobe does
 this for some customers and I know UUNet does this for all customers.

When the attack is distributed, having one or two providers (even if they
are UUNET
or Teleglobe) is just not enough.  Must private routing policy be developed
in order to make my suggestion work.  The reason that so many methods likely
fail are the difficulty of implementation and low implementation.

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Leo Bicknell



In a message written on Wed, May 01, 2002 at 08:17:04PM -0500, dies wrote:
 Then you are pushing out /32's and peers would need to accept them.  Then
 someone will want to blackhole /30's, /29's, etc.  Route bloat.  Yum!

I'm not sure what form this would take, but I have long wished
route processing could be sent into a programming language.  For
this specific example it would be nice to set a maximum number of
route limit for the total number of routes on the session, as well
as /per community/.

That is, community :666 == blackhole me, and I could limit each
peer to say, 6 of these at a time.  More would not take down the
session, but simply be ignored.

I can carry 6 /32's for every peer I have, and if they only have
6, they will probably use them for the most abusive target.

There are, of course, approximately an infinitate number more
applications for a more flexible mechanism.  Of course, it would
require more human smarts, which might be why vendors don't do it.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Richard A Steenbergen



On Wed, May 01, 2002 at 09:38:52PM -0400, Wojtek Zlobicki wrote:
 
 How about the following :
 
 We develop a new community , being fully transitive (666 would be
 appropriate ) and either build into router code or create a route map to
 null route anything that contains this community.  The effect of this being
 the distribution of the force of the attack.

This has been proposed a dozen times over, and I agree that there should
be a well known community for discarding packets. Go try and get the IETF
to add it, let me know how it goes. :)

 This aside, how effective would be using a no export community with ones
 peers (being non transitive, it would still distribute the force of the
 attack).

Many people do this already. If you're looking to purchase transit and you
think this is something you'll care about, ask for it or vote with your
wallet.

-- 
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Sean Donelan





On Wed, 1 May 2002, Pete Kruckenberg wrote:
 We experience a lot of types of attacks (education/research
 network  = easy hacker target). With DDoS incidents, it
 seems we are more often an unknowing/unwilling participant
 than the target, partly due to owning big chunks of IP
 address space.

Universities are hacker training grounds, but also have much
better network security response than most corporate networks.
Whatever problems you have, the rest of us will have soon enough
it may just take us longer to notice it.

 Has anyone tried this kind of an approach or any other type
 of automated/efficient approach to dampen the zombie side
 of the DDoS attack?

Has anyone implemented Bellovin's Pushback in a production
network yet?

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Pete Kruckenberg



On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:

 and then again, there has been much discussion on simple
 DoS attacks, where the term DDoS is erroneously used...  
 I am very much not trying to imply that this is the case
 here, but it's important that the two be thoroughly
 distinguished from each other - they are totally
 different things to deal with.

Sorry, I should have been more clear. 

My issue (currently)  is not being the target of the DDoS
attack, but being a (unwilling) participant. People outside
our network are launching DDoS attacks (distributed SYN
floods) against destinations outside our network, using
about 8,000 Web server hosts on our network as reflectors.

These are not zombies. They are secured, uncompromised Web
servers. The attack spoofs the target address as the source,
and one of our machines as a destination, port 80. Getting
everyone to implement defenses (SYN cookies) on their Web
servers is nearly impossible (most don't even have a
defense--printers and routers with Web interfaces).

SYN packet comes in, one of these machines responses with a
RST to the source, which is actually the target of the
attack. Unfortunately, the target is often a site that
people would like to get to, as is the reflector, so
permanent filters on the target or reflector create lots of
complaints.

 We captured several seconds of the last DDoS and came up
 with over 700 participating hosts...

Some of them probably appear to be from our network...

Pete.

Re: Effective ways to deal with DDoS attacks?



What we use and we're a 'largeish' network:

http://www.secsup.org/Tracking/
(shameless plug #1)

Among other things this is a tool we use... there was a great set of
slides and presentation given at NANOG23:

http://www.nanog.org/mtg-0110/greene.html
(shameless plug #2)

There is also a set of papers Barry Greene from Cisco has available on the
Cisco website... I'm positive he'll respond to this with the link, if he
doesn't search the NANOG mailing list archive for the link it should be
obvious in posts from Barry.

If you want more pointers I'd be glad to chat on the phone with you,
numbers included below.


--Chris
([EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

On Wed, 1 May 2002, Pete Kruckenberg wrote:


 There's been plenty of discussion about DDoS attacks, and my
 IDS system is darn good at identifying them. But what are
 effective methods for large service-provider networks (ie
 ones where a firewall at the front would not be possible) to
 deal with DDoS attacks?

 Current method of updating ACLs with the source and/or
 destination are slow and error-prone and hard to maintain
 (especially when the target of the attack is a site that
 users would like to access).

 A rather extensive survey of DDoS papers has not resulted in
 much on this topic.

 What processes and/or tools are large networks using to
 identify and limit the impact of DDoS attacks?

 Thanks.
 Pete.

Re: Effective ways to deal with DDoS attacks?





On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:


 True DDoS attacks, fortunately, are rarer than most people believe.  If they
 were not, the Internet as we know it would look a lot more like a telephone
 system in USSR-at-it's-worst-days.  For example, of the two recent DDoS's I
 have been on the receiving end of, the first was generating a little over
 300mbit/sec (steady for a prolonged time), and the second went over that by a
 fair bit.  In both cases, we had core equipment (M20's and BSN5000's) fall
 over and die trying to work the events.  Additionally, our upstream peers

Your M20 tipped over?? What were you doing? We regularly stop large
(+100Mb-800Mb) attacks with less horsepower than this. Truthfully, a
cisco is even capable of filtering (done right) at +200kpps...

 also had core equipment fall over, and we all came the [now obvious]
 conclusion that the only way to stop these attacks was to completely null
 route ourselves at our upstreams (they tried filter-fishing for specific data
 which may have helped our investigation, but when their routers started
 wheezing, we gave them the OK to just send us straight into the bit bucket
 till it was over...


Hmm, this highlights the need to learn how to use the equipment, learn its
boundaries and learn defenses inside these boundaries...

-Chris

Re: Effective ways to deal with DDoS attacks?




On Wed, 1 May 2002, dies wrote:



 Then you are pushing out /32's and peers would need to accept them.  Then
 someone will want to blackhole /30's, /29's, etc.  Route bloat.  Yum!


Yes.

 Additionally you are creating a way to basically destroy the Internet as a
 whole.  One kiddie gets ahold of a router, say of a large backbone
 provider, takes one of their aggregate blocks (/16? /10? /8?) and splits
 it into /32 announcements.


Or, blackhole the /16 :) more fun! (assuming no other smaller
announcements inside that /16 of course)

 Anyways, some providers already allow you to set a community on a route,
 and they will inturn blackhole it for you.  I believe Teleglobe does
 this for some customers and I know UUNet does this for all customers.

Hmm, Mr. 'dies' is almost correct... if you are a UUNET customer and you
would like to do this please call the customer service center and they
will help you to configure this 'service'.

Thanks though Mr. 'dies' :)


 On Wed, 1 May 2002, Wojtek Zlobicki wrote:

 
What processes and/or tools are large networks using to
identify and limit the impact of DDoS attacks?
  
   A great deal of thought is being expended on this question, I am certain,
   however, how many of these thought campaings have born significant fruit
  yet,
   I do not know.
 
  How about the following :
 
  We develop a new community , being fully transitive (666 would be
  appropriate ) and either build into router code or create a route map to
  null route anything that contains this community.  The effect of this being
  the distribution of the force of the attack.
 
  This aside, how effective would be using a no export community with ones
  peers (being non transitive, it would still distribute the force of the
  attack).

Re: Effective ways to deal with DDoS attacks?




On Wed, 1 May 2002, Wojtek Zlobicki wrote:

 Where are providers drawing the line ?  Anyone have somewhat detailed
 published policies as to what a provider can do in order to protect their
 nework as a whole.
 At what point (strength of the attack) does a customers netblock (assuming a
 /24 for
 example) get null routed by whichever party.

Most providers likely have a policy similar to: I can't sacrafice 1
my network for 1 customer. So, if the attack is sufficient to degrade
service on the ISP network most likely the customer under attack will get
null routed.


  Anyways, some providers already allow you to set a community on a route,
  and they will inturn blackhole it for you.  I believe Teleglobe does
  this for some customers and I know UUNet does this for all customers.

 When the attack is distributed, having one or two providers (even if they
 are UUNET
 or Teleglobe) is just not enough.  Must private routing policy be developed
 in order to make my suggestion work.  The reason that so many methods likely
 fail are the difficulty of implementation and low implementation.

Hmm, perhaps FIRST customers should insist that their ISP have some 24/7
security contact that can actually help in the case of an attack. Today
there are very few that have this capability. I'd say from personal
experience that the number is way too small, even in the 'large' ISP arena
:(

More pressure from customers for real security would be a good start.

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Richard A Steenbergen



On Thu, May 02, 2002 at 04:28:44AM +, Christopher L. Morrow wrote:
 
 Let me say this one more time... RATE LIMITS DON'T DO SHIT TO STOP
 ATTACKS for the victim atleast, all they do is make the job of the
 attacker that much easier.  For instance:
 
 1) I synflood www.avleen.org
 2) you rate-limit syns to 1MB
 3) I now only flood 1MB and I still win
 
 So, don't rely on a rate-limit as its not going to help.

Thank you, I can't make this point enough and people still say we'll just
rate limit!. Filtering is only as good as your ability to DETERMINE WHAT
TO FILTER.

The only time you can get anything from this is when you admit defeat on 
keeping your services responding to new connection but want to keep 
existing connections and/or the end servers from failing completely. 
Depending on the service in question this may or may not be a good goal.

-- 
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Re: Effective ways to deal with DDoS attacks?




On Wed, 1 May 2002, Richard A Steenbergen wrote:

 I give it 2 months, then they'll start hitting random dst IPs in a target
 prefix (say a common /24 going through the same path).


Damn you, don't give them any ideas :)

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Basil Kruglov



On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote:
 On Wed, 1 May 2002, Wojtek Zlobicki wrote:
 
  Where are providers drawing the line ?  Anyone have somewhat detailed
  published policies as to what a provider can do in order to protect their
  nework as a whole.
  At what point (strength of the attack) does a customers netblock (assuming a
  /24 for
  example) get null routed by whichever party.
 
 Most providers likely have a policy similar to: I can't sacrafice 1
 my network for 1 customer. So, if the attack is sufficient to degrade
 service on the ISP network most likely the customer under attack will get
 null routed.

Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just
for the sake of the argument), UU will not null route my ircd if it
it gets attacked on regular basis, say *daily* ?

Furthermore you are going to consistently place filters on your routers,
take them out within the 24h (or whatever then-current policy of UUnet is)
and track attacks back to their sources within the boundaries of your 
backbone on a daily basis? ;)

Will you do that for say a regular T1 customer or do I need more commitment 
as sales droids like to put it, to even consider such a service ? ;)

 Hmm, perhaps FIRST customers should insist that their ISP have some 24/7
 security contact that can actually help in the case of an attack. Today
 there are very few that have this capability. I'd say from personal
 experience that the number is way too small, even in the 'large' ISP arena
 :(
 
 More pressure from customers for real security would be a good start.

sigh, tried and failed, miserably I might add.

-Basil

Re: Effective ways to deal with DDoS attacks?




On Wed, 1 May 2002, Pete Kruckenberg wrote:


 On Wed, 1 May 2002, Richard A Steenbergen wrote:

  DDoS attacks is such a generic term. There are a wide
  variety of attacks which each need to be handled in
  their own way, the extra D is just one possible twist.
  Can you explain what kind of attack you're interested
  in?

 We experience a lot of types of attacks (education/research
 network  = easy hacker target). With DDoS incidents, it
 seems we are more often an unknowing/unwilling participant
 than the target, partly due to owning big chunks of IP
 address space.

 We most frequently are the zombie/reflector participants in
 an attack that originates outside our network, to a target
 outside our network. As many as 8,000 hosts on our network
 are reflecting SYN floods in the current attacks.

Sounds like its time for a firewall on your network :)


 Identification doesn't seem to be a problem. Snort is doing
 far too well notifying us. Responding and managing all of
 the defenses is becoming a lot of pain-staking work, and
 error-prone (why can't Cisco make ACLs easier to manage).


they aren't tough to 'manage' they are sometimes tough to live with though
:(

 Our approach so far has been temporary blocks (via ACL) of
 the target address. Blocking 8,000 internal addresses, many
 legitimate (secured) Web servers, generates more complaints.

 I'm thinking about a scripted Zebra feed where route
 injections are triggered by Snort. Routes for the target
 and/or SYN flood reflector hosts could be injected
 temporarily during the attack to border routers, which would
 route-map those routes to Null0. Script periodically
 withdraws routes to see if the attack is over (some of these
 last weeks, some only last a few seconds), to minimize the
 impact on those otherwise legitimate hosts.


This is a nice idea, anything 'scripted' is prone to abuse though ;( all
of a sudden www.your.edu is dead.. on class registration day no less.

 Has anyone tried this kind of an approach or any other type
 of automated/efficient approach to dampen the zombie side
 of the DDoS attack?

Re: Effective ways to deal with DDoS attacks?




On Wed, 1 May 2002, Pete Kruckenberg wrote:


 On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:

  and then again, there has been much discussion on simple
  DoS attacks, where the term DDoS is erroneously used...
  I am very much not trying to imply that this is the case
  here, but it's important that the two be thoroughly
  distinguished from each other - they are totally
  different things to deal with.

 Sorry, I should have been more clear.

 My issue (currently)  is not being the target of the DDoS
 attack, but being a (unwilling) participant. People outside
 our network are launching DDoS attacks (distributed SYN
 floods) against destinations outside our network, using
 about 8,000 Web server hosts on our network as reflectors.

Funny, you say 'secured' here...


 These are not zombies. They are secured, uncompromised Web
 servers. The attack spoofs the target address as the source,
 and one of our machines as a destination, port 80. Getting
 everyone to implement defenses (SYN cookies) on their Web
 servers is nearly impossible (most don't even have a
 defense--printers and routers with Web interfaces).


and here you say: printers and routers Since when did they need to be
accessible off campus? Additionally, why does a router need a web
interface?? Printers are on the cusp, but they certainly don't need to be
accesible from out of your LAN.

Re: Effective ways to deal with DDoS attacks?




On Wed, 1 May 2002, Basil Kruglov wrote:


 On Thu, May 02, 2002 at 04:45:43AM +, Christopher L. Morrow wrote:
  On Wed, 1 May 2002, Wojtek Zlobicki wrote:
  
   Where are providers drawing the line ?  Anyone have somewhat detailed
   published policies as to what a provider can do in order to protect their
   nework as a whole.
   At what point (strength of the attack) does a customers netblock (assuming a
   /24 for
   example) get null routed by whichever party.
 
  Most providers likely have a policy similar to: I can't sacrafice 1
  my network for 1 customer. So, if the attack is sufficient to degrade
  service on the ISP network most likely the customer under attack will get
  null routed.

 Are you saying UUnet, assuming for a sec that I am a customer of UUnet (just
 for the sake of the argument), UU will not null route my ircd if it
 it gets attacked on regular basis, say *daily* ?

I did not say that.


 Furthermore you are going to consistently place filters on your routers,
 take them out within the 24h (or whatever then-current policy of UUnet is)
 and track attacks back to their sources within the boundaries of your
 backbone on a daily basis? ;)


uhm... sure, we do this now... or have you not been paying attention?

 Will you do that for say a regular T1 customer or do I need more commitment
 as sales droids like to put it, to even consider such a service ? ;)


read above.

  Hmm, perhaps FIRST customers should insist that their ISP have some 24/7
  security contact that can actually help in the case of an attack. Today
  there are very few that have this capability. I'd say from personal
  experience that the number is way too small, even in the 'large' ISP arena
  :(
 
  More pressure from customers for real security would be a good start.

 sigh, tried and failed, miserably I might add.


Then become a UUNET customer cause we already do this... Perhaps other
providers with 24/7 security teams will pipe up to give potential
customers a heads-up on options other than UUNET? If you go with UUNET
please tell the sales driod I sent you cause then I get 50 bucks :) (my
only raise thanks to bernie)

Re: Effective ways to deal with DDoS attacks?

2002-05-01 Thread Pete Kruckenberg



On Thu, 2 May 2002, Richard A Steenbergen wrote:

 SYN packet comes in, one of these machines responses with a
 RST to the source, which is actually the target of the
 
 You have an interesting situation. I think rate limiting
 outbound RSTs would be the least offensive thing you
 could do, off the top of my head.

What about just blocking out-going RSTs altogether from our
borders? While this interferes with proper TCP
functionality, would it actually interfere enough to cause
noticeable problems? Would certainly be less of a burden on
routers than rate-limiting.

Pete.

Re: Effective ways to deal with DDoS attacks?