Actions to quiet the Smurf amplifiers?
Hi, a few months ago there was quite a bit of talk about publishing known Smurf amplifier networks. I've been exchanging a few e-mails with one of the guys maintaining the smurf amplifier registry at http://www.powertech.no/smurf/ He tells me that since they started, several thousand entries have been fixed. However, the list is still quite a moutful (860KB in dense format, approx. 11.000 entries, no less!). It would appear that we (collectively) are not doing a sufficient job to remove this at times quite bothersome problem. One thing is that there's been lots of talk about preventing source IP address spoofing, but apparently not enough has happened there. Going after the networks being abused as amplifiers is quite a bit easier since they can be easily identified. Massaging the condensed list mentioned above and adding up the entries for the origin the route was seen with at the time the prefix was bound to an AS, the top of the (rather long!) list comes out as something like this: AS# Ampl. %ampl AS name AS174 6427 6.24 PSINet Inc. AS3561 4337 4.21 Cable & Wireless USA AS701 4152 4.03 UUNET Technologies, Inc. AS1239 2545 2.47 Sprint AS1 2372 2.30 BBN Planet AS568 2149 2.09 DISO-UNRRA AS2551 1721 1.67 NETCOM On-Line Communication Services, Inc. AS2548 1710 1.66 Digital Express Group, Inc. AS1785 1549 1.50 Sprint, Government Systems Division not-analyzed 1478 1.44 AS7018 1420 1.38 AT&T AS2900 1244 1.21 Arizona Tri University Network AS268 983 0.95 Uniformed Services University of the Health Sciences "Ampl." is the sum of the amplification factor for the amplifier nets that were announced with this AS number as the home AS in BGP when each prefix was bound to a BGP route. "%ampl." is the percentage of the total sum of the amplifier factors for all the networks in the list. Folks, it would seem that there's ample work left to inform your customers that they should take the necessary precautions to prevent their networks from being inundated with traffic by being exploited as an amplifier in a "Smurf" denial-of-service attack. It might be a good idea to point out that doing the work to prevent this from happening is also in their own best self-interest. Lastly, I'd like to get some idea as to how best to attack this problem -- the present method of "public list of shame" of the providers with the amplifiers as "local sources" is one method, but I'm far from certain that it will be effective. Comments appreciated. - Håvard
On Sat, 17 Oct 1998 Havard.Eidnes@runit.sintef.no wrote:
http://www.powertech.no/smurf/
He tells me that since they started, several thousand entries have been fixed. However, the list is still quite a moutful (860KB in dense format, approx. 11.000 entries, no less!).
It would appear that we (collectively) are not doing a sufficient job to remove this at times quite bothersome problem.
Last time I checked with them they didnt do regular checks of all nets. I believe that there might be a larger portion of the net being fixed than what the SAR reflects because of this. On the other hand, update checks might have been implemented the past 2 months that I dont know about... ----- Mikael Abrahamsson email: swmike@swm.pp.se
On Sat, 17 Oct 1998 Havard.Eidnes@runit.sintef.no wrote:
Lastly, I'd like to get some idea as to how best to attack this problem -- the present method of "public list of shame" of the providers with the amplifiers as "local sources" is one method, but I'm far from certain that it will be effective.
Finding some way to deny them routing until the problem is fixed, is the most effective means I can think of. (I dont mean a DoS attack, I mean some way of ignoring their route announcements). The last site I dealt with took _3 weeks_ to close their amplifiers once they were notified. And this was a multimillion dollar publishing company. -Dan
Dan Hollis wrote:
The last site I dealt with took _3 weeks_ to close their amplifiers once they were notified. And this was a multimillion dollar publishing company.
Wow, you sure get them to act quickly! How did you manage to get a big monstrous behemoth like "corporate america" to move that fast? :-) Solving technical problems does requiring a couple things. The first is the technical background to know what the problem is and how to deal with it. Usually the big corporations do have at least someone that knows this. The second is to get management approval. And managers do not understand things like smurf. They do understand things like lawsuits, and other financial incentives. In a few cases they can understand things like "we won't be able to communication with a large segment of customers due to being blackholed" when someone explains it to them in terms of $$$. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
On Mon, 19 Oct 1998, Phil Howard wrote:
Dan Hollis wrote:
The last site I dealt with took _3 weeks_ to close their amplifiers once they were notified. And this was a multimillion dollar publishing company. Wow, you sure get them to act quickly! How did you manage to get a big monstrous behemoth like "corporate america" to move that fast? :-)
They did nothing for two weeks, then their upstream threatened to pull their connection. If there were only some way to blackhole smurf amplifier routes globally... sigh. -Dan
Dan Hollis replied:
On Mon, 19 Oct 1998, Phil Howard wrote:
Dan Hollis wrote:
The last site I dealt with took _3 weeks_ to close their amplifiers once they were notified. And this was a multimillion dollar publishing company. Wow, you sure get them to act quickly! How did you manage to get a big monstrous behemoth like "corporate america" to move that fast? :-)
They did nothing for two weeks, then their upstream threatened to pull their connection.
If there were only some way to blackhole smurf amplifier routes globally... sigh.
There is. The method involves a software design change in the routers. For each arriving packet, in addition to doing a routing lookup based on the destination, also do a routing lookup based on the source address. If the interface the packet arrived on is NOT in the list of addresses that routing back to the source suggests, then discard the packet. That will drop the majority of packets before they even read smurf amplifiers, as they are generally forge-sourced to the ultimate target of the attack. The first router hop with this implemented where the source address is invalid will stop the attack. The core backbone probably does not need to have this enabled, but all the leafs from it should to ensure no forged sources can get through. I have access list filters in place that block all sources from other than my network space. I also block all incoming to *.*.*.255. There should be no smurf originations or amplications in my network (except non-forged from within, which we can deal with anyway, e.g. cancel, fire, prosecute, etc.). -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
At 02:19 PM 10/19/98 -0500, Phil Howard wrote:
I have access list filters in place that block all sources from other than my network space. I also block all incoming to *.*.*.255. There should be no smurf originations or amplications in my network (except non-forged from within, which we can deal with anyway, e.g. cancel, fire, prosecute, etc.).
You left off "maim, pillory, and mutilate" <grin> ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ I bet the human brain is a kludge. -- Marvin Minsky
On Mon, 19 Oct 1998, Dan Hollis wrote:
If there were only some way to blackhole smurf amplifier routes globally... sigh.
There is. It's been suggested several times in the past. All it takes is someone willing to maintain/distribute it as in the case of the BGP distribution of the RBL. Unlike the MAPS RBL, participation in the Smurf RBL wouldn't offer any protection...it just inconveniences the sites blackholed and anyone wanting to access those sites. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Mon, Oct 19, 1998 at 12:03:41PM -0700, Dan Hollis put this into my mailbox:
On Mon, 19 Oct 1998, Phil Howard wrote:
Dan Hollis wrote:
The last site I dealt with took _3 weeks_ to close their amplifiers once they were notified. And this was a multimillion dollar publishing company. Wow, you sure get them to act quickly! How did you manage to get a big monstrous behemoth like "corporate america" to move that fast? :-)
They did nothing for two weeks, then their upstream threatened to pull their connection.
I've found that CC:'ing uplinks on the first e-mail to smurf amplifier contacts works VERY WELL...I managed to get Santa Clara University (a site notorious for being smurf amplifier that ignored all attempts to get them to fix things) to fix their routers. Several others happily shut off their amplifiers, as well. When in doubt, add more addresses to the CC: line. I realize this ends up annoying the more clueful folks who actually read e-mail to things like abuse@, security@, noc@, etc, but unfortunately the less clued folks (whose only 'administrative' type account is webmaster@, if they even have that) seem to be more prevalent these days. (What was even more hilarious about SCU.edu was that they had the gall to mail me back saying this was the first they'd heard of the problem and that they had been working with their uplink to find out why their connection was constantly at 90% utilization....) -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) I bet living in a nudist colony takes Founder, the DALnet IRC Network all the fun out of Halloween. e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
participants (7)
-
Dalvenjah FoxFire -
Dan Hollis -
Havard.Eidnes＠runit.sintef.no -
Jon Lewis -
Mikael Abrahamsson -
Phil Howard -
Roeland M.J. Meyer