4788310 2000-02-12 01:09 /142 rader/ Postmaster
Mottagare: Bugtraq (import) <9751>
Ärende: A DDOS proposal.
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <0002111514392V.02552@smp>
Date: Fri, 11 Feb 2000 13:23:36 -0800
Reply-To: Dragos Ruiu <dr@DURSEC.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Dragos Ruiu <dr@DURSEC.COM>
Organization: kyx.net
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
Panic Button, open trouble notification channel: Attack Defender
The appropriate place to suggest this solution was at the NANOG
meeting on DDOS but I didn't think of it before then so I thought
that a posting to bugtraq may float this proposal for public
discussion. The term ISP is used below to refer to any network
service provider responsible for connecting end user systems or
servers to the net.
The problem with DDOS:
- It is infeasible to secure the entire net.
- Scanners for DDOS daemons are being built but still require efforts
from uniterested parties to run the scans. Frequency of scanning will
be an issue too.
- The attackers are often systems that are unattended or neglected as
far as security. This makes it even harder to reach someone at the
site to stop the attack.
- The ones who are motivated to do something about DDOS are the
victims not the attack relays.
- The ISPs are also greatly motivated to ensure that their services
are not disrupted.
- The problem with disabling the attack is that the victim has to
contact many, many systems to notify them that they have been
breached and convince the administrators and take measures agains the
attacker software now embedded in their system.
As this is an industry wide issue, it is doubtful a single source
commercial antidote to all the potential DDOS problems can be found
with a single countermeasure. So I propose a collaboration between
service providers - an Anti-ddos ISP Coalition to remedy the problem.
The key issue I as I see it is one of notification, how do you notify
all the attackers that their systems are being detrimental to the
net. I suggest that we move the onus of solution to their service
providers. It has already been suggested that the ISPs that connect
the attacker-relays to the net may be culpable or liable for
damages... so they should be willing to expend some effort to resolve
the issue. There is already a push to educate about putting in proper
address filtering into provider routers, but this is not the full
solution because it will only hinder DDOS attacks based on spoofed
traffic. At dursec we have been testing DDOS effects for the last 8
months, and we've researched many DDOS techniques that do not require
spoofing, so address filters will not be a panacea solution.
One of the solutions we've been bandying about is some sort of
Emergency Broadcast Network like solution that would facilitate
communication during attacks or outages amongst service providers.
We would like to propose that an open-source, peer reviewed attack
notification system like this be developed. It would work like this:
- Each ISP(AS) that has an IP address block allocated to it would
maintain a publicly listed attack/outage notification point. - call
it the Attack Defender daemon. By my estimate and materials published
by Boardwatch there are less than 15,000 ISPs in the world so
keeping/distributing a central contact table listing address blocks
and contact would be feasible (similar to whois).
- Free client software would be distributed to the participating
(hopefully all) ISPs customers. This client software would
essentially be a red panic button for victims of a DDOS attack. When
activated it would use some sort of strong crypto authentication and
notify your local service provider's Attack Defender that an attack
is in progress. The notice would contain a small description of the
attack and a list of attack sources gathered by promiscuous sniffing
by the Defender client as well as a contact e-mail for the attack
victim. The client could also log traffic stats for future forensic
verification/tracing of the attack. Varous levels of automation are
possible.
-When an ISP customer triggers the Attack Defender panic button, and
notifies his service providers' Defender daemon, it will in turn
contact/notify the other well-known and publicly listed Defender
contact addresses of the ISPs/ASs/Owners of the address blocks that a
victim ISP's customer has filed a complaint about attacks coming from
their nets. That notification will contain the offending source
address(es) and contact info for the victim and their ISPs technical
support for subsequent verification.
-When the incoming complaints from other Defenders reach some
configurable(and likely site dependent) threshold level, the AS's
Defender will notify/alarm the attack origin ISPs technical support
crew, who would supposedly have contact information for the client
nodes that are doing the attacking. They could then notify, with
whatever strength of wording (:-) they feel is appropriate, their
customers that they must take additional security precautions and
hopefully provide assistance. There are numerous inherent DoS
opportunities in such a system so great care needs to be taken care
beween Defenders to use strong authentication. In addition,
guidelines should be drafted so no draconian penalties are imposed on
clients that have potentially spurious complaints filed against them.
I would suggest that no action be taken until mutliple complaints are
filed, and then some sort of attack verification process with the
victim be used before attack relays are notified/penalized. Systems
that are repeatedly/consistently used as attackers could be
filtered/disabled/penalized until approriate security improvements
are demonstrated to their ISP - thus providing the motivation for the
attack relays to care about the damage they are doing and to spend
the effort on better security.
-To stop this system from being used as a DoS itself, I would propose
that some sort of fine or other financial penalty be imposed for
false or improper complaints being filed (like the fines for pulling
a fire alarm).
Obviously, the coding work of developing such a system is trivial,
but the problems are all political and administrative. If this idea
is met with positive reception, I would even commit to developing the
open source software consortium here - I'm pretty sure we could have
it whipped up by next week - but the question really goes back out to
the technical planners at service providers: Would they would deploy
and take the appropriate measures to make such a system work. The
barriers on this are all political not technical.
I could start a mailing list to discuss this solution at
defender@dursec.com if there is sufficient interest and I would urge
all interested parties to participate. Feedback solicited either
here or via mail.... Is this idea feasible? Goofy? Realistic?
cheers,
--dr@dursec.com
--
dursec.com / kyx.net - we're from the future http://www.dursec.com
learn kanga-foo from security experts: CanSecWest - April 19-21 Vancouver
Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org,
RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD, Max Vision/whitehats.com
(4788310) ------------------------------------------(Ombruten)
4801382 2000-02-15 19:11 /155 rader/ Postmaster
Mottagare: Bugtraq (import) <9770>
Ärende: Re: A DDOS proposal.
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <0002120530263I.02552@smp>
Date: Sat, 12 Feb 2000 01:10:58 -0800
Reply-To: Dragos Ruiu <dr@DURSEC.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Dragos Ruiu <dr@DURSEC.COM>
Organization: kyx.net
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
Thank you all for your kind comments, offers of help and input about
my attack signalling system proposal. Here are some comments to the
comments:
Re: In-band vs. Out of band signalling
In our tests so far, though we've found some pretty devastating
attacks, none of the host targeted attacks has succeeded in producing
100% saturation/failure to the point where an outbound connection
with some determined re-try and process priority could be completely
defeated. My hypothesis at this point is that an in band
notification or signalling that would survive DoS could be built. If
not with TCP certainly with an aggressive UDP re-transmitter. You
will likely be able to squeak out that alarm packet eventually (even
with TCP I think). If anyone has some evidence to contradict this I
would love to hear about it. I estimate that out-of-band signalling
is -very- expensive (perhaps prohibitively). Let's save that for the
big e-commerce sites.
Having avoided the temptation (:-) to take out a whole bunch of
systems and try a test with a massive number of nodes our tests have
been limited to the small number (<10) of links we could cobble up
with our employee's home cablemodem/adsl links and other scrounged
systems and T1's from friends, but there seemed to be little effect
difference as we increased the number of nodes. DDOS seems to be a
bandwidth game, and he/she with the most bandwidth wins. If some
people would like to volunteer to set up a massive number of systems
in a testbed, we're game. We can even play target, but I may have to
talk to my ISPs and warn them. :-) C'mon, this is way more fun than
Seti@Home.
Re: DoS the victim and the relay Defenders simultaneously
One of the theoretical side effects of this quot;Defenderquot; system is that
there will be a big bull's eye painted on the Defender node - they
will likely become a target of choice so that you can get past them
and do some mischief. This is both good and bad, good because the
obvious target can be fortified and watched appropriately, bad
because it's, well.... a target. However DoSing the Defender will
hardly qualify as a stealth maneouver... when you see all that
traffic to it you will pretty much know that -something- is going
down. (And you -should- be watching.) I would be worried much more
about the stealthy clean up the complaints penetration.
Re: AI-driven attack sensing
There are a huge number of ways to wire this into advanced IDSes and
the like. I think there will be a lot of vendors who may wish to
differentiate themselves or improve their features in this way. I
was only proposing a rudimentary human operated triggering - you'd
think that only server operators would care enough about ddos and
uptime to go to the trouble of getting themselves wired into such a
system at first. I'm sure there will be lots of other clever ideas
here.
Re: Coding trivial
I didn't mean to downplay the difficulty of really securing an
app. But the effort here still seems dwarfed to the policy and
political issues to be overcome to make this work. A prototype is not
a long reach, I maintain.
Re: InterNIC whois as a contact instead.
First of all, for small companies they might work, but I've -tried-
on many occasions with more mundane portscans and attacks to contact
operators of servers attacking us to warn them about potential
compromises. My success rate is less than 10%. And you would be
surprised at the number of sites that are seemingly unreachable by
telephone (even some big ones). Then let's consider the language and
geography issues of attacks from different countries....
Another issue if you get attacked by forlorn.subgroup.megacorp.com
and you contact the whois for megacorp.com in likely a different city
is that it may take you a long time to reach the operator of the
attack system - if you can at all (sysadmins for large companies seem
to have developed the best telephone call avoidance technologies
around :-).
The other point here is that the ISPs Defender daemon would be able
to contact many sites en-masse (this is for -distributed- attacks) if
the other ISPs have a server listening for such requests. When was
the last time you tried to contact 100 server operators nevermind
1000? (Guys from Yahoo need not answer. :-) The idea is to distribute
the contact work to the ISPs responsible rather than saddling the
victim with the burden as we do now.
When I used to chase down attacks on our servers to warn sysops (I
don't anymore, declaring it futile), it would take me on the average
of a day per system if it worked, and I used to time out on it after
more than a day - which led to the abysmal success rate. Normally it
would take at least four phone calls before you got to someone who
understood what you were talking about. Maybe things are better now
with all this DDOS visibility, but I doubt it.
Re: RTBL and blocking
Yes, some extension may be feasible.... but the issue here is not
some voluntary opt in filtering, but squelching and securing the
origin of the attacks. Say I took over an address numerically just
below ddos poster child yahoo's dns server and another just above it
and installed my favorite super-nasty ddos tools. Most current
filtering facilities would likely have to block out a whole range of
addresses due to limits in the number of filters runnable with
reasonable performance, thereby making yahoo unreachable to your
users as well, sandwiched between those addresses. One of the points
of my proposal was to avoid blocking by going to a root of the attack
- the vulnerable attack relays - and notifiying their ISPs
automatically.
Then further you have to provide some incentive for them to care
about their security - another surprise to me was how often I
contacted sysadmins who really couldn't care less that their box was
broken into and attacking my system as long as their app was still
running, or, even more frequently, who didn't believe the info or
understand attack technology. Hopefully with my proposal, their ISP
upon receiving complaints about the user, will be able to have some
leverage on the user - otherwise one bad apple who doesn't care about
security could get a whole address range blocked off, in a way giving
another kind of DoS attack as that entire ISPs customer base may be
made unreachable to/from a chunk of the net. Without some
notification system, the ISP will never know the attack happened and
that they are being blocked - to them it will look like a whole chunk
of the net that is filtering them went mysteriously 404. (The revenue
loss implications of blocked customers are large for e-commerce.)
Blocking and filtering by itself will make the already flaky net more
so.
IMHO Though I do think an RTBL-like or derived blocking solution
would be a good incentive generator for ISPs that would choose to
ignore hypothetical inbound Defender complaints from other net users,
it doesn't strike me as a good solution in general. And there will
always be a few ISPs that ignore the guidelines is my bet - for
evidence I point to the difficulties of getting routing BGP
announcements to follow guidelines and the always-needed NANOG
tutorials. I doubt that we will ever completely mitigate DDOS - the
best we can hope for is to dramatically reduce the ridiculous ease
with which it can be done today. (Make'em work for their hack I
say. They have it so easy now. Why when I used to have to walk
through two miles of snow to hack on a 110 baud teletype... :-)
Unfortunately, I surmise this will require the tough road of securing
the obvious targets that will get taken over the most and do the most
damage. It would be interesting to see what wins the gets hacked the
most award....
Unless someone finds the magic silver bullet on this one, it's not
pretty, but I would still suggest we roll up our sleeves and start
getting to it. Sigh....
Again, thank you all for the valuable feedback,
--dr
--
dursec.com / kyx.net - we're from the future http://www.dursec.com
learn kanga-foo from security experts: CanSecWest - April 19-21 Vancouver
Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org,
RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD, Max Vision/whitehats.com
p.s. I really did walk through two miles of snow to use a 110 baud
teletype for a while. :-)
(4801382) ------------------------------------------(Ombruten)
4802363 2000-02-15 23:12 /74 rader/ Postmaster
Mottagare: Bugtraq (import) <9792>
Ärende: Re: A DDOS proposal.
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.10002120401140.23577-100000@sarah.home.blockdev.net>
Date: Sat, 12 Feb 2000 04:15:26 -0800
Reply-To: Matt <mickey@HOME.BLOCKDEV.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Matt <mickey@HOME.BLOCKDEV.NET>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <0002111514392V.02552@smp>
Appropriate quoting (I hope) follows.
The chief concern with DDOS attacks is, as Mr. Rulu points out, that
it is not feasible to protect the entire net. Morover, he is correct
that the solution he proposes would bring with it severe DOS and even
new DDOS opportunities, strong authentication notwithstanding. Of
course, the issues of international legal enforcement, liability, etc
are glossed over or ignored. In short, adopting a massive Panic
Button system, as suggested, would probably open more holes than it
would close, and many of the recommended remedies (fire alarm
penalties, for instance) would be difficult or impossible to enforce
in many circumstances.
The secret, I think, to limiting vulnerability to these sorts of
attacks, and limiting exposure, is to cause _someone_ (it doesn't
particularly matter who) to internalize the external costs of
protection. That is, since (say) the University of California at
Santa Barbara has less (theoretical) personal stake in detecting DDOS
agents on compromised clients, they will expend no effort to do so.
If they fully internalized the costs of the damage, however (if CNN
could, for instance, reliably collect the entire potential damages
due to loss of service), they would have a greater incentive. The
solution, then, becomes primarily technical- a reliable, trustworthy
means of identifying the author of a certain packet would need to be
obtained, so that packets could not be spoofed.
It should be remembered, too, that legal sanction against (for
instance) ISPs will be difficult to enforce in practice. My computer
doesn't much care, or notice, if it is being flooded by Rwandan
networks or Australian- service is just as denied either way. Legal
sanctions against foreign ISPs, however, are very difficult to
enforce. Sanctions would have to transcend law and political
boundaries meaning network wide isolation of offensive networks, not
liability assessments.
--Matt
On Fri, 11 Feb 2000, Dragos Ruiu wrote:
> The problem with DDOS:
>
> - It is infeasible to secure the entire net.
<DELETIA>
> As this is an industry wide issue, it is doubtful a single source commercial
> antidote to all the potential DDOS problems can be found with a single
> countermeasure. So I propose a collaboration between service providers -
> an Anti-ddos ISP Coalition to remedy the problem.
<DELETIA>
> . . . There are numerous inherent DoS
> opportunities in such a system so great care needs to be taken care beween
> Defenders to use strong authentication. In addition, guidelines should be
> drafted so no draconian penalties are imposed on clients that have potentially
> spurious complaints filed against them. I would suggest that no action be
> taken until mutliple complaints are filed, and then some sort of attack
> verification process with the victim be used before attack relays are
> notified/penalized. Systems that are repeatedly/consistently used as attackers
> could be filtered/disabled/penalized until approriate security improvements are
> demonstrated to their ISP - thus providing the motivation for the attack relays
> to care about the damage they are doing and to spend the effort on better
> security.
>
> -To stop this system from being used as a DoS itself, I would propose that
> some sort of fine or other financial penalty be imposed for false or improper
> complaints being filed (like the fines for pulling a fire alarm).
(4802363) ------------------------------------------(Ombruten)
4822674 2000-02-22 00:52 /155 rader/ Postmaster
Mottagare: Bugtraq (import) <9896>
Ärende: A DDOS defeating technique based on routing
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <200002201734.OAA18447@ns1.via-net-works.net.ar>
Date: Sun, 20 Feb 2000 14:33:44 -0300
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Fernando Schapachnik <fpscha@NS1.VIA-NET-WORKS.NET.AR>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
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
(4822674) ------------------------------------------(Ombruten)
4838851 2000-02-25 23:19 /133 rader/ Postmaster
Mottagare: Bugtraq (import) <9965>
Ärende: Re: A DDOS defeating technique based on routing
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <200002221732.OAA18546@ns1.via-net-works.net.ar>
Date: Tue, 22 Feb 2000 14:32:56 -0300
Reply-To: Fernando Schapachnik <fpscha@via-net-works.net.ar>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Fernando Schapachnik <fpscha@NS1.VIA-NET-WORKS.NET.AR>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
I'll summarize many responses my proposal has have and give my
thoughts about each one. Sorry for not been able to answer each one
individually. Not enought time ;-)
Let me first state that this was never meant to be a cure for every
situation. I think is only feasible in particular cases. I do agree
with most posts stating that to really solve DDOS we must attack the
problem at its roots: egress filtering. My proposal aimes to help the
ones that are being attacked.
Renaud Deraison <deraison@cvs.nessus.org> said:
> 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 +f+---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
If example.com is flooded with bogus network traffic (say, lots of
TCP RST) , then the link "f" that I added on your map will be flooded
anyway. So neither the stub network or example.com's border router
will receive all the data they should receive. So the attack is still
active.
---> Answer: it was just a graphic mistake. E and d should be
absolutely independent links.
=======================================================
Andreas Bogk <andreas@andreas.org> said:
> 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.
This will not help, as the ISPs border router is still flooded. You
could drop the BGP route for that network, but that is highly
undesirable: you would end up needing one BGP advertisement per
"important" server.
---> Answer: this solution is intendeed to site's whose ISP has
multiple links. Hopefully, the ISP total bandwidth is several times
the bandwidth it sells to its customer, and it uses some kind of
traffic shaping for each customer at the other end of its links, so
he could survive the attack. If the ISP can't survive the attack,
neither can its customers.
And BGP routes are a scarce resource, since they cost RAM in
everybody's border router: usually ASen try hard to announce as few of
them as possible, some aggregate all of their space to a single
announcement.
---> Answer: you would have to spend some resources in order to get
protection. ISP can aggregate routes at its borders, so nobody knows
that the route has been dropped (this is usefull is the ISP can
survive the attack) or can advertise each involved network
separatedly. The last option has the disadvantage you pointed out,
but the advantage of traffic being dispersed nearer its origin.
============================================
Many pointed out thinks like:
DNS records aren't instantly propogated to everyone (because of the
TTL). How do you make sure that clients are diverted to the proper
website?
---> Answer: Of course you have to use 0 (or very small) TTL DNS
records. Remember RFC 1034: "[...] a zero TTL prohibits caching
[...]".
===========================================
David Brumley <dbrumley@rtfm.stanford.edu> said:
If the DDOS attack was targeted at the router one hop before the web
server, you would have to move the whole subnet.
---> Answer: Yes, you are right. A solution might be for this router
no to respond to ICMP or traceroutes, so its IP does not become
publicly available.
===========================================
Many pointed out:
The attacker can switch its attack to the new network.
---> Answer: in this case he is creating a very particular traffic
pattern. He will be consulting DNS servers very often. The clients
can do it automatically, so surfing logs will show them, or even the
'evil master' behind the attack could make a mistake and consult them
often enough. If his software must attack and IP address (not a FQDN)
and he has some experience, he will consult DNS from one of the
comprised machines, but then again you can track him down from there,
as he must use real IPs to get to that machine.
===========================================================
Felix von Leitner <felix@convergence.de> said:
DDOS attacks normally saturate a, b and c as well, so this change will
only help dial-up users from ISP in general. The DDOS attacks that
struck Germany so far have always taken the whole ISP with them.
---> Answer: I'd really like to know if during these attacks ISP was
appling bandwidth limiting to the customer being flooded on the other
side of each of its Internet links.
Fernando P. Schapachnik
Administración de la red
VIA NET.WORKS ARGENTINA S.A.
fernando@via-net-works.net.ar
(54-11) 4323-3333
(4838851) ------------------------------------------(Ombruten)