June 1998 - Test - lists.nanog.org

smurf-check page
by Jared Mauch 18 Jun '98

18 Jun '98

The results from my recent smurf check are now all stuck in a database, and you can query them based on home-as, etc.. questions? send them directly to me, otherwise here's the url: http://puck.nether.net/smurf-check/ - Jared conf t no router bgp end wr

1 0

Re: RBL Update (Re: Lets go vixie!! rbl)
by Dean Anderson 18 Jun '98

18 Jun '98

Dave Rand provided me with a blocked MCI customer. (not an RBL block, but still a block). Can someone downstream of Above.net give me a shell account? Test case, here we come... --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: DoS attack.
by Richard Thomas 18 Jun '98

18 Jun '98

-----Original Message----- From: brad <brad(a)poofy.tbn.tm> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Thursday, June 18, 1998 3:16 AM Subject: DoS attack. >If you only feel confident cutting and pasting the configuration >into your router, here is the config line: > >no ip routing Hrmmmm that's a really good strategy. Now if we could just get everyone on the net to do that there would be no more denial of service attacks. =)

1 0

Lucent Sues Cisco
by James Glave 18 Jun '98

18 Jun '98

Anyone familiar with the history here and care to comment for a Wired article? I'll pass on more details as they emerge if folks are interested... -james(a)wired.com >>LUCENT TECHNOLOGIES FILES PATENT INFRINGEMENT LAWSUIT >>AGAINST CISCO SYSTEMS; SEEKS DAMAGES AND INJUNCTIVE RELIEF >> >>FOR IMMEDIATE RELEASE: THURSDAY, JUNE 18, 1998 >>MURRAY HILL, N.J. - Lucent Technologies today filed a patent infringement >>lawsuit against Cisco Systems of San Jose, California. >> >>Filed in U.S. District Court in Delaware, the lawsuit charges Cisco with >>infringing eight patents related to data networking. The patents cover Bell >>Labs-developed technology associated with routers, frame relay network >>equipment and Asynchronous Transfer Mode (ATM) equipment. >> >>"After numerous attempts to negotiate with Cisco, we were left with no other >>recourse but to file suit," said Michael Greene, Lucent Technologies' >>president of Intellectual Property. "We license our patents to many >>companies in the industry, and our goal is to receive fair value for Bell >>Labs' discoveries and innovations - innovations that are the result of more >>than $3 billion in annual investment. We're looking to protect our >>intellectual property with the appropriate agreements and for proper >>compensation." >> >>In its suit, Lucent will be seeking damages for Cisco Systems' infringement >>of its patents and an injunction prohibiting Cisco's use of its patents in >>the future. James Glave, Senior Technology Writer Wired News http://www.wired.com (415) 276-8430

1 0

Re: Smurf Amp Nets
by Richard Thomas 18 Jun '98

18 Jun '98

-----Original Message----- From: Richard Thomas <buglord(a)ex-pressnet.com> To: Jon Lewis <jlewis(a)inorganic5.fdt.net> Cc: nanog(a)merit.net <nanog(a)merit.net> Date: Thursday, June 18, 1998 1:09 PM Subject: Re: Smurf Amp Nets >Might want to add a delay considering the amount of bandwidth they will be receiving if they tried to send out all those probes at once. In a previous message it was stated that a probe uses 4x64bytes, plus amplification by the broadcasts. I just took the SAR offline for about 4 minutes while trying running a SMALL portion of my bcasts through your script on my 28.8k modem, and it didn't even come close to completing that portion. That fact aside you won't get very accurate results if the SAR is so flooded it can't receive the replies. I would suggest they use ping >-s 1 or -s 8 if the timing information is desired. Woops my bad missed the ''s to protect &, I really WAS firing 'em off all at once =)

1 0

RE: DoS attack.
by S.J.Brannon 18 Jun '98

18 Jun '98

I have been thinking of a witty answer to this email. This will do Tony !! ---------- From: Tony Li[SMTP:tli@juniper.net] Sent: Thursday, June 18, 1998 10:22 To: brad Cc: nanog(a)merit.edu Subject: Re: DoS attack. brad(a)poofy.tbn.tm (brad) writes: > If you only feel confident cutting and pasting the configuration > into your router, here is the config line: > > no ip routing ;-) Thanks, I needed that. Tony

1 0

Re: GRE packets
by Danny McPherson 18 Jun '98

18 Jun '98

Perhaps to combat this, unless I'm missing something, one could justifiably deploy GRE filters with source & destination addresses of the exchange subnets. Filtering GRE in general seems nothing more than foolish. -danny [snip] (we certainly allow GRE packets and expect everyone else does, too) > This could kill IP-GRE VPNs indiscriminately.

4 3

Re: DoS attack.
by Tony Li 18 Jun '98

18 Jun '98

brad(a)poofy.tbn.tm (brad) writes: > If you only feel confident cutting and pasting the configuration > into your router, here is the config line: > > no ip routing ;-) Thanks, I needed that. Tony

1 0

Re: Smurf Amp Nets
by Richard Thomas 18 Jun '98

18 Jun '98

-----Original Message----- From: Jon Lewis <jlewis(a)inorganic5.fdt.net> To: Oystein Homelien <oystein(a)homelien.no> Cc: Andrew Herdman <andrew(a)whine.com>; nanog(a)merit.net <nanog(a)merit.net> Date: Wednesday, June 17, 1998 7:51 PM Subject: Re: Smurf Amp Nets >On Thu, 18 Jun 1998, Oystein Homelien wrote: > >> You need to push the "probe=" parameter to the cgi as well. What you are >> doing above is merely looking up already-registered networks in the SAR >> database. Again, you are NOT probing the networks through the SAR by >> running the above lynx command! >> >> To do what you want, you must use URLs of this form: >> >> http://www.powertech.no/smurf/probe.cgi?network=1.2.3.4&probe=PROBE > >ack! I somehow missed that when pasting the URL from Netscape into my >editor. Here's an updated version. Chris Bongaarts <cab(a)tc.umn.edu> sent >the 172.16/12 regex I was too lazy to include before. > >#!/usr/bin/perl > >while (<STDIN>) { > ($net,$junk)=split /:/,$_,2; > if (($net=~/\d+\.\d+.\d+/) && > !($net=~/^(0\.)|(10\.)|(192\.168)|(172\.((1[6-9])|(2[0-9])|(3[01]))\.)|(255\ .255\.255)/)){ > system("lynx -dump 'http://www.powertech.no/smurf/probe.cgi?network=$net&probe=PROBE'"); > } > elsif ($net=~/---/) { > die "\ndone.\n"; > } >} > >I'm using this to make sure all the nets I recently posted about are >registered. Based on the times reported by SAR, I think I'll be adding a >bunch of new nets to it. Might want to add a delay considering the amount of bandwidth they will be receiving if they tried to send out all those probes at once. In a previous message it was stated that a probe uses 4x64bytes, plus amplification by the broadcasts. I just took the SAR offline for about 4 minutes while trying running a SMALL portion of my bcasts through your script on my 28.8k modem, and it didn't even come close to completing that portion. That fact aside you won't get very accurate results if the SAR is so flooded it can't receive the replies. I would suggest they use ping -s 1 or -s 8 if the timing information is desired.

2 1

Re: GRE packets
by Sean Donelan 17 Jun '98

17 Jun '98

>Moreover, if IPSEC is in use, you can't even sniff. With IPSEC you infer things from traffic analysis. Or if you don't feel like doing grevious harm to IPSEC, you block the traffic and wait to see who complains. Many telephone companies do this type of blocking to control fraud on international calls. Your calling card will suddenly just stop working. You'll call up your communications provider, and while usually acting totally clueless, they'll re-enable your calling card. Most of the time, the spikes in traffic are fairly obvious. People share the 'secret' with their friends and like hogs at the trough they can never use it just a little. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0