- NANOG - lists.nanog.org

SMURF amplifier block list
by Karl Denninger 13 Apr '98

13 Apr '98

The following networks and masks are banned from our network at the core due to being smurf amplifiers. When the folks who own these STOP THIS, we'll take them off the list. Contact me by TELEPHONE if you want to discuss this matter or what a Smurf is and why you should care. I'm going to start posting the blacklist here weekly in the hopes that peer pressure will cause people to clean up their acts. Until you DO clean up your act, you're not transiting our network - period. We're not going to accept this kind of vandalism and attractive nuisance any more. If you haven't disabled directed broadcast forwarding, you are a potential listee on this blacklist. DO IT NOW, or risk connectivity blockades. I urge all other network providers to block any identified smurf amplifier that they can verify, and to post their list as well. Only through public pressure can people be forced to CORRECTLY configure their networks to make these attacks impossible to launch. access-list 2 deny 128.118.0.0 0.0.255.255 access-list 2 deny 129.24.0.0 0.0.255.255 access-list 2 deny 129.111.0.0 0.0.255.255 access-list 2 deny 129.100.0.0 0.0.255.255 access-list 2 deny 128.40.0.0 0.0.255.255 access-list 2 deny 129.101.0.0 0.0.255.255 access-list 2 deny 203.64.0.0 0.0.255.255 access-list 2 deny 129.115.0.0 0.0.255.255 access-list 2 deny 203.108.225.0 0.0.0.255 access-list 2 deny 129.60.0.0 0.0.255.255 access-list 2 deny 137.79.0.0 0.0.255.255 access-list 2 deny 130.37.0.0 0.0.255.255 access-list 2 deny 130.70.0.0 0.0.255.255 access-list 2 deny 203.108.236.0 0.0.0.255 access-list 2 deny 132.169.0.0 0.0.255.255 access-list 2 deny 129.107.0.0 0.0.255.255 access-list 2 deny 129.49.0.0 0.0.255.255 access-list 2 deny 129.96.0.0 0.0.255.255 access-list 2 deny 130.65.0.0 0.0.255.255 access-list 2 deny 134.205.0.0 0.0.255.255 access-list 2 deny 129.29.0.0 0.0.255.255 access-list 2 deny 204.48.224.0 0.0.0.255 access-list 2 deny 205.177.49.0 0.0.0.255 access-list 2 deny 204.47.208.0 0.0.0.255 access-list 2 deny 204.242.172.0 0.0.0.255 access-list 2 deny 194.6.129.0 0.0.0.255 access-list 2 deny 206.31.78.0 0.0.0.255 access-list 2 deny 207.211.60.0 0.0.0.255 access-list 2 deny 206.27.242.0 0.0.0.255 access-list 2 deny 207.175.67.0 0.0.0.255 I'm sure there are more, but these are the ones blacklisted in our network configuration right now. -- -- 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

11 19

Strange behavior...
by Aaron Tavistock 13 Apr '98

13 Apr '98

Not too sure if this falls into NANOG or not but I thought I'd give it a shot. I'm seeing some wierd responses from the Sprintlink primary name server (ns1.sprintlink.com) and I wanted to know if anyone could explain the behavior. Pinging 204.117.214.10 from San Francisco CA (GTE & Pacbell) and our colo in Bay City MI (MCI), I get a standard response. However, if I ping from our colo in Cambridge MA (GTE), I get a response of "2 times amplification" instead of packet loss. I've certainly seen amplification from ping in the past, but I thought it was a host/interface configuration issue that would affect all external hosts equally. I did not believe it had anything to do with routing, but now I'm not so sure. Anyone have any clues on why this is happening? Can anyone explain why ICMP amplification would occur? Aaron Tavistock Network Engineer / UNIX Systems Administrator Total Entertainment Network (http://www.ten.net)

3 2

someone new to sanction: wwd.org & comsys2.com
by Erik E. Fair 13 Apr '98

13 Apr '98

Western World Distribution (WWD3-DOM) 5751-246 B street Langley, BC v2z1h2 CA Domain Name: WWD.ORG Administrative Contact: Proske, Sean (SP1745) mail(a)WWD.ORG (604) 856-9330 (FAX) (604) 856-9330 Technical Contact, Zone Contact: Jarman, Greg (GJ267) greg(a)COMSYS.NET 3179322083 Billing Contact: Proske, Sean (SP1745) mail(a)WWD.ORG (604) 856-9330 (FAX) (604) 856-9330 Record last updated on 26-Aug-97. Record created on 24-Dec-96. Database last updated on 13-Apr-98 03:38:23 EDT. Domain servers in listed order: NS.COMSYS.NET 206.230.41.2 RESUME1.COM 206.230.41.224 Indiana Comm. and Sys (COMSYS6-DOM) 240 North Main Rushville, IN 46173 US Domain Name: COMSYS2.COM Administrative Contact, Technical Contact, Zone Contact: Jarman, Greg (GJ267) greg(a)COMSYS.NET 3179322083 Billing Contact: Jarman, Greg (GJ267) greg(a)COMSYS.NET 3179322083 Record last updated on 29-Mar-97. Record created on 29-Mar-97. Database last updated on 13-Apr-98 03:38:23 EDT. Domain servers in listed order: NS.COMSYS.NET 206.230.41.2 RESUME1.COM 206.230.41.224 ---- BEGIN FORWARDED MESSAGE Received: from NO-IDENT-SERVICE(a)homeworld.cygnus.com (port 53339 [205.180.83.70]) by cesium.clock.org with SMTP id <77318-247>; Mon, 13 Apr 1998 04:10:33 -0700 Received: (qmail 4611 invoked by uid 605); 13 Apr 1998 11:10:09 -0000 Received: (qmail 4562 invoked from network); 13 Apr 1998 11:10:04 -0000 Received: from unknown (HELO comsys2.com) (www(a)206.230.41.123) by homeworld.cygnus.com with SMTP; 13 Apr 1998 11:10:04 -0000 Received: =?UNKNOWN-8BIT?Q?=9Cby?= tallas4112.com (8.8.5/8.8.5) id GAA25409 for current-users(a)NetBSD.ORG; Mon, 13 Apr 1998 06:09:44 -0500 (EST) Date: Mon, 13 Apr 1998 06:09:44 -0500 (EST) Message-Id: <199804131109(a)tallas4112.com> From: bulkisp(a)wwd.org Reply-To: bulkisp(a)wwd.org To: current-users(a)NetBSD.ORG Subject: BULK ISP Sender: current-users-owner(a)NetBSD.ORG Precedence: list Delivered-To: current-users(a)NetBSD.ORG Return-Path: <current-users-owner-netbsd-current-users-local=clock.org(a)NetBSD.ORG> X-UIDL: 0325d4f5085c143d8a376734021769ba Hi, I noticed your listing for Bulk Email Software in the search engines and I thought you may have a need for a Bulk Friendly ISP. For complete details regarding our services, please visit our website at http://wwd.org Best regards, Sean PS: We are initially taking on only 100 users so don't delay... space is limited. ---- END FORWARDED MESSAGE

1 0

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 13 Apr '98

13 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 13 Apr '98

13 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