 The
causes of denial-of-service attacks vary, but the results are always the same.
They hog your bandwidth and server resources so your servers can no longer perform
their functions. They’re annoying, usually anonymous, and costly in terms of lost
business. Don’t let the next DDoS attack affect your business – take steps now
to prevent lost uptime and reduced server capacity. Today’s article by Iljitsch
van Beijnum passes on some router filtering tips that might help you dodge the
next “big one.”
One final note before you get to the article – don’t forget to patch your Windows servers. A critical flaw in Windows 2000 that can cause buffer overflows (or worse) has been identified. It’s being exploited all over the Internet so it’s very important to take care of this problem quickly. Read the CERT Advisory here (http://www.cert.org/advisories/CA-2003-09.html), and even more important, get the patch here (http://microsoft.com/downloads/details.aspx?FamilyId=C9A38D45-5145-4844-B62E-C69D32AC929B&displaylang=en).
Enjoy the article (but patch those servers first)!
How to Get Rid of Denial-of-Service
Attacks
By Iljitsch van Beijnum
On August 10th I had the opportunity to talk about (Distributed)
Denial of Service (DDoS) at the Megabit 2002 event. I wanted to
show a new way to use standard routers and protocols to combat denial
of service. Unfortunately there wasn't enough time to really prepare
the test setup. I was unable to show conclusively that it works. I was
able to explain how it is supposed to work. I'm going to repeat that
part here and then talk about the Cisco router configurations that
make it all happen.
Network-based (D)DoS attacks boil down to a lot of unwanted traffic coming in,
which uses up either the available bandwidth, CPU time, memory, or some combination
of these. The idea is to filter out this unwanted traffic. This has to happen
as close to the source as possible, since the available bandwidth typically goes
down as the traffic gets closer to the destination. Filtering out traffic that
has already succeeded in completely filling up the link to an ISP isn't extremely
useful. This means in practical terms that the ISP has to configure a filter when
a customer is under attack.
Filtering Possibilities
How do we filter? We filter either on the source address, on the service, or on
the destination address. Filtering on the source address is the preferred way
to get rid of unwanted traffic: it catches only traffic from the attacker. Unfortunately
this approach can't be used very often. Attackers usually falsify or spoof the
source address in attacking traffic, with the result that the attack seems to
come from many different hosts throughout the net. Even when the source addresses
are real, in a distributed attack there may be so many of them that it's impractical
to configure a filter for all of them.
If you're lucky you may encounter an attacker who uses a single, inessential service
for all attacking packets. For example, some early DDoS tools used a single UDP
port for all attacking traffic. Smurf directed broadcast attacks by their nature
only create ICMP echo reply packets. In these cases the attacking traffic can
easily be filtered out by filtering a UDP or TCP port or by ICMP type. If the
attack uses unpredictable ports or ports that can't be filtered because they are
used for important services, it's not possible to filter on service type.
As a last resort, it's possible to filter out all traffic to the host or hosts
under attack in order to protect the rest of the network. This is usually possible
because most attacks are directed at a small number of hosts. If the attack is
directed at the entire network, filtering on destination address isn't possible.
Installing the right type of filter will get rid of most attacks. Unfortunately
this has to be done at a transit ISP, at least one hop closer to the core of the
Internet, so the attacking traffic doesn't overload the customer connection. This
is very inconvenient because it requires an ISP engineer to install the filter,
which often takes a long time. I propose incorporating mechanisms so customers
can do this themselves in the ISP network.
Destination Address Filtering
Let's start with filtering on destination address, which is the easiest to create.
An ISP can give a customer the necessary tools to do this by creating a BGP community
that routes traffic for the advertised address range to the null interface. The
customer then announces /32 routes with this black hole community
set, in addition to the regular address block announcements. All traffic for these
/32s is then sent to the null interface. A /32 is BGP-speak
for a single IP address, and communities are labels which indicate that special
treatment of some kind is desired. In this case, the special treatment is to throw
away all traffic that has this IP address as its destination. An admittedly Cisoc-centric
route map to accomplish this might look something like the following:
!
ip community-list 13 permit 65000:13
!
route-map customer-in permit 10
match community 13
set ip next-hop 13.13.13.13
!
This route map will set the next hop address for all routes with
the community 65000:13 attached to it to
13.13.13.13. (A community takes the shape of a 32 bit
value written as two values separated by a colon, where the first
value is often the Autonomous System number of the network that will
act on the community.) This route map must be applied to the customer
BGP session. This makes the router check for the community in all
routing updates received from the customer and change the destination
of the packets that match the route to the special
13.13.13.13 address. Then, on all routers in the network,
the 13.13.13.13 address must be routed to the null
interface and the packets will end up being discarded:
!
ip route 13.13.13.13 255.255.255.255 Null0
!
In the real world you would use an address out of your own address block rather
than the 13.13.13.13 address.
When this setup is in effect, all traffic directed to a black-holed address
is immediately thrown away as soon as it enters the network. Unlike regular anti-DoS
filters that are applied to customer interfaces, traffic is first transported
through the ISP network to the router connecting the customer, only to be thrown
out there. The main advantage is the customer can initiate filtering at any time
without any need for cooperation from the ISP. (Obviously, customers shouldn't
be allowed to announce addresses that aren't theirs with this black hole community,
or they could black hole addresses belonging to others. Regular filters on customer
BGP sessions should take care of this.)
|
|