- NANOG - lists.nanog.org

Re: SPAM, RE: Internic and there lame response
by Anthony Sticha 13 Jul '98

13 Jul '98

OK so what to do if their upstream does nothing? Like PBI >>There are many other ways to track a spammer. >> >>- Do nslookup on the IP that originated the spam (sometimes this takes a >>bit of detective work to find what IP actually originated the spam). >>- Traceroute to the originating IP. Email the ISP that is directly upstream. > >*I* know these techniques. Joe User who's irritated at his spam likely >does not. > >>- Look in the Whois information for contact emails and nameservers - if >>these are for the upstream ISP, or some ISP other than the spammer, report >>it to them. > >But there's the rub. A great deal of the information (including >delegations) in domain registrations by net.abusers is complete >fabrication. InterNIC refuses to deal with it, even when it's pointed out >to them. > >>- If they are advertising a web page, track the web page host, and their >>upstream, and report it to them. > >All the time :> >> >>>What do spammers and nails have in common? They're both intended for >>>hammering. >> >>Amen. > >Witnesses available at www.witness.com...:) > > >What do spammers and nails have in common? They're both intended for >hammering. > >Dean Robb >PC-Easy >On-site computer services >(757) 495-EASY [3279] > > >

2 1

Re: NOC communications (was Re: Process management)
by Sean Donelan 13 Jul '98

13 Jul '98

>You bring up an interesting (if unspoken) point in your prior statement, >and that is: "Communications between entities is worthwhile if the >communications facility has a high signal-to-noise rate." While I am not >certain, I have strong suspicions that the SS7 NOCs pushed their emergency >directory numbers to the general number due to useless, misdirected calls. Most of the SS7 providers involved reported no problems with misuse of their contact information. A couple of providers said they were changing the contact information out of fear the information might be misused. One provider stated they had problems, but didn't give any specifics. As some anecdotal evidence I've found our WHOIS e-mail contact information tends to get spammed by the small time bulk mailers, usually whose own contact information is bogus. While our phone information tends to get junk calls by large corporations, usually one particular major ISP's telemarketing operation trying to sell Internet service. Handling such calls through the general purpose number can work well, IF and I repeat IF, the staff at the general purpose number is trained how to handle the calls and direct the information expeditiously. Unfortunately, it seems the person changing the emergency contact information forgets to inform the customer service operation they will now be getting those calls. Some companies seem to do this well, some seem to do this poorly. As I found out, you never know when it will be your newest, greenest tech who happens to get the call at the exact same time the senior engineer is in the bathroom. Even though the calls are fairly rare, it is an ongoing training process. Of course, if the general purpose contact number was working well, there wouldn't be a need for another contact method. > Being a secretary is not something that a NOC can afford to do. Being a secretary is also something most NOCs don't do well. It is a different set of skills. Dealing with a good receptionist is a pleasure. On the other hand, a bad receptionist is really bad. How many folks remember the recurring receptionist character sketch on Saturday Night Live. I doubt most NOC engineers would last 30 minutes on the front desk of a large law firm. >Therefore, to avoid this problem, one must limit the ubiquity of the >contact mechanism and increase the value of each message. Using a medium >like a phone number is of course the standard method for contact in any >emergency situation (email is great, but it lacks a rapid >question-answer-experiment ability) but phones also carry with them the >ease of use that works against them, as well as for them. A phone number >gets handed out on web sites, "emergency call" sheets, etc. and soon >people who do not have anything directly relating to operations are calling >the operations hot line. Either more staff is required to start answering >these questions, or (more likely) the "hot line" becomes not-so-hot and it >will go unanswered or not taken seriously, or simply nobody will care about >it and it will get forwarded to the Void. Yes, I'm aware of the 9-1-1 problem. If you make something that works well, everyone is afraid it will be overwhelmed with all sorts of calls not relevant to its primary purpose. On the other hand, if you make a something that is so restricted, it will never be abused, but it will also likely never get used or important pieces of information won't get through. How do you set things up to create a 'shared fate' among all the participants? Do you need a strong moderator, editor or dispatcher to make such a system work? To avoid the 'whose in charge' problem do we draw lots each week for the moderator position? If each of the participants don't feel some pressure from their management, shareholders, customers to make a good faith effort; will any and every system fail of active neglect? There have been several attempts in the past, and have not had a sucessfull track record. I'm going to keep throwing ideas against the wall to see what sticks. Are any of these ideas even close to being useful? Or do people think there is not a problem and I should just shut up. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: Smurf Prevention
by Richard Thomas 13 Jul '98

13 Jul '98

-----Original Message----- From: Dalvenjah FoxFire <dalvenjah(a)dal.net> To: Richard Thomas <buglord(a)ex-pressnet.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Sunday, July 12, 1998 6:24 PM Subject: Re: Smurf Prevention >On Mon, Jul 13, 1998 at 04:48:41AM -0400, Richard Thomas put this into my mailbox: > >> Perhaps we might have some success preventing smurfs from the most common >> sources, hacked machines on university dorm networks, by getting the >> university backbones to filter spoofs. Things like SUnet, FUnet, NYSERnet, >> etc, account for a large portion of universities used to smurf from, and it >> might be easier then trying to get each school to filter individually. I >> found the following two addresses for nysernet and funet but was unable to >> read or translate the Swedish on www.sunet.se. > >That's one solution. What might be a better solution would be if the Big Few >networks (MCI, Sprint, UUnet, etc.) were to take the list of smurf amplifiers >from something like the SAR, *verify* that they're still smurf amplifiers, >and then refuse to route traffic from those networks. > >Not only would it cut the smurfs down cold, but it would also get the folks >responsible for those networks to fix things. > >Then again, if the big-bandwidth folks cared about such things, perhaps they >would have done so already. Unfortunately the big guys have no incentive to deal with it on a large-scale basis. The amount of traffic involved is insignificant to them, they're making money off the bandwidth used, and of course the "filtering smurfs takes too much cpu time on our routers" answer (they don't seem to realize that as soon as the kids loose the instant gratification of seeing a ping timeout they will get bored and stop). You know several global broadcast scans have been conducted, I've submitted them all to the Smurf Archive Registry, and we now seem stuck at around 14,000. That leads one to believe maybe this is all there ARE (of the .0 and .255 variety anyhow). 10,000 of those are < 10 dupes, and only 500 or so are > 30 dupes. Also remember that SAR doesn't scan to remove dead ones by itself (something I am currently working to create in my bcast databases), so a good many of those are probably fixed by now. HOW HARD CAN IT BE to take care of 500 broadcasts? Very hard, since the only bcasts still left are those with broken contact information and upstreams who haven't been informed or who don't give a damn. Maybe if we all picked 10 of the worst offenders every day, picked up the phone, and started informing people who have missed the boat...

3 2

Simulating full BGP peers
by Jon Green 13 Jul '98

13 Jul '98

Hi all- Does anyone know of a way to simulate about three BGP peers with full Internet routing tables in a lab environment? Preferably this would be something I could run on a Sparc. Thanks for any ideas -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen(a)netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------

6 9

Re: NOC communications (was Re: Process management)
by John Todd 13 Jul '98

13 Jul '98

At 04:30 PM 7/11/98 -0500, Sean Donelan wrote: >>> >establish a out-of-band communication system [...] connected via >>> >nationwide system which doesn't rely on IP, ATM, or SS7 >>> >>> I'm not sure where you'd find such a beast anymore. Maybe an SS7 and >>> an Iridium system, side-by-side, would do the trick. >> >>HF radio, more likely. Those of you without roof-rights, you better >>ask building management about getting same for the triband beam.... > >Actually I was thinking of a combination of 'order wires' with a combination >of VSAT and in-band network conference bridges for backup. However several >people of indicated that level of backup was too expensive. > >This problem isn't really unique to the Internet. I was looking at the >backup communications network for SS7 providers and noticed a couple >of major SS7 network providers don't give out their direct contact >information even to other SS7 network operators anymore. They changed >their listings in the emergency directory to general customer service >numbers. You bring up an interesting (if unspoken) point in your prior statement, and that is: "Communications between entities is worthwhile if the communications facility has a high signal-to-noise rate." While I am not certain, I have strong suspicions that the SS7 NOCs pushed their emergency directory numbers to the general number due to useless, misdirected calls. Being a secretary is not something that a NOC can afford to do. The same is the case with the administrator of an AS number - this is the real point of contact that providers use to work out issues with each other. Therefore, to avoid this problem, one must limit the ubiquity of the contact mechanism and increase the value of each message. Using a medium like a phone number is of course the standard method for contact in any emergency situation (email is great, but it lacks a rapid question-answer-experiment ability) but phones also carry with them the ease of use that works against them, as well as for them. A phone number gets handed out on web sites, "emergency call" sheets, etc. and soon people who do not have anything directly relating to operations are calling the operations hot line. Either more staff is required to start answering these questions, or (more likely) the "hot line" becomes not-so-hot and it will go unanswered or not taken seriously, or simply nobody will care about it and it will get forwarded to the Void. Email has the same problems, but with the a benefit of being a one-to-many broadcast service, where a phone is point-to-point. (email = multicast messaging? Better not go there. ;) However, email is not what you'd want to use in the event of an outage (for obvious reasons) for both incoming notifications as well as outgoing queries. Additionally, email is more easily ignored by a group of people than it is by an individual (how many times have you said "I thought you took care of that problem!" to someone on your "staff" list?) The Fantasy: Using a REAL out-of-band system for notifications of regional or "national" outages would be the best method for inter-provider communication, IMHO. However, Iridium phones, HF radios, or carrier pigeons are all too complex and too expensive for deployment into any organization other than the largest ISP/NSP circles. While I'd LOVE to see a line printer banging away in a corner on a 2400 baud Ku band "gas-station" style uplink, I don't see that happening. Besides, someone would have to centrally coordinate that - you think ARIN would mind taking on a multi-national satellite communications network? Sure - just hike the price for an AS number to, say, $4000 a year and make it mandatory that each AS has one of these systems in house. Right. The Reality: Reality is ugly. The phones and email are all we've got to work with. The trick is to make them more useful. Part 1: ARIN should be a fascist for maintaining correct information. The best method for allowing interprovider communications to work smoothly is to keep the NOC phone numbers and NOC email addresses valid and responsive. Maintainers of ASes should be correctly identified in the ARIN database. Phone numbers should be audited. I'm a big fan of "turn it off and see who comes running" update procedures. If someone doesn't respond within a reasonable number of attempts, or information is out of date for X period of time, enforce policy by denial of service. (I will leave "turn off" as an exercise to the reader - this could merely be administrative, or it could actually be a DOS on the AS. You could even do it during more-or-less standard early-morning maintenance windows that were pre-announced - enough pain for a few hours to encourage repair, but not total and permanent disability.) I guarantee that this will cause apoplexy, foaming at the mouth, and certain members of this list threatening lawyer/orifice interaction with ARIN or perhaps wondering if that's my black Sikorsky parked on the pad out back... but the database will quickly come up to date, and I'll bet that nobody is actually turned off. The amount of time saved during real DOS attacks, security breaches, peering problems, and route-mangling will far outweigh the actual number of lost dollars due to policy-enforcement outages. Part 2: Separate your handles for your domain names and your AS number. A smart provider will have a friendly front-end (perhaps a general number) on their domain name, since this is what the majority of the world will look at when trying to get a point of contact. Standard SPAM complaints, sales questions, joe-user will be getting a (hopefully) responsive interaction, but he won't be talking to the NOC at 3:00AM when he can't get to the Doom server off your network. The contact information for the AS number should be direct, always staffed, and clued appropriately. Even forwarding it to a pager is better than RNA. There are spaces for "alternate contacts" on the ARIN forms - _use them_. You might have a head routing person listed as #1 option, but put your NOC as #2 - it's free! "Operational" enough? Long-winded enough? JT

2 1

Re: MAJOR OUTAGE NYC
by Sean Donelan 13 Jul '98

13 Jul '98

>MFS has a major outage in NYC according to 800-MFS-CITY, which began 24 >minutes ago. It must be peak digging season. I saw tickets for four 'fiber cuts' in the last 7 days. Florida, Minnesota, Maryland, and now New York. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

T1 Circuit actual throughput 1290Kbps
by tonyh＠noc.cbn.net.id 13 Jul '98

13 Jul '98

Does anybody have experience having a T1 circuit with PPP encapsulation getting only 1290 Kbps maximum throughput looking at "sh int" result from cisco router or MRTG ? This is the explanation our upstream provider gave us: You have a 1.536Mbps port. However, there is the overhead from PPP and the translation overhead which takes place in all circuits. Judging by your settings that limit ends up somewhere between 1.3 and 1.4. This overhead would be the non-data portion of cells or frames for example. For example, you might have 1.3 Mbps of data which gets framing or cell information appended onto it before sending taking up additional bandwidth. It is to be expected in all circuits. Thank you for your help. Tony S. Hariman http://www.tsh.or.id Tel: +62(21)574-2488 tonyha(a)compuserve.com

13 16

Smurf Prevention
by Richard Thomas 12 Jul '98

12 Jul '98

Perhaps we might have some success preventing smurfs from the most common sources, hacked machines on university dorm networks, by getting the university backbones to filter spoofs. Things like SUnet, FUnet, NYSERnet, etc, account for a large portion of universities used to smurf from, and it might be easier then trying to get each school to filter individually. I found the following two addresses for nysernet and funet but was unable to read or translate the Swedish on www.sunet.se. Gary Crane, Senior Director of Network Development, gcrane(a)nysernet.org Markus Sadeniemi, Director of FUNET, Markus.Sadeniemi(a)csc.fi

2 1

Re: SPAM, RE: Internic and there lame response
by Dean Robb 12 Jul '98

12 Jul '98

At 19:22 7/8/98 -0400, you wrote: On SPAM-L: >Here is Internic's lame response regarding some of the domains that they >seem to support spam houses.. Some of the domains are clearly spam houses.. >and I complained about one.. being registered to the same person and is >being used to spam the heck out of people.. here is there lame response >back.. seems Like internic is not gonna be of any help. InterNIC is NEVER any help. IMO, they are the single biggest blight on the Internet, mainly because they have so much power and choose to just sit back and collect $$ instead of use their power to do anything even remotely good. >The InterNIC, like all Internet users, is impacted by individuals >who send out "spam" (bulk e-mailing) on the network. However, >Network Solutions is responsible for the administration of the >name space and not for policing its content or use. True. >Removal of domain names belonging to users who send unsolicited >e-mail would make it harder, not easier, to track and filter >unsolicited e-mail from their domain. Several free software programs >allow users to filter incoming traffic from a specified domain. If >users sending unsolicited e-mail are forced to register new domain >names it also becomes harder for Internet users to track the origin >of the unsolicited e-mail. Straw man. "If we enforce the laws, the criminals will just get sneakier". > >Although we are concerned about the validity of information in the >WHOIS database, it is the responsibility of the domain holder to >maintain current information. Invalid phone numbers or non-working >e-mail addresses of contacts is not a valid reason for cancellation >of a domain name. Domain names are only deleted at the request of >the registrant or via our billing cycle if payment is not received. Except, of course, that the Registration Agreement that a domain registrant agrees to in order to get a domain says that the domain can be deleted for false information. IF InterNIC TRULY gave a damn about WhoIs, they'd enforce their contract. This is just a massive lie. Can someone with acess to a lawyer comfortable in Internet law PLEASE get an opinion on whether an "attractive nuisance" or other civil suit against InterNIC would work? > >Many Internet Service Providers (ISPs) have policies regarding bulk >emails. You may wish to contact the ISP of the user who sent you the >unsolicited e-mail. Incredibly two-faced response. How do you determine the user's ISP? Check WhoIs. But...OOOPPSS!...the information in WhoIs is phoney, and we don't do anything about that. Sorry, guess you're just screwed. Oh, but give us money! Our $16 million dollar quarterly profits just aren't enough. Why, we can't even afford to write a script that will only permit numbers in numberic fields of our registration templates! What do spammers and nails have in common? They're both intended for hammering. Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]

3 2

Re: SPAM, RE: Internic and there lame response
by Andrea Di Lecce 12 Jul '98

12 Jul '98

At 20:21 7/8/98 -0400, you wrote: >Incredibly two-faced response. How do you determine the user's ISP? Check >WhoIs. But...OOOPPSS!...the information in WhoIs is phoney, and we don't >do anything about that. Sorry, guess you're just screwed. There are many other ways to track a spammer. - Do nslookup on the IP that originated the spam (sometimes this takes a bit of detective work to find what IP actually originated the spam). - Traceroute to the originating IP. Email the ISP that is directly upstream. - Look in the Whois information for contact emails and nameservers - if these are for the upstream ISP, or some ISP other than the spammer, report it to them. - If they are advertising a web page, track the web page host, and their upstream, and report it to them. - If the spammer is stupid enough to use their real names, include their phone numbers and addresses in the complaint. Or call them up yourself and tell them what you think. Order pizzas with triple anchovies and pineapple, and no cheese. Order 50 pink flamingos on their front lawn, with a sign saying "Congratulations on your graduation from kindergarten !!" :) The above few lines *were* in jest. I probably would not include the sign. :) >What do spammers and nails have in common? They're both intended for >hammering. Amen. ************************************************** Andrea Di Lecce Rogers@Home Network Operations 1 Mount Pleasant Road, Toronto, M4Y 2Y5 **************************************************

2 1