April 1998 - Test - lists.nanog.org

Re: SMURF amplifier block list
by shields＠crosslink.net 13 Apr '98

13 Apr '98

In article <Pine.BSI.3.93.980412085359.7879a-100000(a)sidhe.memra.com>, Michael Dillon <michael(a)memra.com> wrote: > If Karl will supply us the IP address of a non-critical machine in his > network then we only need one list maintained. Anyone can then add new > networks to Karl's list simply by smurfing his non-critical machine and it > will still meet his criteria of a verified atack. Careful. I could, from a well-connected machine, launch a stream of forged ICMP echo replies from various 199.166.227.x addresses. This would cause it to look like junction.net was the source of a smurf, and cause them to be blocked. Well, in the case of junction.net, there is no such forgery needed. ~$ host www.memra.com www.memra.com A 199.166.227.56 ~$ ping 199.166.227.255 PING 199.166.227.255 (199.166.227.255): 56 data bytes 64 bytes from 134.87.109.226: icmp_seq=0 ttl=243 time=110.2 ms 64 bytes from 199.166.227.41: icmp_seq=0 ttl=51 time=111.0 ms (DUP!) 64 bytes from 199.166.227.32: icmp_seq=0 ttl=242 time=112.2 ms (DUP!) 64 bytes from 199.166.227.54: icmp_seq=0 ttl=51 time=112.8 ms (DUP!) 64 bytes from 199.166.227.5: icmp_seq=0 ttl=51 time=113.7 ms (DUP!) 64 bytes from 199.166.227.27: icmp_seq=0 ttl=51 time=114.3 ms (DUP!) 64 bytes from 199.166.227.22: icmp_seq=0 ttl=51 time=115.0 ms (DUP!) 64 bytes from 199.166.227.1: icmp_seq=0 ttl=51 time=115.7 ms (DUP!) 64 bytes from 199.166.227.12: icmp_seq=0 ttl=242 time=116.4 ms (DUP!) 64 bytes from 199.166.227.19: icmp_seq=0 ttl=51 time=117.0 ms (DUP!) 64 bytes from 199.166.227.21: icmp_seq=0 ttl=242 time=117.7 ms (DUP!) 64 bytes from 199.166.227.28: icmp_seq=0 ttl=51 time=118.3 ms (DUP!) 64 bytes from 199.166.227.26: icmp_seq=0 ttl=242 time=119.0 ms (DUP!) --- 199.166.227.255 ping statistics --- 1 packets transmitted, 1 packets received, +12 duplicates, 0% packet loss round-trip min/avg/max = 110.2/114.8/119.0 ms -- Shields, CrossLink.

6 5

NANOG topics so far
by Susan Rebecca Harris 13 Apr '98

13 Apr '98

Greetings - here are topics we've lined up so far for the June NANOG: - Differentiated Services Panel: Working Group Update and Viewpoints From the Community (Kathleen Nichols, Bay Networks, moderator) - The National Internet Measurement Information (NIMI) Project (Vern Paxson, Laurence Berkely Lab) - Scaling BGP (Yakov Rekhter, Cisco) - ARIN Update (Kim Hubbard, ARIN) - InterNIC Update (Mark Kosters, InterNIC) - Path and Round-Trip Time Measurements: a New Project at CAIDA (Daniel McRobb) - Implementing Simplex IP Bandwidth Augmentation and IP-Based News and HTTP Broadcast Services via Geosynchronous Satellite (Avi Freedman, Net Access) - Introduction to the NETPERF.NET Inter-Provider Network Performance Monitoring Project (Avi Freedman, Net Access) Additional presentations will be posted at www.nanog.org . Are there other topics you'd like to hear about? ------------------------------------------------------------------------- Susan Rebecca Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

Re: SMURF amplifier block list
by Chris Liljenstolpe 13 Apr '98

13 Apr '98

Greetings, I was just thinking the same thing. In general, I hate (as I'm sure everyone else here does as well) cutting connectivity, but this appears to be the only way to fix the problem. The RBL (or something architected like it) would be a very clean way of doing it.... Chris --On Sunday, 12 April, 1998, 00:54 -0400 "Jon Lewis" <jlewis(a)inorganic5.fdt.net> wrote: > On Sat, 11 Apr 1998, Sean M. Doran wrote: > >> And consequently increases the liklihood that more networks >> will refuse traffic to or from these networks, which in turn >> increases the pressure on these sites to wonder what is happening >> to their connectivity and how to repair it. Which may just solve >> the problem. >> >> This is a monumental admission: I think Karl is doing the right thing. > > Would the vix people have any interest in just adding "being a smurf amp" > to the possible causes for entry in the BGP version of RBL? That way, it > would be harder for the smurf d00dz to get up to date lists. > > I suggested this sort of thing a while ago, but don't currently have time > to implement it. The vix people already have everything in place. > > ------------------------------------------------------------------ > Jon Lewis <jlewis(a)fdt.net> | http://noagent.com/?jl1 for cheap > Network Administrator | life insurance over the net. > Florida Digital Turnpike | > ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____ CChris Liljenstolpe - Principal Engineer - worldwide solutions, Inc. Currently under contract to the US Antarctic Prog., McMurdo Stn. Antarctica mailto:cds@wwsi.com http://www.wwsi.com TEL(303)-581-0800 FAX(303)-530-0191 worldwide solutions, Inc. Ste 100, 4450 Arapahoe Ave, Boulder CO, 80303 USA

1 0

Re: Fixing RFC's WAS Re: SMURF amplifier block list
by Scott Bradner 12 Apr '98

12 Apr '98

-- > Is there a review of the Router and Host requirements RFC's in the works? > Specifically, to review those areas which could be changed to fix some of > these problems. -- There are a number of RFCs that it would be good to update (I'd point to 1122 & 1123 before RR) but it takes someone with lots of time and energy to take on one of these big ones - if you know of someone who is willing to do the work and has the time a number of us on the IESG would love to know. Scott

2 1

Re: [nanog] Re: SMURF amplifier block list
by Sean M. Doran 12 Apr '98

12 Apr '98

Uhm, all that is necessary is for Karl to tell people what he's blocking on his network in such a way that anyone else wanting to protect themselves in the same way can so configure their routers. Ironically, this closely parallels the Satanic Phyltres, with similar sets of plusses and minuses. The idea of some permanent coordination is disconcerting in two ways: firstly, it assumes that the problem is permanent (which I doubt), and secondly, the idea of there being a central administration for policing the network seems to to be incompatible with the theory that the Internet is fundamentally ungovernable. Essentially, if "they" shouldn't bother to try, because it won't work, why should "we" bother to try? Sean.

1 0

Re: SMURF amplifier block list
by barton＠cent.net 12 Apr '98

12 Apr '98

> The following networks and masks are banned from our network at the core due > to being smurf amplifiers. The earlier suggestion to use the vixie blackhole system was rebuffed because the volunteers are just that, and already overworked. But re-using the existing infrastructure with suitable controls and a modest amount of cooperation and agreement has enormous potential. Using communities should be the key to safely adding different hit-lists to AS-7777 feeds. If current recipients of AS-7777 feeds could all simply add tests for specific communities to the existing route-maps being used to implement the black-holing, many different filters with even radically different policies can coexist on the same feed and each site can select which lists it chooses to use. The vixie folks could take additional feeds from selected 3rd parties and suitably tag these with the necessary communities, and yet not have to actively maintain the additional lists themselves. Paul's original list could be 7777:1, and perhaps the unsassigned address blocks should be 7777:2. Karl's list could be 7777:3 Problem areas would be when the same network is on several different hit-lists and needs the communities of each, and the fact that I believe the version of GATED Paul & Co. is running does not support communities. A simplifying rule might be that if a network were already on Pauls list(s) and tagged with 7777:1 or even combinations of communities Paul maintained, it simply would not be propagated with the addition 7777:3 community or whatever used for Karl's list. If it dropped off Paul's list(s), Karl's feed tagged 7777:3 would then be used. Perhaps the newer version of gated Paul hadn't yet installed a while ago solves all this, or perhaps someone has an idle cisco to loan/give Paul that could enable using communities with low impact on the volunteers. I wonder how many of the current recipients can handle adding a community list and then a match statement into their current black-hole route-map so it only does the current function despite additional lists being added, and if any remaining recipients unable or unwilling to deal with communities would mind using the additional filtering. Subject to the current legal agreements Paul demands, perhaps Karl could take Paul's current feed, the list of folks already signed up and authorised for the feed but that want MORE lists tagged with communities, and simply redistribute to them with his own additions suitably tagged. I don't know if they have changed, but the early AS-7777 instructions emphasised using the IP address of *THE* port facing towards Paul's machine. This is not necessary for this multi-hop application and may be difficult in a multi-homed world in any case. A loopback works well.

1 0

Cisco 'rsh' attacks?
by Louis Destree 12 Apr '98

12 Apr '98

Greetings, Over the past few days, my Cisco logs have shown several attemps of folks trying to rsh into my core routers. These attempts seem to happen within a very brief period of time, and so far there have been less than 8 attempts per 'attack' as if run by some sort of script. Below is the output from the latest attempt. You can see there were 4 attempts in 2 seconds. I'm a pretty fast typist, but I don't think I could pull that off by hand. Is this the 'next thing' we get to scramble about? Anyone else having these? Are there any Cisco router related security holes relating to rsh that these folks are trying to abuse? Thanks, Louis -- Louis A. Destree Senior Network Engineer FlashNet Communications destree(a)flash.net Apr 11 20:13:49 wormhole.flash.net 2279: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140 Apr 11 20:13:49 wormhole.flash.net 2280: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140 Apr 11 20:13:50 wormhole.flash.net 2281: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140 Apr 11 20:13:50 wormhole.flash.net 2282: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140

2 1

RE: AS8584 taking over the internet
by Goldstein_William＠bns.att.com 10 Apr '98

10 Apr '98

PSINet recently announced free private peering for any ISP buying transit. How might this affect the frequency of AS8584-type problems? Bill Goldstein Senior Internet Specialist AT&T wgoldstein(a)att.com TEL:(412)642-7288 ---------- From: jprovo Sent: Thursday, April 09, 1998 10:44 PM To: nanog Cc: jprovo Subject: Re: AS8584 taking over the internet Received: from speedy1.bns.att.com (speedy1.bns.att.com [135.177.97.230]) by pawayn01.bns.att.com (8.8.6/1.3) with ESMTP id WAA13155 for <Goldstein_William/bcs_pawayn01(a)pawayn01.bns.att.com>; Thu, 9 Apr 1998 22:53:16 -0400 (EDT) Received: from kcig1.att.att.com (kcig1.att.att.com [135.38.78.194]) by speedy1.bns.att.com (8.7.3/2.5) with ESMTP id VAA18513 for <goldstein_william(a)bns.att.com>; Thu, 9 Apr 1998 21:54:41 -0500 (EST) Received: (from nuucp@localhost) by kcig1.att.att.com (AT&T/GW-1.0) id VAA14235; Thu, 9 Apr 1998 21:53:11 -0500 (CDT) >Received: by kcgw1.att.com; Thu Apr 9 21:53 CDT 1998 Received: by kcgw1.att.com; Thu Apr 9 21:53 CDT 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA26613; Thu, 9 Apr 1998 22:46:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Apr 1998 22:44:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA26537 for nanog-outgoing; Thu, 9 Apr 1998 22:44:56 -0400 (EDT) Received: from strato-fe0.ultra.net (strato-fe0.ultra.net [146.115.8.190]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA26533 for <nanog(a)merit.org>; Thu, 9 Apr 1998 22:44:52 -0400 (EDT) Received: from noc.ultra.net (noc.ultra.net [199.232.56.9]) by strato-fe0.ultra.net (8.8.8/ult.n14767) with ESMTP id WAA07955 for <nanog(a)merit.org>; Thu, 9 Apr 1998 22:44:51 -0400 (EDT) Received: (from jprovo@localhost) by noc.ultra.net (8.8.5/8.6.9/0.2jzp) id WAA12336 for nanog(a)merit.org; Thu, 9 Apr 1998 22:44:50 -0400 (EDT) Date: Thu, 9 Apr 1998 22:44:50 -0400 (EDT) From: Joe Provo - Network Architect <jprovo(a)ultra.net> Message-Id: <199804100244.WAA12336(a)noc.ultra.net> To: nanog(a)merit.org Subject: Re: AS8584 taking over the internet Sender: owner-nanog(a)merit.edu Content-Type: text -------------------------------------------------- [snip] > I believe that the implication was that: 1) they're not directly > connected to any of the major _US_ backbones, and 2) they're on the > other end of a fairly thin hose. > > And they can _still_ hose things this badly. > > This speaks not well of the architecture involved. No, no, it speaks _well_ for the architecture - equal opportunity hosage! There is no backone-hasage cabale; all that enter into bgp relationships can have a shot at hurting the net... ObContent: - yes, filters are Good. customers, especially if new to complicated things, should have both as-path and prefix filters placed against them. the questions to ask oneself regarding peers is "how clueful are they, really? and do their procedures allow only these clueful into the boxes? am I willing to tie my performance/reliability/ reputation to theirs in this intimate a fashion? are my bosses willing to do so? " People like to think in terms of the first question, not the last two. - yes, the IRR is good (and yes, their PGP implementation works); giving third parties the ability to verify your organization's "routing intent" cannot be construed as bad -- the data is publicly visible. there's nothing to hide. - yes, filtering doesn't mean not pushing IRR (or other forms of distributed data) on folks. IRR (or ...) doesn't mean not trying to more closely tie authentication/verification vs realtime; present tools are config-only, which aren't dynamic enough for the real net. joe -30-

2 1

Mae-west problems
by Wilson Chu 10 Apr '98

10 Apr '98

Hello, Currently the Mae-west fddi ring is experiencing hits which are causing many problems at and around mae-west. We are tracking MFS ticket number 202934. noc(a)above.net

1 0

Sprint ISC Number? - Not for Randy
by Jay Stewart 10 Apr '98

10 Apr '98

You can delete this one Randy, My Question? What happened to the Sprint ISC, calling their number: 800 232 6895, gets only the "sprint voice mail" system. I used to be able to reach the ISC direct this way, does anyone know a current working number? Jay Stewart Vice President Olympia Networking Services - "Premier Internet Access" Phone (360) 753.3636 Fax (360) 357.6160 http://www.olywa.net/

2 1