what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

ddos-routing.txt

ddos-routing.txt
Posted Feb 24, 2000
Authored by Fernando P. Schapachnik

Distributed Deniel Of Service attacks - A proposal based on routing. This paper describes a technique that -hopefully- can be used to defeat the recent DDOS attacks. The solution presented here is bases on routing. It requires a certain amount of extra network infrastructure.

tags | denial of service
SHA-256 | d4db3368713cb2f7d6a456ebc627dd45e014bc76bf35def353db951d27f392a7

ddos-routing.txt

Change Mirror Download

Distributed Deniel Of Service attacks. A proposal based on routing.
-------------------------------------------------------------------
(version 1.0)

Disclaimer
----------

The opinions expressed here are mine only. My current employer does not
hold any responsability over them.

This is only a proposal that must be considered as _draft_ or _work in
progress_. It is made available to the Internet community as a contribution to
fight the DDOS threat. It is published as and 'thinking starting point' rather
than as closed solution.

Please be aware that assesments made here could be wrong. I'd love to
here corrections and refutals.

Abstract
--------

This paper describes a technique that -hopefully- can be used to defeat
the recent DDOS attacks. The solution presented here is bases on routing. It
requires a certain amount of extra network infrastructure.

Introduction
------------

Recent attacks to big Internet sites such as Yahoo and CNN has possed
a threat on Internet security. The problem with these DDOS is that packets
come from spoofed addresses and tracking the source becomes a very complex
task involving cross-AS cooperation and a huge amount of time.

Some measures have been proposed, but they are based on filtering
forged packets at the origin, and this means action by an -a priori-
uniterested party. Furthermore little has been proposed to stop attacks as
they are being produced.

This paper introduces a method that can be used in some situations to
avoid this kind of attacks in a short time fraim. It's efectivy increases if it
is combined with origin-analysis techniques.


Description
-----------

We will introduce the proposed technique by means of an example. Let's
suppose example.com has an important web site. During the scope of this paper
we will asume we are not interested on any other service than www, although
this method can be applied to protect another services (but not all of them).
Another simplification will be to assume that example.com has only one link to
the Internet.

We can draw example.com current infrastructure like this:

+--------+
-a--| | +---------------+
| | | | +-----------------+
-b--| ISP +-----d------+ example.com's +-----+ www.example.com |
| | | border router | +-----------------+
-c--| | +---------------+ \
+--------+ \ 10.0.0.2
10.0.0.1

Being: a, b and c the ISP links to the Internet, and d a link between the ISP
and example.com. Let 10.0.0.1 be the IP assigned to the internal interface of
the border router and 10.0.0.2 the IP assigned to www.example.com public web
server.

It can be argued that there must be a firewall in between, but this is
not relevant to the proposal.

The proposed technique is about changing the IP addresses of the hosts
being attacked and diverting the IP block under attack to a stub network
where traffic can be analyzed to track it down, or just dropped.

In order to be ready to a massive DDOS attack, example.com should
change its network structure to something like:

+--------------+
+----e-----+ stub network |
| +--------------+
+--------+ |
-a--| | | +---------------+
| | | | | +-----------------+
-b--| ISP +-+---d------+ example.com's +-----+ www.example.com |
| | | border router | +-----------------+
-c--| | +---------------+ \
+--------+ \ 10.0.0.2 and 10.0.1.2
10.0.0.1 and 10.0.1.1

+---------------+
| example.com's |
| DNS server |
| where |
| www=10.0.0.2 |
+---------------+

In case a DDOS attack against example.com is detected, the following
actions should be carried on:

1- dial up connection to example.com's externally located DNS server
(possible many of them in order to complicate DDOSing both www and DNS
servers) to make www.example.com point to 10.0.1.2.
2- phone call to ISP to route traffic to 10.0.0.x to the stub network and start
routing the 10.0.1 network.

These simple steps would divert the attack to a place where it doesn't
disrupts example.com functionality and where it can be tracked down.

Of course the attacker can notice the change, and:
a) attack also the new network. In this case his 'firing power' against each
network would be halfed. This opens the chance to example.com to have many
networks to be used for such cases. Hopefully, a sufficient number of networks
would make the amount of traffic received by each one large enough to be
handled by undelying infraestructure.
b) attack _only_ the new network. example.com can switch back to the old one,
or even a new one. Maybe this is the best move the attacker can made, but if
he does the comprised machines would create a pattern of traffic very easily
identified by a distributed network scanner that can consult a central site
for patterns and can _hopefully_ be run on periodic bases by ISPs concerned
about Internet safety.


Conclusion
----------

A method for defeating DDOS attacks on real time has been depicted.
This method is not bullet proof and requires a certain amount of extra network
infrastructure.

Publishing it in its actual form main purposed is having it enhanced
by the Internet community.



Fernando P. Schapachnik
Administración de la red
VIA NET.WORKS ARGENTINA S.A.
fernando@via-net-works.net.ar
(54-11) 4323-3333


Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close