[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DDoS Mitigation Survey

[ I've commented on some things that are not specific to DDoS - jtk ]

On Sun, 6 Mar 2005 00:04:03 -0800
Merike Kaeo <kaeo@merike.com> wrote:

> - Where does loose vs strict uRPF get used?

I personally only have experience with strict uRPF.  I suspect some
ISP networks that would have a multi-homed customer attached may use
loose.  I'm not sure, but my guess is that loose uRPF is just a slight
enhancement over the use of bogon filtering (where bogon in this case
means private, reserved and unassigned address space).  Since bogon
filtering will typically not catch routes that assigned, but not being
advertised, loose will add some additional spoof protection.

I've used strict uRPF on router interfaces that face a stub subnet.
That is, there is no router hop via this subnet that is not already
directly attached.  This last piece implies that the subnet may be
multihomed, which can also use strict uRPF, but you typically have
to poke a hole in the uRPF check.  Using a Cisco example, this would
look something like:

  ! routerA
  interface Ethernet0
   ip address
   ip verify unicast source reachable-via rx 100
  access-list 100 remark uRPF override
  access-list 100 permit ip any host
  access-list 100 permit udp any
  access-list 100 permit ip any any

  ! routerB
  interface Ethernet0
   ip address
   ip verify unicast source reachable-via rx 100
  access-list 100 remark uRPF override
  access-list 100 permit ip any host
  access-list 100 permit udp any
  access-list 100 permit ip any any

In practice you'd probably be using something like HSRP for a
multihomed subnet, which makes the config a little more complex, but
this is just for show.  Each e0 interface attaches to the same subnet
and they want to restrict source addresses using uRPF strict.  The
ACL is needed to allow packets to 'loop' around via one router, onto
the multihomed subnet to the other multihomed router's interface.
Traffic such as that does happen in certain configurations.  I also
added the multicast hack, in which if you have multicast routing
enabled, you'll effectively get the same thing happening.  Although
you could typically ignore those and just deny them, if you're
logging denies, they fill up the logs.

Strict uRPF is also very popular in campus environments to do source
based black holing.  So if in the above example I wanted to black hole
an address in, all I would have to do is route a more
specific to null.  Basically you're doing this sort of thing in your
router config:


but injecting your own more specifics of your address space to 'disable'
a host.  This is often used when you can't easily turn off a specific
port, because the host is on a shared port/network.  There is a more
specific write up of this application of uRPF here:


...and to plug a recent effort of mine, here is a web-based interface
to managing black hole routes.  If you look through the code you can
get an idea of some of the issues in deploying such a thing:


> - What (if any) is problem with using remotely triggered blackhole 
> routing?

Probably one of the biggest reasons for a network not deploying it
would be that the setup requirements outweigh the benefits.  This is
probably more likely to be true in smaller networks.  If you are to
receive your black hole routes from a 3rd party, there are the trust
and correctness issues as well.

> - Do triggers usually get deployed based on traffic filters to all 
> routers or are they BGP community based?

There seems to be a growing trend by ISPs to allow you to send a
route tagged with community '666', which will in effect black hole
the advertised route(s).  However if the DoS can't easily be stopped
via an address, then probably a custom packet filter on other header
details gets deployed at ingress points.

In a campus environment like mine where source-based black holing is
also useful and where you can black hole based on an address, my
preferred approach is to just setup a unique BGP route server that
looks like it's own AS, and have each internal router peer with it.
You can also just use your IGP.

> - Where are prefix filters vs AS filters used?  Why?

I've used prefix filters on peers to limit the number of routes I
am willing to accept from them.  This is just a hacky way of avoiding
problems if they leak above the configured threshold number of routes.
FYI... in my experience, this ends up just bringing peers down when
they grow without you knowing.

I've also used prefix filters to avoid getting various types of
unexpected routes (my routes or bogons) or routes that too specific.

Furthermore, I've used prefix filters in conjunction with dampening
policies to penalize or limit certain routes (see RIPE-229 - also of
questionable use).

AS filters may be used to remove private ASNs or obnoxiously long
AS paths.

> - Any other DDoS mitigation techniques which are deployed today?

I've heard that some ISPs will filter routes from their peers and
customers based exactly on the routes they expect to see.  Usually
this is through the use of a routing registry.  I don't know of too
many folks doing this though, because the setup and maintenance seem
to be relatively high for most.

Rate limiting select protocols or groups of protocols has been used,
particularly in campus networks.  For example, in a typical network
TCP is dominant.  Therefore, while TCP isn't rate limited, UDP, ICMP
and a handful of others may each be limited to 10%-20% of ingress
capacity or less.  Other protocols, that are simply not in use may
all be put in an aggregate rate limit or be blocked completely.
This can help minimize DoS attacks that use someting other than TCP.
Of course, doing this can be tricky.

There are all kinds of multicast hardening things that can be done and
might be an entirely separate document.  To give you an idea of what
one might do:


Some networks use a 'quarantine system' or a 'walled garden' approach.
This is a place problem hosts go.  In a nutshell, they have limited
connectivity and are typically used to help enable the end user to
'self-remediate' their way out of a problem.  This is often down with
VLAN, IP addressing and/or routing tricks.