September 2000 - Test - lists.nanog.org

Re: netscan.org update
by John Payne 25 Sep '00

25 Sep '00

On Mon, Sep 25, 2000 at 12:49:15AM -0400, Patrick W. Gilmore wrote: > I actually think that filtering prefixes such that you cannot send traffic > *to* smurf amplifier networks would help, and be far less expensive (CPU > wise). It would be trivial to null-route amplifier prefixes, and if enough > networks subscribed to the service, the amplifier sites would notice very, > very quickly - in much the same way people on the BGP RBL notice. My thoughts are that the "SAL" is operated in a similar way to the RBL, except that education comes *after* listing :-) ie.. once a smurf amp has been *abused* and reported to the network operator, it gets listed. Further reports of abuse of that amp (because listing it won't stop attacks) will result in widening the listing, until it really starts to hurt. -- John Payne http://www.sackheads.org/jpayne/ john(a)sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header

1 0

RE: CEF RPF check w/ACLs (was: Re: netscan.org update)
by rdobbins＠netmore.net 25 Sep '00

25 Sep '00

Very cool - thanks much for the info! -----Original Message----- From: Tony Tauber [mailto:ttauber@genuity.net] Sent: Monday, September 25, 2000 12:31 PM To: Roland Dobbins Cc: Bradley Dunn; John Fraizer; nanog(a)merit.edu Subject: CEF RPF check w/ACLs (was: Re: netscan.org update) On Mon, 25 Sep 2000, Roland Dobbins wrote: > Bradley Dunn wrote: > > > > On Mon, Sep 25, 2000 at 03:31:53AM -0400, John Fraizer wrote: > > > In a BB situation and in some simple multihomed situations, it is possible > > > for someone to have a route into your network via an interface that for > > > administrative/technical reasons, you're not accepting routes to them via. > > > In such instances, CEF will break an otherwise valid, though be it > > > asymetric stream. > > > > You are confusing CEF, a switching path, with > > 'ip verify unicast reverse-path', > > an interface configuration command which requires CEF. > > > > In any case, recent flavours of IOS support using an ACL to > > specify exceptions > > to the reverse-path check. > > > > Bradley > > Now =this= I'm familiar with. ip verify unicast reverse-path causes > massive problems when you're multihomed. > > By 'recent', I assume you mean 12.x? > It came later. It's in 12.0(9.3)S for sure. I was the one who asked for something like it and a friendly developer coded it up nice and quickly. One simple way to use it: If a customer is multiply homed, make up an access-list including their prefixes as source addresses and use it as ip verify unicast reverse-path <acl> so that you can permit packets with those sources even though they might fail the generic RPF check. You already know your customers' prefixes because you're either statically routing them or filtering the prefixes they can announce to you dynamically (right?) One could note that a regular packet-filtering ACL inbound on the customer's port could achieve a congruent functionality. That's probably true. In this case, I had a different idea in mind when I asked for the feature but this is what came out. FWIW. Tony

1 0

Test "BlackHole" Amplifier Route Server....
by dies 25 Sep '00

25 Sep '00

Hello, I have a test "blackhole" route server that will pass out the top 2000 amp sites from netscan.org and the top 4000 amp sites from pulltheplug.com via BGP. After the routes get passed it is very simple to discard/dump/null-route/etc the traffic going to the amp sites. This will only be useful for those who wish not to launch smurf attacks. This will not stop a smurf attack from coming down your pipe/pipes. If you are interested in testing this, please respond off list. I have tested this blackhole route server on a cisco 7513, 12008, and Juniper M20. It works and the configuration on the other end (Yours) is very simple and minimal. Thanks.

1 0

RE: The Backhoe Summit
by Sean Donelan 25 Sep '00

25 Sep '00

On Sat, 23 September 2000, John Fraizer wrote: > On 23 Sep 2000, Sean Donelan wrote: > > On Sat, 23 Sep 2000 rdobbins(a)netmore.net wrote: > > > Do the large carriers now participate in 'one-call' operations like power > > > and gas companies do? At least in Virginia a couple of years ago, they > > > didn't. It might be a good idea for them to do so. > > > > "For competitive reasons we can't tell you the location of our fiber." > > > > - An anonymous representative of a very large telco > > Wow. They must not have any fiber near our facility. The folks running > the digging operations are keeping Plastikote in business selling orange > paint. There seems to be more orange than black on the blacktop -- all of > it marked pretty clearly with the carrier name. Ask them for a map. Yeah, I know a lot of folks have resorted to calling OneCall, getting the street painted orange, and making their own maps.

4 3

Re: CEF RPF check w/ACLs (was: Re: netscan.org update)
by Danny McPherson 25 Sep '00

25 Sep '00

> One could note that a regular packet-filtering ACL inbound on the > customer's port could achieve a congruent functionality. > That's probably true. In this case, I had a different idea in mind > when I asked for the feature but this is what came out. Right, the latter is nothing more than a standard packet filter. Ideally, on could employ the same policy used for route filtering from a peer (perhaps generated via IRR or other similar mechanism) to perform source address 'authorization' in the forwarding path. Given, the practicality of performing these functions in hardware today is, well, interesting.... If this were widely supported and deployed (especially inter- domain), IP spoofing DoS attacks would largely be a thing of the past. Of course, if prefix filtering and/or ingress packet filtering were widely deployed even at the edge, this would largely be a thing if the past. This is one of the things that we plan to discuss during the "Service Provider Route Filtering" panel @NANOG. -danny

1 0

Re: netscan.org update
by Michael Shields 25 Sep '00

25 Sep '00

In article <20000924175334.A46043(a)ussenterprise.ufp.org>, Leo Bicknell <bicknell(a)ufp.org> wrote: > A large part of it is probably that very few administrators > set of warning bells on a single ping, but a substantial fraction of > mail administrators get floods of e-mail warnings from the mail testing > programs, wasting their time and energy. > > When you scan properly locked down boxes in a way that fills > an admins mailbox they get testy. http://www.nfr.net/forum/publications/id-myths.html -- Shields.

1 0

Telemarketing
by Susan R. Harris 25 Sep '00

25 Sep '00

Hi everyone - we've received reports that some of you have received calls from telemarketers saying they are from NANOG and want information on attendees. We want to note that these calls are in no way associated with Merit Network, Inc., or other NANOG staff. Susan R. Harris Merit Network/Univ. of Mich. (734) 936-2100

1 0

RE: The Backhoe Summit
by owen＠dixon.delong.sj.ca.us 25 Sep '00

25 Sep '00

> On Sat, 23 Sep 2000 rdobbins(a)netmore.net wrote: > > Do the large carriers now participate in 'one-call' operations like power > > and gas companies do? At least in Virginia a couple of years ago, they > > didn't. It might be a good idea for them to do so. > > "For competitive reasons we can't tell you the location of our fiber." > > - An anonymous representative of a very large telco > - Almost every representative of every large telco I've ever talked to about this subject. Owen

1 0

Looking for colo space in Denver email me direct...
by Rich Sena 25 Sep '00

25 Sep '00

-- In a brood of blind back biting vipers... ...the one-eyed snake is king! Rich Sena -.~~~ssssSSSSiSSSSssss~~~.- ras(a)thick.net

1 0

Re: netscan.org update
by John Fraizer 25 Sep '00

25 Sep '00

On Mon, 25 Sep 2000, Patrick W. Gilmore wrote: > > At 02:01 PM 9/24/2000 -0700, Bill Woodcock wrote: > > > >It's sounding like what we're working our way around to is that two > >separate BGP feeds would be needed: <SOAPBOX> OK... In typical engineer fashion, we're all over-engineering this. Even if we do manage to set up a RBL style BGP feed, all this will do is limit OUR ability to reach the SMURF-friendly networks. That's the wonderful thing about BGP. You can limit what you accept but, once you hand an announcement to someone, there is no real way to say "announce this to everyone but the SMURF-friendly networks." So, what we end up doing is limiting the damage done by a smurf attack. Unless you're running CEF, your router is going to pass traffic destined for networks you're announcing to those networks. I have yet to find an easy way to implement CEF on the border that doesn't break something in some funky way or another. What needs to happen (and most likely won't... I'll grant you that) is that we need to begin dropping peering sessions with those ASNs that host smurf amplifiers and refuse to do anything about it. Networks who host stub sites who refuse to do anything about their smurf activities need to flat out DROP those customers! When the smurf sites can no longer connect to anyone because either they or their transit provider has been dropped by the rest of the world, they can't cause any damage to anyone else. Like I said above, I doubt this will happen because there are far too many pointy-head types and bean-counter types vs engineer types. Since we _know_ that the obvious solution will _NOT_ happen on a large enough scale to really make any impact, there is something that we can ALL do to prevent the problem from getting any worse. 1) If someone is connecting to your network for transit, make sure that, at a minimum, their router is configured for no ip directed broadcast. 2) Make sure that your AUP has provisions for disconnecting a customer who is causing network disruptions AND DISCONNECT THEM WHEN THEY ARE!!! 3) Make sure your AUP has provisions to drop a customer like a bad habbit if they have multiple "accidental misconfigurations" that cause network disruptions. 4) Make sure that there is room in your bi-lateral peering agreements for you to drop the session when you're seeing SMURF traffic from a peer and KEEP IT DOWN until they fix their problem. DON'T TAKE THEIR WORD FOR IT! TEST IT YOURSELF! When someone has to buy transit to you to smurf you via a free/inexpensive bi-lateral peering session, it WILL get their attention. Folks, we build and run the internet in North America and parts unknown. I'm NOT advocating that we adopt an elitist attitude. We do however have the power to make it painful/expensive for those who don't play by the rules. It's time for us to USE IT! Simply blocking crap at our borders does not prevent it from makeing it to our borders and clogging the pipe/cpu at the borders. If collectively we refuse to put up script kiddies and networks that provide safe havens for them, we will no longer have to deal with them. Tell me... Has anyone heard of anyone from the US "tagging" in Singapore? Hell no. They made an example. They don't put up with that crap. I would MUCH rather someone spraypaint the front of our NOC than throw 300Mb/s of ICMP towards us. Perhaps if we all started hiring an "enforcer" for our AUPs who "visited" problem clients, they would go away. It's time to take a tough stand against SMURF-haven networks/clients. We DON'T want their business and we DON'T want to peer with them. We DO want them to get their act together and fix their networks/customers. It's just that simple. Like most things in life, I'm sure that this is far too simple to catch on. Something has to be complicated for people to appreciate the beauty generally. </SOAPBOX> --- John Fraizer EnterZone, Inc

1 0