- Test - lists.nanog.org

[Fwd: [Fwd: More amplifier blocks]]
by Jan Czmok 01 May '98

01 May '98

1 0

RE: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!!
by Dennis Simpson 01 May '98

01 May '98

So that's how we wound up on your list! Please remove any addresses you have for us. We are quite diligent about this, and you are most welcome to test us for smurf sourcing any time. It should definitely not work. Current addresses: 205.189.200/23 205.210.186/23 206.130.244/23 209.212.32/19 Old addresses we no longer use and will be turning back in by June: 204.50.247/24 206.107.177/23 206.186.216/23 209.5.14/23 209.50.76/22 209.50.80/22 If you are smurfed by any our downstreams on any address belonging to one of our blocks, let us know, and we will take steps to prevent their being a participant in a smurf attack. Thx, dennis > From: NOC <NOC(a)mercury.balink.com> > To: "'Erik Muller'" <nc0773(a)corp.netcom.com> > Cc: "'nanog(a)merit.edu'" <nanog(a)merit.edu> > Subject: RE: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!! > Date: Thu, 30 Apr 1998 15:44:58 -0400 > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Erik, > > The script I wrote isn't really that smart... It just looks for two IP's > within the same /24 that were sending some kind of ICMP packet to the > victim machine. Since NetFlow logs don't break ICMP down to the type > and codes, I had to unilaterally make that decision. If your network is > clean, I sincerely apologize for any embarrassment or hassle this may > have caused, and I will remove it from the list. > > Regards, > Christian > > >-----Original Message----- > >From: Erik Muller [SMTP:nc0773@corp.netcom.com] > >Sent: Thursday, April 30, 1998 12:14 PM > >To: Martin, Christian > >Subject: Re: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!! > > > > > >> 163.179.230.0 > > > >This one's mine... the entire /24 is broken down as /30s, and .255 will > >respond with nothing more sinister than an ICMP unreachable. Any details > >on what results you saw that pointed to this network as an offender would > >be appreciated (since I can't see any danger from it). > > > >--------------------------------------------------------------------------- - > >Erik Muller, Network Engineer emuller(a)noc.netcom.net > >NETCOM Network Services Support NETCOM On-Line Communication Services > > > > > >On Wed, 29 Apr 1998, Martin, Christian wrote: > > > >> All, > >> > >> Here is my contribution to the block list. The script that generated > >> this will follow. It is 'public domain', in that it can be modified, > >> BUT, please give credit where credit is due! > >>

1 0

RE: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!!
by Douglas E. Pickett 01 May '98

01 May '98

> 199.243.210.0 Sorry, that's one of mine, but it should be fixed up now. Regards, Doug.

1 0

RE: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!!
by NOC 30 Apr '98

30 Apr '98

Erik, The script I wrote isn't really that smart... It just looks for two IP's within the same /24 that were sending some kind of ICMP packet to the victim machine. Since NetFlow logs don't break ICMP down to the type and codes, I had to unilaterally make that decision. If your network is clean, I sincerely apologize for any embarrassment or hassle this may have caused, and I will remove it from the list. Regards, Christian >-----Original Message----- >From: Erik Muller [SMTP:nc0773@corp.netcom.com] >Sent: Thursday, April 30, 1998 12:14 PM >To: Martin, Christian >Subject: Re: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!! > > >> 163.179.230.0 > >This one's mine... the entire /24 is broken down as /30s, and .255 will >respond with nothing more sinister than an ICMP unreachable. Any details >on what results you saw that pointed to this network as an offender would >be appreciated (since I can't see any danger from it). > >---------------------------------------------------------------------------- >Erik Muller, Network Engineer emuller(a)noc.netcom.net >NETCOM Network Services Support NETCOM On-Line Communication Services > > >On Wed, 29 Apr 1998, Martin, Christian wrote: > >> All, >> >> Here is my contribution to the block list. The script that generated >> this will follow. It is 'public domain', in that it can be modified, >> BUT, please give credit where credit is due! >>

1 0

RE: SMURF amplifier page
by Michael J. Freeman 30 Apr '98

30 Apr '98

stop the vanity. -----Original Message----- From: Jason Lixfeld [SMTP:jlixfeld@idirect.ca] Sent: Thursday, April 30, 1998 11:50 AM To: Jared Mauch Cc: Eric Germann; Karl Denninger; nanog(a)merit.edu Subject: Re: SMURF amplifier page Or, I particularly like this URL: http://if.you.on.this.list.youre.phucked.nether.net/smurf/ =) On Mon, 27 Apr 1998, Jared Mauch wrote: : You can take a look at : :http://puck.nether.net/smurf/ : : It's not filtered and copies the mcs page, graphics and all. : : - Jared : :On Mon, Apr 27, 1998 at 12:47:22PM -0400, Eric Germann wrote: :> Uhhh, is it just me, or does the below imply that if you are on the list, :> you can't read the page to find out :> :> a) you're on the list :> b) how to get off the list :> :> Kind of a catch-22 here, isn't it? :> :> :) :> :> Eric :> :> :> At 07:21 PM 4/26/98 -0500, Karl Denninger wrote: :> > :> >As promised, we now have a web page for this. :> > :> >The current smurf list is at http://www.mcs.net/smurf :> > :> >This will be updated roughly weekly, or whenever major changes are made :> >to the list of blocked networks. It contains, in addition to dialogue on :> >the Smurf issue, a list of network numbers and "whois" lookups on the :> >owners. :> > :> >IF YOU APPEAR ON THIS LIST YOU CANNOT TRANSPORT PACKETS INTO OUR :> >INFRASTRUCTURE. :> > :> >Instructions for what you must do to get the block removed are contained :> >within this page. Bitching and moaning is pointless - the only fix is :> >to FIX THE PROBLEM. :> > :> >Thank you! :> > :> >-- :> >-- :> >Karl Denninger (karl(a)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 :> > : :-- : Work: jared(a)qual.net - We Make The Internet Work for Your Business : 9-5pm(ET) 800 637 4424x2634 - 24x7 NOC - 800 424 3223 : pgp key available via finger from jared(a)puck.nether.net : -- Regards, Jason A. Lixfeld jlixfeld(a)idirect.ca iDirect Network Operations jlixfeld(a)torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------

1 0

Re: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!!
by Matt Ranney 30 Apr '98

30 Apr '98

Phillip Vandry <vandry(a)Mlink.NET> writes: [...] > Every router on there has had directed broadcasts disabled for a long time. > Only that network is a /25, so the broadcast address we are talking about > is 205.236.182.127. > > It turns out that not only does 205.236.182.255 unexpectedly function as > an alternate broadcast address for this network, but it is unaffected by > no ip directed-broadcast!!! We've seen this type of behavior as well, and on larger networks than /24's. On one /18 that we have, someone was sending to xx.xx.255.255, and it was heading to the first /23 that was allocated out of that block. The customer that was lucky enough to be the recipient eventually had to explicitly deny the 255.255 address because no ip directed-broadcast didn't stop it. -- Matt Ranney - mjr(a)ranney.com Let's not let the students run the High School.

1 0

Re: Two renumbering questions
by Mark Borchers 30 Apr '98

30 Apr '98

On 29 Apr 98 at 22:40, John R Levine wrote: > > > 1. I have a /24 SWIPed to me, 205.238.207.0. The ARIN listing doesn't say > > > it's non-portable, so can I take it with me? And if I do, how likely is it > > > that the new ISP's announcement will get installed in backbone routers > > > rather than filtered for being too long? It's right in the middle of the old > > > upstream's block 205.238.192/18. > > > > If you *own* the block, you can do anything you want with it. > > Well, there's the question -- I have no idea who owns it. Look it up in > ARIN, it says it's mine, but with contact info from epix, the old upstream. > Again, though, even if I own it, if the announcements don't make it into the > backbone it's not very useful, and I gather that some backbones now filter at > /19 except for the swamp. "Ownership" is not the word to be using. The 205.238.192/18 is ALLOCATED to Epix. Meaning: the are authorized to use the addresses or to assign them to someone else to use. The /24 is probably ASSIGNED to you. Meaning: you can be an end user of the addresses. The /18 is not registered with ARIN as non-portable, so the portability call is exclusively up to the administrator of that block.

2 1

Re: Router modifications to deal with smurf
by Tony Li 30 Apr '98

30 Apr '98

> Note that I'm not arguing that it *should* be the default, I'm just > arguing that vendors have implemented it this way because that's the way > they were told to in the RFC. Umm.... this is only partially true. As of the writing of 1812 (and predecessors), vendors had implemented it one particular way and argued that the spec should reflect the implementations. Of course, at the time, the net was a kinder, gentler place, and the threats of smurfing were not well known. Live and learn. ;-) Tony

1 0

FOLLOW ON TO BLOCK LIST
by NOC 30 Apr '98

30 Apr '98

All, Obviously these networks are atomic - the aggregates can easily be identified for the purposes of access-lists - unless someone wants to build a list with 1400+ entries... I will repost the list using aggregates in the context of the subnetworks involved, something like Aggregate xxx.xxx.0.0/16 Networks: x.y.z.0 a.b.c.0 g.e.f.0 etc...

1 0

feasability of stopping smurfs with cisco's CAR
by Marko Bukvic 29 Apr '98

29 Apr '98

Greetings, cisco's new Committed Access Rate feature lets you do real QoS rate limiting (as opposed to traffic shaping) with access lists. CAR could be implemented on either ingress/egress interfaces to limit bandwidth usage by ICMP to something safe like 5MBits. This would prevent an incoming ICMP flood from consuming your aggregation links, while it still might inconvenience a T1 customer. If placed on the outgoing access-list it can prevent your network from originating unfriendly amounts of ICMP. CAR can either discard or decrease the priority of the offending traffic. A couple of questions: I am unfamiliar with what tier 1 providers use as aggregation routers(routers their T3+ customers connect to). Due to CAR's potentially CPU intensive nature (when dealing with access-list based traffic limiting compared to address based limiting), would an "ICMP permit with exceed-action drop" filter constitute an unacceptable load on the CPU and memory of these routers? If I only had 1 multi-megabit transit pipe, is it reasonable(in the future) of me to ask/require my upstream provider to protect my pipe from being wasted by large amounts of ICMP? If I only put it on my side, the pipe still gets wasted. Are there any other vendors who offer a similar feature without the use of ATM? Thank you. Marko

1 0