- NANOG - lists.nanog.org

Smurf Amp Nets
by Andrew Herdman 17 Jun '98

17 Jun '98

Sorry to pollute the list with yet another e-mail about Smurf Amp's, but at this very second, an IRC server that I run is being hammered from these networks. I tried registering them in SAR, got some of them in, but some wouldn't take, and entering all 132 nets manually is kind of cumbersome. *hint hint* I've also assumed they are all /24's (which the 141.161.x.x's are for sure). Anyway here they are. Andrew 0.0.0.0 10.0.4.0 127.0.0.0 129.71.1.0 134.24.34.0 141.161.11.0 141.161.12.0 141.161.180.0 141.161.19.0 141.161.196.0 141.161.2.0 141.161.20.0 141.161.21.0 141.161.54.0 141.161.97.0 141.164.236.0 141.164.240.0 141.164.241.0 141.164.242.0 141.164.243.0 141.198.64.0 142.154.4.0 142.165.3.0 146.188.232.0 161.27.9.0 168.198.52.0 168.216.11.0 168.216.12.0 168.216.13.0 168.216.14.0 168.216.15.0 168.216.9.0 169.130.14.0 172.20.1.0 172.20.2.0 172.20.4.0 172.20.5.0 172.20.50.0 172.31.0.0 192.102.232.0 192.106.1.0 192.168.102.0 192.168.104.0 192.168.250.0 192.206.159.0 192.231.112.0 192.234.72.0 192.40.28.0 192.89.254.0 193.190.196.0 193.76.0.0 193.76.109.0 193.76.81.0 194.211.170.0 194.215.130.0 194.215.133.0 194.244.59.0 198.163.232.0 198.26.182.0 198.3.200.0 198.53.245.0 198.60.120.0 198.68.156.0 199.104.254.0 200.135.13.0 200.23.51.0 200.230.140.0 200.230.142.0 200.230.143.0 200.38.168.0 200.5.128.0 200.5.129.0 202.184.18.0 202.184.25.0 203.150.240.0 204.115.171.0 204.17.178.0 204.208.152.0 204.208.153.0 204.228.161.0 204.229.43.0 204.229.45.0 204.233.137.0 204.242.172.0 204.244.32.0 204.249.16.0 204.26.101.0 204.26.102.0 204.26.103.0 204.26.104.0 204.26.109.0 204.31.135.0 204.64.22.0 204.64.23.0 204.65.223.0 204.70.146.0 204.70.164.0 204.71.242.0 204.96.225.0 205.150.226.0 205.163.217.0 205.172.3.0 205.184.109.0 205.211.168.0 205.218.18.0 205.232.11.0 205.232.119.0 205.232.8.0 206.110.105.0 206.110.253.0 206.110.98.0 206.204.42.0 206.251.0.0 206.251.5.0 206.251.7.0 206.29.111.0 206.34.91.0 207.112.247.0 207.124.139.0 207.34.202.0 207.65.122.0 207.68.0.0 207.99.6.0 208.128.161.0 208.128.185.0 208.133.118.0 208.145.80.0 208.149.198.0 208.192.84.0 209.125.164.0 209.2.160.0 209.22.240.0 209.48.31.0 209.49.144.0 209.49.157.0 209.84.61.0 24.129.20.0 255.255.255.0

4 4

Re: Government scrutiny is headed our way
by howland＠Priss.com 17 Jun '98

17 Jun '98

Karl, *You* may wish to make your life more convenient by bringing government force into your relationship with other network providers, why by what divine right do you get to impose your convenience on others by force? Just go ahead and filter the offenders. When their customers cannot reach your services, or their server customers get contacted by your customers about the policies of their ISP, either they will change their policies or they will loose customers. It is MUCH more effective to guide business policies by the lure of money than by the gun. Each and every network service I have worked for has, once the benefits of cooperation were pointed out to them, changed their tune. Maybe if it were someone advocating force against YOU you wouldn't be quite so pleased at the prospect as when you think the cavalry is coming to rescue YOU. Curt-

6 8

Operational: Need IMMEDIATE cooperation to trace a smurf...
by Dalvenjah FoxFire 17 Jun '98

17 Jun '98

Hi folks, I don't know if this'll work, but I thought I'd try it. One of the networks containing a DALnet server is currently under smurf attack, and has been so since 3:30 AM Pacific Time. I need folks with access to your cores (including MCI, Sprint, and all the other big folks) to sniff in the right places and see if you can't find some ICMP_ECHO_REQUEST packets with the SOURCE address of 209.133.28.*. (You can rest assured that this network isn't sending anything of the sort right now.) I'm hoping we'll get lucky and find this person by chance. If not, oh well, but it's worth a shot. Please e-mail me back (dalvenjah(a)dal.net) or telephone me (619-678-8586) if you find packets of this nature transiting your network. Thank you, -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) May evil beware...and may good dress Founder, the DALnet IRC Network warmly and eat plenty of vegetables. - The Tick e-mail: dalvenjah(a)dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

1 0

Re: Government scrutiny is headed our way
by Kent W. England 17 Jun '98

17 Jun '98

If software from OFRV can do ingress source address checking without performance penalty on edge devices, it should be included as a default. It doesn't make sense to me to run around yelling about strange people in your house if there is technology that can bar entry. Install the lock that is already there and lock the door. We just have to get creative about describing the inclusion of the feature, attendance at a congressional hearing, a demonstration at an industry conference, and a well written press release about how "we" are doing something about the problem. IOPS could do this. NANOG's press secretary or executive director could do this. :-) --Kent From: Jon Lewis <jlewis(a)inorganic5.fdt.net> > >On IOS, aren't packets going through ip access-group filters (that don't >do logging) fast switched as of some point in 11.2? If ingress filtering >no longer has to put a huge burdon on router CPUs, it would be nice to see >ingress filtering on the routers backbone providers talk to customers >with ...

1 0

Re: Government scrutiny is headed our way
by Richard Thomas 17 Jun '98

17 Jun '98

-----Original Message----- From: Karl Denninger <karl(a)mcs.net> To: Richard Thomas <buglord(a)ex-pressnet.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Tuesday, June 16, 1998 6:54 PM Subject: Re: Government scrutiny is headed our way >Well, we do it one better - we black-hole the network. > >I just added another ~60 prefixes to the list after another persistent smurf >attack. I've given up trying to trace them myself (although we do report >it) because the big networks, where this originates, are unwilling to help >in a timely fashion. > >If people bitch about the connectivity loss, well tough shit. Better >to have a working network that can get to 99.5% of the Internet than a >completely trashed one with full visibility. Somehow I doubt there is a big demand for access to your network from these smurf relays. And if there is 1 person who happens to try, I doubt they will go running to their admins with "I know why we can't connect... Its 'cause we're a smurf relay". All the responsive clueful networks have protected themselves already, what we're dealing with now are the people who don't understand subtle messages like people blocking their connectivity. >I'm going to have to talk to our lawyers about whether or not we could *sue* >the amplifier networks. Most of them are truly large organizations (ie: >universities, big corporations, big national providers, etc) and could easily >pay such a judgement. I bet if you just got ONE big judgement there would be a lot more responsiveness out of some of the big guys... =)

1 0

NAP
by Muhammad Naved 17 Jun '98

17 Jun '98

Hi, I want to find out the ideas and techniques about NAP(network access point) .I want to creat our local NAPS in pakistan . Please let me know where I get the informations of NAPS. Thanks in advance. Regards Naved

1 0

Duplicate and conflicting NIC Handles
by Sean Donelan 17 Jun '98

17 Jun '98

Well, it looks like we have yet another WHOIS database, whois.nic.gov. The problem is the creators didn't remembered the lessons from previous WHOIS databases, namely they've created duplicate conflicting NIC Handles. NIC-DOM has a conflict in whois.nic.mil and whois.nic.gov. GB1 also has a conflict in various whois databases. What a mess. Obviously I missed the announcement on the change, does anyone know where it was posted, or who is in charge this week? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Government scrutiny is headed our way
by Richard Thomas 17 Jun '98

17 Jun '98

-----Original Message----- From: Karl Denninger <karl(a)mcs.net> To: Jay R. Ashworth <jra(a)scfn.thpl.lib.fl.us> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Tuesday, June 16, 1998 3:54 PM Subject: Re: Government scrutiny is headed our way >> > Since they don't cooperate, the only two defenses are: >> > >> > 1. Black-hole detected amplifier networks (what we're doing here). >> >> Indeed. And what I think is the best approach. Kick 'em in the >> nads^Wnets. > >Not really. The best approach is to nail a few of these folks with felony >indictments for the denial of service attacks, and the theft of the >amplifier network's services. That would stop this practice cold. Unfortunantly I highly doubt this will have much impact. Firstly, all of the "smurf kiddies" are using hacked shells, so when you trace it back to them they don't care, they just move to the next machine. Secondly, the most annoying and persistant smurfers (read "conflict") are too stupid to know better even if you start bumping off smurfers left and right. You're likely to scare the casual immoral network admin who smurfs his isp's competition or such, but thats about it. My strategy is to hit the smurfers where it hurts, the broadcasts. I email the broadcast network, and their uplink, and their uplink, until something gets done. If you can exaust their broadcasts quickly enough it becomes too "expensive" for them to continue.

3 2

RE: Government scrutiny is headed our way
by Jamie Scheinblum 17 Jun '98

17 Jun '98

And then you'll get wrapped up in the court-case, probably lose the case since they'll be able to hire better lawyers and fight it out longer, the judge/jury will have no idea what your talking about, and you'll still be the victim of the smurf attacks. My guess is, you won't get far this way. Too many people to sue. I still like the idea of running a scan of the entire IP space, as expensive and tiring it would be, and inject them all into the RBL. I know Jared is off to a great start... My guess is the policy makers will come up with a never-enforced set of guidelines, that only hurt the small ISP or organization. The answer has to be technical. We'll hate the political one. Best regards, Jamie Scheinblum - FASTNET(tm) / You Tools Corporation jamie(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions The views stated above are mine and do not reflect those of my employer. -----Original Message----- From: Karl Denninger [mailto:karl@mcs.net] Sent: Tuesday, June 16, 1998 6:58 PM To: Richard Thomas Cc: nanog(a)merit.edu Subject: Re: Government scrutiny is headed our way I'm going to have to talk to our lawyers about whether or not we could *sue* the amplifier networks. Most of them are truly large organizations (ie: universities, big corporations, big national providers, etc) and could easily pay such a judgement. Heh, now there's an idea :-) -- -- 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

2 1

Re: smurf amp nets, the registry (SAR)
by Oystein Homelien 17 Jun '98

17 Jun '98

On Mon, 15 Jun 1998, D'Arcy J.M. Cain wrote: > > http://www.powertech.no/smurf/ > > It's great that you are doing this but I'm wondering how you determine > the number of responses. In particular I see that 194.157.40.0/24 gives > 840 dups. That one seems to be fixed but another one, 192.127.30.0/24, > is still broken but your probe shows 412 dups. Seems to me that it can't > be more than 254. My own test of that network showed a response of 151. > Just wondering. What we do is basically this: ping -c4 network_address ping -c4 broadcast_address Then we log the _highest number of returned packets_ from any of the 3*2 pings we now have stored replies for. The number of _dups_ we record is this count, minus one. Some times the number of dups we see vary wildly depending on when we probe, or where you are probing from. I tend to attribute this to load on the amplifier network (perhaps someone is using them in an attack at this time), or packet-shredding international links that can't take the burst. (That is, if you and I were probing a european amplifier network, I might see slightly more dups than you since I am in Europe). Oh, and by the way! No more than 254 replies, you say. That's because you see it registered in the registry as a /24. I need to point out that there's nothing we do at this point to verify that the prefix lengths of the networks entered into the SAR are actually correct. So something listed as a /24 could be anything - you'll have to look at the actual network number to judge for yourself what it might be. We try to keep the prefix lengths longer so as not to block too much by accident (the probe defaults to /24). In some cases we see that the number of dups returned far exceed the theoretical max of the probed network. In some cases this happens because the prefix length is wrong, but in other cases i am at a loss - the hosts in the probed network actually seems to return more than one response per request. I have no idea why. We saw this with the 193.55.112.0/24 network, for instance (which has now been fixed). Oystein Homelien | oystein(a)powertech.no PowerTech Information Systems AS | http://www.powertech.no/ Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333

3 2