- Test - lists.nanog.org

RE: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> From: Troy Davis [mailto:troy@nack.net] > Sent: Tuesday, September 26, 2000 9:49 AM > > On Tue, 26 Sep 2000, Roeland M.J. Meyer <rmeyer(a)MHSC.com> wrote: > > > I know that all of you are aware of this. Granted, each subsequently > > smaller subnet also limits the maximum number of hosts that > will respond > > to the smurf trigger. The point is that, the web-site ONLY > tests 0 and > > Actually, that's often not the case. Through NAT and other modern > marvels, it's possible to have massively overpopulated netblocks that > all respond. The largest amplifier we've found yet was 170,000x (on > a class C). Thank you Troy, However my point remains.

2 1

RE: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> From: John Fraizer [mailto:nanog@EnterZone.Net] > Sent: Tuesday, September 26, 2000 9:43 AM > > On Tue, 26 Sep 2000, Roeland M.J. Meyer wrote: > > > Defense is a lot less socially antagonistic than offensively BGP > > black-holing antire IP-blocks (which can get you seriously sued) and > > creating more outages than we already have to suffer through. > > Roeland, > > The last time I checked, AS65535 (picked for obvious reasons) does not > have a transit contract in place with my company and as such, has > absolutely NO grounds to sue me if we choose to blackhole > routes to them > at our borders. > > No transit contract -- no guaranteed transit. It's just that simple. The operative would that I used was "can" and not "will". However, you don't discount my statement about blackholing creating artificial outages. I am proposing a more surgical response to the smurf threat. One that in no way creates outages and may be more socially acceptable. You also missed the point that a IP-block can pass the netscan.org test and STILL be a smurf amp via it's subnets. The subnet bcast addrs aren't hard to find.

1 0

RE: netscan.org update
by Roeland M.J. Meyer 26 Sep '00

26 Sep '00

> From: Daniel Senie [mailto:dts@senie.com] > Sent: Tuesday, September 26, 2000 8:45 AM > "Henry R. Linneweh" wrote: > > John; > > "The SMURF problem is years old. People who don't look for > this on their > > own networks and prevent it before it starts are AS MUCH if > not MORE a > > part of the problem as the script kiddies". > > Implementing RFC 2827 (ingress filtering) and RFC 2644 (disabling > directed broadcast) is more than just a nice idea. These are > both BCPs, > since they both represent methods for limiting damage to the Internet. I've been following this thread since the first time it came around. In the last round, the point was made that 0 and 255 weren't the ONLY b'cast addrs in a /24. In fact they aren't, over here (MHSC.NET) Our /24 is so sub-netted. In fact, one can have up to 64 b'cast addrs in a /24. I know that all of you are aware of this. Granted, each subsequently smaller subnet also limits the maximum number of hosts that will respond to the smurf trigger. The point is that, the web-site ONLY tests 0 and 255 and y'all are discussing filtering on ONLY those values. This is inadequate for what you are trying to do. A /25 can still yield 127 host respnses and a /26 will yield 63 host responses, and so on... Discovering these b'cast addrs isn't difficult either and I'm sure that the script-kiddees already have a means to do so. Had I the time, I could write the code, the algorithm is trivial. The last time this came around I suggested a means that would work. It involves making entries in your in-addr.arpa file that lables each base and b'cast addr. As an example, I have done this to my own file and have been maintaining it for years. Once put in place, it is simple to maintain. Generally, subnet assignments don't change that much (scale = years). The upstream should filter any and all packets going to those addrs, at the gateway. This can be made a part of the contract, with downstreams that manage their own IP and DNS space (like MHSC does). I've actually considered a script that reads the ARPA file and generates ipchains commenads to automagically put the proper filters in place. Again, it isn't that hard. The specific file I am talking about is "175.108.199.inaddr.arpa", dig at your local BIND for the auth server NS1.MHSC.NET. Base addrs are labeld "base" and b'cast are labeled "bcast" (duh). There are various means to implement this, I can think of 1-2 others without really trying. The point is that, if you're going to do this, do it right. Defense is a lot less socially antagonistic than offensively BGP black-holing antire IP-blocks (which can get you seriously sued) and creating more outages than we already have to suffer through.

3 2

HR 4445 Reciprocal Compensation (fwd)
by multics＠ruserved.com 26 Sep '00

26 Sep '00

I've been thinking about this and I think the CLECS and ISP's might be benefitted by the passing of this. I think this bill will do more to hurt the ILECS then help them in the long run. One of the things blocking CLECS from offering local dial tone for residential service is the reciprical compensation. The single biggest item contributing to it is internet dialup. As an example of what I mean: AT&T had been heavily advertizing to get people to select AT&T for local dialtone in my area. The ads all say unlimited, but the fine print limits this to 75 hours a month. I would suspect the limit is due to the amount of usage from modem users dialing into the internet. If this bill passes, I suspect AT&T will take advantage of that and ammend their ads to 75 hours, intenet dialup unlimited. Why should someone who spends alot of online hours on the internet even consider AT&T with the 75 hours/month limit? Once this bill passes, any company interested in offering local dialtone wil no longer have to worry about internet connect time causing large reciprical compensation. I suspect AT&T and other CLECS who are providing or interested in providing local dialtone to residential customers are backing this bill. The short term result may be bad for any CLEC depending on the income, but those that are looking to providde local phone service will find this a great benefit and as a result this is more likely to lead to local dialtone competition against the ILEC. Which will lead to lower costs for phone lines ;) As best I can see, the ILECs tend to be the more incompetent competitors and maybe they will finally put themselves out of business with this encouragement to their compitition. If I had the money, I'd start some planning now to put up my own CO's and lay my own copper/fibre/etc for providing local services. -- Richard Shetron multics(a)ruserved.com multics(a)acm.rpi.edu NO UCE What is the Meaning of Life? There is no meaning, It's just a consequence of complex carbon based chemistry; don't worry about it The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.

6 5

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

26 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