- Test - lists.nanog.org

NANOG 11 UPDATE
by Pam Ciesla 12 Aug '97

12 Aug '97

Airfare discount & alternate hotel info is available on the NANOG Web page www.nanog.org. If you need any other info please contact me. I am looking into international airline discounts, but not sure if this will be available for this meeting. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2 1

Re: [nsp] known networks for broadcast ping attacks
by Dennis Simpson 12 Aug '97

12 Aug '97

> Here's a sorted list of the networks used to attack FDT (pulled from my > 1.5mb of tcpdump data which was just a brief sample of the data from our > attack Sunday. If any of them belong to you, shame on you. > > 207.107.244 You are being hit through Sprint Canada. Four /30's from this class c are the addresses assigned to the 4 T1's we have with Sprint Canada. What specific addresses on this net hit you? We do source address filtering, and do not permit packets to leave our net which do not have source addresses on our nets. Having said that, the /30's I am concerned about do not appear anywhere but our core router. If your attack is coming from there, then I would likely to know what the h*ll our router is doing sending those packets, and who the h*ll has that kind of access to our router that we don't know about. Please confirm the actual source IP's on the 207.107.244 network. I also know of a Toronto ISP who has a /30 from this network for their link to Sprint Canada. Thx, dennis

2 1

Samsung
by dhudes＠graphnet.com 12 Aug '97

12 Aug '97

Sir: Spamming as normally practiced involves the theft of services through the use of one or more third party's mail servers to send the spam on behalf of the spammer. Should Graphnet, an FCC-licensed carrier, in reviewing its message logs from months of spamming which we have finally ended through technical means, find that your clients have directly or through the contracted services of a third-party bulk e-mail service used our systems without permission we will most assuredly seek heavy damages as permitted under laws of Interstate Commerce and also to ask the FCC to sanction Samsung and its subsidiaries. As any first-year law student knows, the First Amendment does not cover illegal acts. One cannot yell 'fire' in a crowded theater nor can one incite to riot. Use of one's own mail system to individually deliver unsolicited commercial messages to e-mail boxes is arguable; hijacking systems that don't belong to one, is theft of services. Impersonating the system you are stealing services from, over Interstate telephone lines (which as all know is what the Internet runs over) is wire fraud. Every criminal is entitled to counsel. That is the basis of the American system of Jurisprudence. Threatening the operators of the Internet is not a smart move, it just raises the profile of your client and ensures its bad name. You have, with your letter, lumped Samsung in with the sleaziest of pornographers. They should discharge you for incompetence. Dana Hudes Manager, Internet Engineering Graphnet p.s. Samsung is officially on my black-list as of this moment. As you can imagine, Graphnet buys lots and lots of electronic gear. No more Samsung for us.

3 2

Samsung
by Harris Schwartz 12 Aug '97

12 Aug '97

Working for one of the largest ISP's in North America, we have received our share of complaints regarding this message from the attorney on behalf of Samsung. I have also contacted the attorney and was told that they did not send the message and that they are investigating. All I know, is that this message has caused alot of problems. >Date: Tue, 12 Aug 1997 15:18:44 -0400 >From: dhudes(a)graphnet.com (Dana Hudes) >Organization: Graphnet Inc. >X-Mailer: Mozilla 4.01 [en] (Win95; U) >To: khskllp(a)aol.com >CC: nanog(a)merit.edu >Subject: Samsung >Sender: owner-nanog(a)merit.edu > >Sir: >Spamming as normally practiced involves the theft of services >through the use of one or more third party's mail servers to send >the spam on behalf of the spammer. Should Graphnet, an >FCC-licensed carrier, in reviewing its message logs from months >of spamming which we have finally ended through technical means, >find that your clients have directly or through the contracted >services of a third-party bulk e-mail service used our systems >without permission we will most assuredly seek heavy damages as >permitted under laws of Interstate Commerce and also to ask the >FCC to sanction Samsung and its subsidiaries. > >As any first-year law student knows, the First Amendment does not >cover illegal acts. One cannot yell 'fire' in a crowded theater >nor can one incite to riot. Use of one's own mail system to >individually deliver unsolicited commercial messages to e-mail >boxes is arguable; hijacking systems that don't belong to one, is >theft of services. Impersonating the system you are stealing >services from, over Interstate telephone lines (which as all know >is what the Internet runs over) is wire fraud. > >Every criminal is entitled to counsel. That is the basis of the >American system of Jurisprudence. Threatening the operators of >the Internet is not a smart move, it just raises the profile of >your client and ensures its bad name. You have, with your letter, >lumped Samsung in with the sleaziest of pornographers. They >should discharge you for incompetence. > >Dana Hudes >Manager, Internet Engineering >Graphnet >p.s. Samsung is officially on my black-list as of this moment. As >you can imagine, Graphnet buys lots and lots of electronic gear. >No more Samsung for us. > > > >

1 0

Re: Filtering Source Addresses on gw-internet
by C. Jon Larsen 12 Aug '97

12 Aug '97

Thats what I thought at first. But if the permit comes first, then packets with valid source addresses (a.b.c.d) get out because they pass that rule. So a packet built like: Source-> a.b.c.d Dest-> 172.17.0.0 will get out and be passed to the ISP, wasting bandwidth. Thats why I deny them first, and then do the permit later on in the list. > On Tue, 12 Aug 1997, C. Jon Larsen wrote: > > > gw-internet#show access-lists 120 > > Extended IP access list 120 > > deny ip any 10.0.0.0 0.255.255.255 log > > deny ip any 172.16.0.0 0.0.255.255 log > > deny ip any 172.17.0.0 0.0.255.255 log > > deny ip any 192.168.0.0 0.0.255.255 log > > permit ip a.b.c.0 0.0.0.255 any (27429 matches) > > deny ip any any log > > Aren't the first 4 deny's redundant? Using access-lists, I was under the > impression, there was an implicit deny at the end, such that all you'd > need is a single permit line above, and optionally the last deny so you > get to log violations. > > ------------------------------------------------------------------ > Jon Lewis <jlewis(a)fdt.net> | Unsolicited commercial e-mail will > Network Administrator | be proof-read for $199/message. > Florida Digital Turnpike | > ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____ > > Linux. +-------------------+---------------------+ | C. Jon Larsen | jlarsen(a)ajtech.com | | Systems Engineer | Tel: 804.353.2800 | | A&J Technologies | | |-------------------+---------------------| | http://www.ajtech.com | +-----------------------------------------+

2 1

Re: Packet size data
by brett watson 12 Aug '97

12 Aug '97

> Paul G. Donner wrote: > > > What about cflowd? > > cflowd would be really useful if netflow worked properly, which at least > in 11.2(7), it doesn't. The official Cisco response is: > > > Case :H82607 > > > > There are many issues with netflow switch with 11.2(7) > > that are still being addressed. Currently the estimated > > release for a fix is 11.3. Please bare with us while > > this issues are been addressed. what problems are you having? we're running it on a number of exchange point interfaces and we use: peer1.sjc1#sh ver Cisco Internetwork Operating System Software IOS (tm) GS Software (RSP-AJV-M), Version 11.1(11)CA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Synced to mainline version: 11.1(11) it's been very stable (we're running this backbone-wide) and it does support version 5 export. > Are people generally having any more luck with the 11.1CA images? It > would be really nice to get some decent traffic stats. yes, no major problems at all and we've been running it for a few months in most places. -brett

1 0

Re: [nsp] known networks for broadcast ping attacks
by Sharif Torpis 12 Aug '97

12 Aug '97

On Aug 12, 2:42am, Charles Sprickman wrote: > Subject: Re: [nsp] known networks for broadcast ping attacks > > When I type "no ip source route" on a Cisco, what exactly is that doing > for me? Is it just disallowing the router itself to generate > source-routed packets or is it saying sink all source-routed packets? > All this talk of spoofing is getting me a bit confused. What exactly is > the difference between source-routing and spoofing? > > Just trying to understand a bit more, Spoofing is forging a packet's source address. Source routing is including information in the packet that tells the route the packet should take to get to its destination. See ftp://ftp.greatcircle.com/pub/firewalls/FAQ -- Sharif Torpis (storpis(a)pbi.net) Network Engineering Pacific Bell Internet PGP Key at http://www-swiss.ai.mit.edu/~bal/pks-toplev.html

1 0

NANOG 11 Registration
by Pam Ciesla 12 Aug '97

12 Aug '97

NANOG registration fee correction on registration response. Please note the Registration fee for NANOG is $150 with the late fee being $170. Sorry for any confussion. Pam

1 0

Re: [nsp] known networks for broadcast ping attacks
by Jon Lewis 12 Aug '97

12 Aug '97

On Mon, 11 Aug 1997, some anonymous source wrote: > the program you are referring to is smurf.c which i believe was already > discussed on this list. I knew that...but I'd forgotten the name of the program. > the answer to the problem is the fact that there are hard coded > broadcast addresses within the programs. the people who are taking out > servers from irc are the idiots who would not know how to change these. This may be true, but what's to stop the writers of smurf and the other programs from distributing version 2 with all new network addresses? Fixing the 119 networks used to attack FDT will help, but I doubt it will solve the problem. Here's a sorted list of the networks used to attack FDT (pulled from my 1.5mb of tcpdump data which was just a brief sample of the data from our attack Sunday. If any of them belong to you, shame on you. The really interesting ones are the 0.0.0.0 and 255.255.255.255 sources. 18:55:54.836177 0.0.0.0 > 205.229.48.20: icmp: echo reply (ttl 245, id 61586) 18:55:55.816177 255.255.255.255 > 205.229.48.20: icmp: echo reply (ttl 249, id 4 Are these just misconfigured devices on some network from the list below? I suppose for bonus points, I could write a script to get the contact addresses from as many of these as possible and email them a note about how they're being used for network attacks. 0.0.0 4.0.1 4.0.144 4.0.84 38.146.219 128.101.101 128.101.233 128.101.87 128.102.18 128.135.181 128.135.23 128.161.1 128.190.156 129.16.1 129.237.128 129.237.129 129.237.130 129.237.131 129.237.2 129.237.80 129.237.83 129.237.86 129.237.87 129.241.181 129.241.56 129.241.57 129.43.7 130.132.1 130.132.143 130.132.159 131.119.0 131.119.58 134.24.38 134.84.254 136.142.185 136.142.254 137.39.130 137.39.136 137.39.166 137.39.184 144.228.20 144.232.8 160.147.28 163.179.230 165.154.1 166.48.35 170.140.3 170.140.35 170.140.4 170.140.5 170.140.6 192.160.127 192.88.114 192.9.9 193.10.85 198.137.140 198.163.155 198.3.101 198.41.0 198.53.119 198.53.145 198.53.33 198.53.44 198.80.46 199.0.154 199.0.216 199.166.6 199.183.24 199.199.93 199.227.0 199.227.28 199.242.23 204.112.14 204.162.96 204.186.0 204.186.95 204.225.245 204.50.176 204.7.246 204.7.247 204.70.59 204.71.242 205.147.225 205.149.75 205.150.207 205.150.221 205.164.8 205.177.10 205.177.4 205.211.8 205.211.9 205.252.5 205.253.29 206.102.224 206.129.122 206.13.28 206.141.250 206.161.255 206.170.28 206.171.128 206.222.98 206.54.225 206.98.160 207.107.244 207.137.200 207.154.150 207.171.87 207.181.65 207.19.74 207.216.162 207.240.8 207.25.16 207.51.36 207.67.241 207.91.124 209.12.0 209.20.130 209.82.1 255.255.255 ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

4 3

Re: Packet size data
by Paul G. Donner 12 Aug '97

12 Aug '97

What about cflowd? At 11:23 AM 8/11/97 -0700, Justin W. Newton wrote: >Hi, > Does anyone have any /recent/ information on the breakdown of packet sizes >crossing the net right now? I have seen some of the older data, but am >interested in whether or not the percentages are changing over time, and if >so, how. I.e. I could see people moving from interactive services such as >telnet for reading mail and news to going to a client based system would up >the packet sizes. Likewise, the use of some of the streaming video and >audio applications out there might lower it again. In my mind, recent is >anything that has been done in the last 6 months or so. > >************************************************************** >Justin W. Newton voice: +1-415-482-2840 >Senior Network Architect fax: +1-415-482-2844 >PRIORI NETWORKS, INC. http://www.priori.net >Legislative and Policy Director, ISP/C http://www.ispc.org >"The People You Know. The People You Trust." >************************************************************** > >

4 3