On Fri, 12 Jun 1998, Michael Dillon wrote:

On Sat, 13 Jun 1998, Jon Lewis wrote:

...

I just recorded 4.5mb of a smurf attack directed at one of my servers. Here's a list of the networks used as amplifiers and the number of different hosts responding from each network.

This is not true! According to your list the following networks are *NOT* smurf amplifiers. Please check your data before blacklisting innocent people!!!

When did I blacklist anyone? Jim Flemming _is_ in my .procmailrc...so are you taking over for him? All I said was "here's a list of the networks used as amplifiers and the number of different hosts responding..." Obviously, any network responding with 1 ip is not terribly effective as an amplifier, but that doesn't alter the fact that the attacker attempted to use them as smurf amps. I should probably have trimmed all nets responding with fewer than 2 IPs since even a cisco with "no ip directed-broadcast" will generally respond with a source ip of the interface on which the echo request arrived. OTOH, these nets might want to consider additional filtering since they probably get abused in this way with some frequency. Every version of smurf.c I've seen has all the amplifier network addresses hardcoded. BTW...I have a theory for a way to get all or most of the big smurf amp networks fixed real fast...but doing it would probably get me in big trouble. Also...all the people cc'd on that message had nets with numbers of hosts responding in the dozens or more. ------------------------------------------------------------------ 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 Fri, Jun 12, 1998 at 11:45:16PM -0700, Michael Dillon wrote:

On Sat, 13 Jun 1998, Jon Lewis wrote:

...

BTW...I have a theory for a way to get all or most of the big smurf amp networks fixed real fast...but doing it would probably get me in big trouble.

Just find the amplifier nets and post their addresses here. Let someone else get in big trouble. The net result will be roughly the same. You do realize that 3l33t KrAkKeR d00dz monitor this list, don't you?

I actually hope that isn't what happens with my list that I posted a link to, I hope everyone just fixes their problems. but that's a bit too much wishful thinking, i realize. I in no way am condoning DoS attacks, they're very evil, (not counting the legality part). I hope that we can get ingress filters on people, and fix these both. One other thing, it would be interesting if someone started a smurf at a smurf amp. (I'm tired, but believe that can be done, but not going to think too much about it. The loop would be interesting, and require some fun intervention to fix). - Jared

On Sat, Jun 13, 1998 at 10:14:11AM +0200, Mikael Abrahamsson wrote:

On Sat, 13 Jun 1998, Jared Mauch wrote:

...

One other thing, it would be interesting if someone started a smurf at a smurf amp. (I'm tired, but believe that can be done, but not going to think too much about it. The loop would be interesting, and require some fun intervention to fix).

I think this is the way of the future when smurf amps get fixed. People will put these kind of things on hacked machines, sending spoofed floods to broadcast adresses locally. Since everybody seems to be going to switched nets this can create substantial amount of data.

I think the only way to solve this more permanently is to remove the response of ICMP data to broadcast adresses in the OS. Is anyone preassuring for this to happen? Is there a list of OS that actually does respond to ICMP to broadcast adresses?

Recent FreeBSD versions have an option to disable response to a broadcast ICMP. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

On Sat, Jun 13, 1998 at 09:19:13AM -0700, ken emery wrote: ==>Solaris also has this ability. You need to use /usr/sbin/ndd utility to ==>turn this off. The RFC's say that responding to directed broadcast should ==>be on (this has been hashed out here before) so the *nix vendors leave it ==>enabled in the default config. This is incorrect. The RFC (1122, section 3.2.2.6), states: --- An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded. DISCUSSION: This neutral provision results from a passionate debate between those who feel that ICMP Echo to a broadcast address provides a valuable diagnostic capability and those who feel that misuse of this feature can too easily create packet storms. --- There is no SHOULD in there. www.quadrunner.com/~chuegen/smurf.txt has a few OS vendors who have either turned replies off by default or have provided an option. /cah

On Fri, 12 Jun 1998, Michael Dillon wrote:

...

BTW...I have a theory for a way to get all or most of the big smurf amp networks fixed real fast...but doing it would probably get me in big trouble.

Just find the amplifier nets and post their addresses here. Let someone else get in big trouble. The net result will be roughly the same. You do realize that 3l33t KrAkKeR d00dz monitor this list, don't you?

Publishing information about smurf amplifier networks seems to work fine for now, albeit slowly. I've been running the Smurf Amplifier Registry for some time now, and it seems we have actually helped fix some networks. Here are the current statistics: 1119 networks have been probed with the SAR 369 of them are currently broken 61 have been fixed after being listed here I'm happy to report that the most severe smurf amplifier network I've seen until now today changed status to "fixed" in the registry (~1100 responses per packet)! :-) I think we are making a difference. And this is even before the more advanced functionality of the SAR has been implemented. In a short while it will be providing an incident reporting system as well as automated nag-mailing to potential contacts etc. of the listed smurf amplifier networks. I again urge those of you who want to participate in fighting against smurfing to please use this tool for all that it's worth. Please visit us and check out the listings and probe networks. If you see a network in there that you can help fix, then do it! The URL is: http://www.powertech.no/smurf/ And btw: A big hand to those of you out there who have helped me by showing interest in this, coming up with ideas and by actually using the SAR. Oystein Homelien | oystein@powertech.no PowerTech Information Systems AS | http://www.powertech.no/ Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333