Bugtraq mailing list archives

A DDOS proposal.


From: dr () DURSEC COM (Dragos Ruiu)
Date: Fri, 11 Feb 2000 13:23:36 -0800


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



Current thread: