September 1997 - Test - lists.nanog.org

Re: uunet + ans == ??
by Peter Leppik 08 Sep '97

08 Sep '97

At 09:13 AM 9/8/97 -0500, you wrote: >Worldcom bought Compuserve? I heard this morning on the radio that AOL >had bought them for a huge summ, and plan on operating them as a seperate >entity. The deal works like this: 1) WorldCom buys CompuServe for $1.2 billion in stock 2) WorldCom splits off the online service business from the network infrastructure business at CompuServe 3) AOL sells ANS (its network infrastructure division) to WoldCom in exchange for $175 million in cash plus the online service portion of the CompuServe business 4) AOL signs a five-year contract with WorldCom for network services (i.e. those which used to be provided by ANS and the network infrastructure part of CompuServe). Net Effects: H&R Block is rid of CompuServe. AOL owns CompuServe's subscribers and is out of the business of deploying modems and routers. WorldCom owns the networks built by AOL and CompuServe and sells network services to AOL. The big get bigger. Anybody else wondering how Prodigy is faring with their recent sale/outsource of their network infrastructure?

1 0

uunet + ans == ??
by Rod Nayfield 08 Sep '97

08 Sep '97

Ok, so in light of Worldcom buying Compuserve so it can just go trade it for ANS - anyone want to guess if uunet will be doing policy configs vs. ANS dropping theirs?

4 4

Looking for Gated
by Marcos Della 08 Sep '97

08 Sep '97

Hey there folks, I just re-subscribed to Nanog and about the only thing I have gotten out of this was a vague reference to turning off directed broadcasts, and a minor discussion on the GRF. Everything else has been white noise (hard to download via POP when on the road...) Anyway, I am looking for the latest copy of gated. I know that Ascend has been working on the code and that it moved from Carnege-Mellon (sp?), however I don't know what is publically available and what is considered propierity. Any pointers? Marcos ''' (o o) Senior Network Design Consultant -oOO--(_)--OOo-----------------------------------mdella(a)cstone.com------- Marcos R. Della http://www.cstone.com/~mdella

3 2

Annoying Ascend GRF thread
by Bill Clark 08 Sep '97

08 Sep '97

Hello, To the people that seem to want to discuss the Ascend GRF deployment, might I suggest using the ascend mailing list, or starting a seperate mailing list for this discussion. I don't believe that this thread really belongs in this forum. I don't mean to be rude, but I read this mailing list for important info and interesting discussions. This might have been slightly interesting, but this thread has been going on now for weeks and Im getting tired of sifting through the ascend subject title and don't really want to build a mail filter for this list. Anyone think I'm out of line here in making this request? Bill Clark NCCS, Inc. Network Engineer (816)941-2144 bclark(a)nccsinc.com bclark(a)not.abnormal.com

4 3

Re: smurf's attack..i
by Hank Nussbacher 07 Sep '97

07 Sep '97

At 02:40 PM 9/5/97 -0700, Steve Noble wrote: >If you are going to filter, you can just filter ICMP for now, thats the >major protocol used in the attack, that way you are only slightly >affecting those who might have a .255 address on one of their machines. We instead limit the rate of ICMP to 30kb/sec over our T1 line, thereby allowing ICMP to work, but yet limiting the damage an ICMP storm can cause. We use a box called Bandwiz that does the QoS (been discussed here before in the past). -Hank

1 0

Spammer Bust
by Mark E Larson 07 Sep '97

07 Sep '97

Thought people would be interested in this article. http://www.pcmike.com/Special%20Reports/High%20School%20Spammer.html Thanx Mark E Larson Senior Network Architect RUSTnet Engineering ==================================================== RUSTnet, Inc. A member of the VERIO Group of Internet Service Providers Tech Support: 313-762-6040 Home Page: http://www.rust.net Network Status: http://www.rust.net/network.html ====================================================

14 17

how to _really_ stop spam
by Barb Dijker 06 Sep '97

06 Sep '97

How many of you ISPs are sick of dealing with spam after the fact?? You get complaints from the world after spam from one of your customer's is sent out - via whatever clever way they have to beat the latest incoming spam filters. Your customer doesn't care. It's called spam & run. Disable their account and they spam & run elsewhere. This does nothing to stop spam - only wastes your time. Measures like the BGP filtering and incoming sendmail hacks are hip. But they do not stop spam. The BGP blackholes all IP traffic, not just mail. Disabling mail relay is indeed hard - especially for ISPs where your business _is_ relaying mail. Legal action is worthless - spammers just move or relay off-shore or otherwise out of whatever jurisdiction we want to impose. It's like trying to fight a fire pointing your extinguisher at the dancing flame-tips. Go for the base! The analogy I like best is the "Whack-a-Mole" game at the arcade. You're reflexes aren't fast enough to deal with the spammers. We need the heavy artillery and we need to go for the throat. Whacking even most of the moles doesn't fix your yard. Blocking incoming spam doesn't keep the bandwidth from being wasted. I have two preventative tactics I'd like to see pursued. Given infinite hours in the day, I'd do them myself. The ONLY way to deal with spam once and for all is for responsible ISPs to proactively enforce anti-spam policies. Then we can have whitelists instead of blacklists. 1) filter outgoing mail 2) validate new users through a "spam" bureau Impossible you say? No, impossible is fighting spam from the WRONG side. -Filtering outgoing mail Responsible retail ISPs should deny any and all OUTGOING smtp connections through border routers from hosts that are not validated as spam free. Wholesale ISPs should require their retail ISP customers take these spam free measuers. How... 1) First make your own outgoing mail relays spam free: o limit number of recipients to something reasonable (<10) o validate all headers (no forgery, valid return addrs) o relay only for your hosts and customer hosts (by ip, not domain) o throttle connections from any one internal ip (eg. <2/minute) o allow only simple DNS based addresses (no %![]:) Most of this can be done in sendmail compat(). A specialized tool that fits in like smap would be great for this. 2) Have a different mailing list host - lock it down tightly and make sure that all lists only allow postings from list members and no one message can be sent to multiple lists. 3) Allow outgoing smtp connections from your mail relay(s) through your border routers. 4) Make all your end-user customers relay through your now spam-free outgoing mail relay. 5) Any non-end-user customer that wants to make direct smtp connections out needs to make their relay spam-free as above. Otherwise they have to go through your relay. Have a separate legal contract/AUP to enable direct smtp. Charge more money for this service if you want - it will cost you more in the long run in hassle for these customers. 6) Lock everyone else out - deny outgoing smtp. The main thing that happens by doing this is you are preventing any of your customer from using a third-party relay!! Imagine that. Even if your outgoing mail relay doesn't do any validation or throttling, you are still preventing external third-party relaying AT THE SOURCE. The hardest part of fighting spam from the receiving end is the presumed-innocent-third-party relaying. Requiring end user hosts to relay through a local outgoing mailer is much easier than disabling relaying on every potential third-party host on the network. Sure this is expensive in terms of the outgoing mail relay server(s). But I'll put money down that you are already spending much more in dealing with spam complaints after the fact. This is NOT censorship. This is responsible mail delivery. The message origin is the ONLY place you can do some of this validation. If enough ISPs do this, then we can maintain a proactive list of spam-free ISPs. Forget the blacklists. They'll only get you sued. We need whitelists - ISPs from whom we trust mail is spam-free. All other mail should be stamped as suspect and dealt with on the receiving end accordingly. I challenge UUNET, PSI, and Earthlink to be the first to adopt this method and/or fund the development of outgoing ISP mail relay tools. This doesn't fix the entire problem. Nothing will. But until origins are willing to proactivley enforce their policies, we're just reacting to an ever changing spam profile and we'll never react quite fast or effectively enough. I'll bet the handful of companies who have made public apologies lately wished they had been proactively filtering outgoing mail. -Validate new users through an anti-spam bureau Most spam comes from independent individuals contracted to do marketing. Either that or they've been scammed into some Internet get rich quick scheme. Those people sign up for a new account with an ISP, promise to pay $X/mo, spam, get cut off, and move to another ISP. Most ISPs require no identification whatsoever to sign up a new user. It's no wonder that prosecuting spammers is close to impossible because the ISPs don't even have customers' legal name or a valid phone number or mailing address. I submit that any responsible ISP should not accept any new user account application without: 1) some form of identification to validate name 2) valid phone number (you call it and get that person) 3) valid mailing address (usps.gov is wonderful) For a business customers, contact the secy of state to validate the company exists and get the names of corporate officers. Check their DnB listing. Now what if you also checked the new user's ISP usage history in a central database - just like a bank checks TRW for your credit history? Are you going to accept a new user that was kicked off of 5 of the last 6 ISPs for violation of AUP? I hope not. But until that database exists, you are taking a chance that each new user is a potential spammer. These users are costing you real money. Just like a bad credit risk, an ISP has a right and a responsibility to check a new user's history. The only problem with this approach is how to unambiguously track such information in the database. Being an advocate of privacy, I'm vehemently against using the SSN for such a purpose. Same with driver's license number. Credit card number can change too often. As with databases like TRW, full name (as appears on a driver's license or other form of bonefide identification and should be validated) plus birth day should be sufficient. Aside from these wish list items, the _best_ way to fight incoming spam is a combination of incoming blocking (my personal blacklist is pretty long including all AGIS nets) and accepting only incoming mail (user agent filters) that explicitly lists a recipient in the header that you accept as being you. The more lists and aliases you are on (webmaster, hostmaster, postmaster, ad infinitum) the harder this gets. For most end-users, this is 100% effective. I've done it for me and it effectively blocked _all_ my incoming spam except those which are personalized and have my actual email address (or a valid alias). These folks you add to your sendmail spammer blocking database. The only drawback with this method is that you no longer get bcc mail. I put all my spam mail aside and peruse it once a week to look for real mail that might be a bcc, a low-vol list I forgot I was on, or otherwise was misfiled as spam. Barb Dijker, Manager NeTrack P O BOX 17565, BOULDER CO 80308-0565 USA +1.303.938.0188, fax +1.303.938.0177 http://www.netrack.net

2 1

Re: how to _really_ stop spam
by Michael Dillon 06 Sep '97

06 Sep '97

>How many of you ISPs are sick of dealing with spam >after the fact?? This was a very nice message. It's really too bad that you posted it to this network operators mailing list where not only is it off topic, but most ISPs will never see the message. Although a few ISPs hang out here, most of the people on this list are network operators and probably would not be as receptive to your ideas as an ISP would be. May I suggest that you sign up for one or more of the ISP mailing lists and repost it there. Here are signup instructions... Send a message that says subscribe to one or more of these addresses: inet-access-request(a)earth.com (high volume of messages, 2000 or more ISPs) linuxisp-request(a)friendly.jeffnet.org (medium volume for ISPs using Linux) freebsd-isp-request(a)freebsd.org (low volume for ISPs using Freesssss or send the message subscribe IAP Your Name to listserv(a)vma.cc.nd.edu (low volume general ISP list) or send the message subscribe OS2-ISP Your Name to listserv(a)stat.com (medium volume list for ISPs using OS/2) or send the message subscribe Apple-Net-Servers to majordomo(a)public.lists.apple.com (medium volume list for ISPs using Macs) ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************

1 0

smurf's attack...
by Network Administrator 06 Sep '97

06 Sep '97

The following network numbers were pulled from a program called "smurf". The program sends a large amount of spoofed traffic at broadcast addresses, hoping their echo packets will be magnified and sent to the spoofed address. The providers/machines most commonly hit are IRC servers and providers. To prevent from being an intermediary, one must turn off "ip directed broadcasts" on the router's interface. "198.3.101.255", "204.71.177.0", "192.41.177.255", "206.13.28.255", "144.228.20.255", "206.137.184.255", "198.32.186.255", "130.63.236.255", "208.202.14.255", "208.131.162.255", "199.171.6.255", "207.124.104.255", "205.180.58.255", "198.3.98.0", "131.104.96.255", "143.43.32.0", "131.215.48.0", "204.117.214.0", "143.43.32.255", "130.235.20.255", "206.79.254.255", "199.222.42.255", "204.71.242.255", "204.162.80.0", "128.194.103.255", "207.221.53.255", "207.126.113.255", "198.53.145.255", "209.25.21.255", "194.51.83.255", "207.51.48.255", "129.130.12.255", "192.231.221.255", "168.17.197.255", "198.242.55.255", "130.160.224.255", "128.83.40.255", "131.215.48.255", "169.130.10.255", "207.20.7.255", "163.179.1.0", "129.16.1.0", "128.122.27.255", "132.236.230.255", "198.32.146.255", "192.41.177.0", "192.41.177.255", "203.25.25.255", "128.82.4.255", "128.6.5.255", "206.80.169.255" "204.71.154.255" "204.127.236.255", "192.41.177.255", "129.200.193.255" "130.1.200.255", "130.1.91.255", "130.1.87.255" "207.155.93.255", "129.245.110.255", "207.155.121.255" "203.252.5.255", "128.6.5.255", "128.82.4.255" "129.245.75.255", "129.245.5.255", "206.7.114.255" "130.1.200.255", "129.245.17.255", "129.245.15.255"

15 19

Re: The Encryption Issue... (fwd)
by Marc Hurst 05 Sep '97

05 Sep '97

I wrote a note to Senator Hutchison in response to the forwarded posting I saw here on the list. She was quoted as being in support of the archiving of encryption keys to keep children from viewing pornography on the Internet. This was the response I got... ---------- Forwarded message ---------- Date: Fri, 5 Sep 1997 10:35:53 -0400 From: Senator <Senator(a)hutchison.senate.gov> To: mhurst(a)skyscape.net Subject: Rule: Re: The Encryption Issue... Thank you very much for your Internet message to Senator Kay Bailey Hutchison. If you provided your postal mailing address, Senator Hutchison will respond to your comments or concerns by regular mail. Again, thank you for contacting Senator Hutchison via the Internet. ** Office of Senator Kay Bailey Hutchison (TX) **

4 4