- Test - lists.nanog.org

Re: Panix.com should be back.
by Hannigan, Martin 17 Jan '05

17 Jan '05

Thanks Fared for your assistance. Ypu are great among a bun --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: nanog list <nanog(a)merit.edu> Sent: Sun Jan 16 19:57:54 2005 Subject: Panix.com should be back. I see that DNS changes has been reverted http://www.dnsreport.com/tools/dnsreport.ch?domain=panix.com I have also contacted our Customer owner of ns1.ukdnsservers.co.uk [panix.com] (142.46.200.67) they have assured me they will remove the DNS config as well. Sorry for the last response I was away for weekend. -- Majid Farid Telecom Ottawa Limited. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Gadi Evron Sent: Sunday, January 16, 2005 7:24 PM To: nanog list Subject: domain hijacking - what do you do to prepared? Until today, I considered this to be a real and relevant threat, although rather low in my matrix. As someone I know said today, now that kiddies saw how much "fun" this is, I am sure they will attempt this again. The question that comes to mind is - what do you do to be prepared? I suppose that other than setting registrar lock in place, there is another thing one can do. Study! Whether it's checking the expiration date for your domain, establishing contact with your up-in-line authority - registrar, tld, etc. depending on who you are. Having the relevant contact information at hand, establishing a set policy on how to handle such an incident and who to contact, bugging your next-in-chain about setting a policy on this with you, as well as setting such a policy for those who are slaves to you. That said, all that is left now is to see how this happened (so that it won't happen again - just killing a fire doesn't mean it won't be re-ignited) and perhaps think a bit on how we do things - which I am sure many will now do. Maybe this can be another discussion issue for the next NANOG get-together as well? Gadi.

1 0

Re: Association of Trustworthy Roots?
by Hannigan, Martin 17 Jan '05

17 Jan '05

I saw Martians this evening, just like the movie, but the country song didn't work. They -did- have big heads encased in glass. Go figure. -M --- Martin Hannigan hannigan(a)verisign.com Verisign, Inc. -----Original Message----- From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> To: North American Network Operators Group <nanog(a)merit.edu> Sent: Sun Jan 16 19:39:01 2005 Subject: Re: Association of Trustworthy Roots? Christopher L. Morrow wrote: >On Sun, 16 Jan 2005, Chris Adams wrote: > > >>If the proper procedure was circumvented in the first place (which >>appears to be the case with panix.com) then it should be circumvented >>to repair the damage as fast as possible. >> >> > >If it can be proven to have been cicumvented, sure. I don't think anything >beyond conjecture about that has been said 'publicly' yet, has it? > > > Why yes, you must have missed the messages. The domain owner and ISP and registrar all clearly stated that they had received no notification, and had not approved the transfer. Notification and approval are required by the process. Therefore, it was proven to be circumvented. QED. Now, as to the actual mechanism of circumvention, that has not yet been revealed here. All we know is that a registry *supervisor* stopped the workers from finishing their investigation. Clearly, this .com registry operator is not trustworthy. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

Regarding panix.com
by Bruce Tonkin 17 Jan '05

17 Jan '05

Hello All, Melbourne IT restored the nameservers and contact details associated with this name first thing this morning (Monday in Melbourne, Australia). We are arranging with the previous registrar (Dotster) to have the name transferred back. We are also investigating the chain of events that led to the problem in the first place. This will take longer, due to the various timezones and parties involved. In this case one of the parties was an ISP in the United Kingdom, which is a reseller of Melbourne IT. Regards, Bruce Tonkin Chief Technology Officer Melbourne IT

3 2

Re: panix.com hijacked (VeriSign refuses to help)
by Thor Lancelot Simon 16 Jan '05

16 Jan '05

Alexis Rosen tried to send this to NANOG earlier this evening but it looks like it never made it. Apologies if it's a duplicate; we're both reduced to reading the list via the web interface since the legitimate addresses for panix.com have now timed out of most folks' nameservers and been replaced with the hijacker's records. Note that we contacted VeriSign both directly and through intermediaries well known to their ops staff, in both cases explaining that we suspect a security compromise (technical or human) of the registration systems either at MelbourneIT or at VeriSign itself (we have reasons to suspect this that I won't go into here right now). We noted that after calling every publically available number for MelbourneIT and leaving polite messages, the only response we received was a rather rude brush-off from MelbourneIT's corporate counsel, who was evidently directed to call us by their CEO. We are also told that law enforcement separately contacted VeriSign on our behalf, to no avail. Below please find VeriSign's response to our plea for help. We're rather at a loss as to what to do now; MelbourneIT clearly are beyond reach, VeriSign won't help, and Dotster just claim they still own the domain and that as far as they can tell nothing's wrong. Panix may not survive this if the formal complaint and appeal procedure are the only way forward. > Date: Sun, 16 Jan 2005 00:21:33 -0500 > To: <alexis(a)panix.com>, NOC Supervisor <nocsupervisor(a)verisign.com> > Subject: Re: FW: [alexis(a)panix.com: Brief summary of panix.com hijacking incident] (KMM2294267V49480L0KM) > From: VeriSign Customer Service <info(a)verisign-grs.com> > X-Mailer: KANA Response 7.0.1.127 > > Dear Alexis, > > Thank you for contacting VeriSign Customer Service. > > Unfortunately there is little that VeriSign, Inc. can do to rectify this > situation. If necessary, Dotster (or Melbourne) is more than welcome to > contact us to obtain the specific details as to when the notices were > sent and other historical information about the transfer itself. > > Dotster can file a Request for Enforcement if Melbourne IT contends that > the request was legitimate and we will review the dispute and respond > accordingly. Dotster can also contact Melbourne directly and if they > come to an agreement that the transfer was fraudulent they can file a > Request for Reinstatement and the domain would be reinstated to its > original Registrar. Dotster could submit a normal transfer request to > Melbourne IT for the domain name and hope that Melbourne IT agrees to > transfer the name back to them outside of a dispute having been filed. > In order to expedite processing the transfer or submitting a Request for > Reinstatement however Dotster will need to contact Melbourne IT > directly. If Dotster is unable to get in touch with anyone at Melbourne > IT we can assist them directly if necessary. > > Best Regards, > > Melissa Blythe > Customer Service > VeriSign, Inc. > www.verisign.com > info(a)verisign-grs.com

11 15

Melbourne IT
by Chris Cappuccio 16 Jan '05

16 Jan '05

Melbourne IT invites you to participate in a survey of brand recognition. Please let them know what the name "Melbourne IT" means to you. http://www.melbourneit.com.au/survey.php?type=brandhealth -- The past cannot be changed. The future cannot be guaranteed.

1 0

RE: Proper authentication model
by Hannigan, Martin 16 Jan '05

16 Jan '05

> -----Original Message----- > From: Joe Abley [mailto:jabley@isc.org] > Sent: Wednesday, January 12, 2005 12:05 PM > To: Hannigan, Martin > Cc: NANOG list > Subject: Re: Proper authentication model > > > > On 12 Jan 2005, at 11:53, Hannigan, Martin wrote: > > >> You mean you'd *request* a different path from different providers. > > > > Provisioning a circuit from two different ^providers^, other than > > your OC3 provider. > > I realise that's what you meant. > > My point was that competing, differently-named and > organisationally-separate suppliers of network services > frequently use > common suppliers for metro fibre, long-haul transport, > building access, > etc. Just because you buy different services from different providers > doesn't mean there will be no common points of failure. There may be common points of failure like a carrier hotel, but I haven't been told I couldn't see loop or longhaul maps when planning a circuit, except when buying from other than a carrier[1] or tier2. Primary and protect should be geographically seperated and if your carrier isn't buying access to BOTH conduits in your entrance facility, you should ask why. I just don't usually see this problem and I've *never* not been able to get into a facility remotely by the diversified frame M/S method. If we're talking semantics, order type 2 ds0s. [1] I'm talking RBOC tier1 for the most part. I would consider tier 1 to be SBC, AT&T, MCI, Sprint, etc. Facilities based. -M<

2 1

Re: panix.com
by Eric Brunner-Williams in Portland Maine 16 Jan '05

16 Jan '05

The outcome I expected when Bruce got involved. ------- Forwarded Message From: "Bruce Tonkin" <Bruce.Tonkin(a)melbourneit.com.au> To: "Eric Brunner-Williams in Portland Maine" <brunner(a)nic-naa.net> Cc: <smb(a)cs.columbia.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic-naa.net id j0GIZIlC038110 Hello Eric, Thanks for letting me know. We will ensure the name is restored to its correct status, and are investigating how the incident occurred. Regards, Bruce Tonkin > -----Original Message----- > From: Eric Brunner-Williams in Portland Maine > [mailto:brunner@nic-naa.net] > Sent: Sunday, 16 January 2005 10:49 AM > To: Bruce Tonkin > Cc: smb(a)cs.columbia.edu; brunner(a)nic-naa.net > Subject: panix.com > > Bruce, > > Steve just sent this note to NANOG. > > panix.com has apparently been hijacked. It's now associated > with a different registrar -- melbourneit instead of dotster > -- and a different owner. Can anyone suggest appropriate > people to contact to try to get this straightened out? > > --Prof. Steven M. Bellovin, > http://www.cs.columbia.edu/~smb > > I know Steve and you know me, so lets see if this is > malfesance or error. > > Eric > ------- End of Forwarded Message

1 0

apropos of nothing
by Eric Brunner-Williams in Portland Maine 16 Jan '05

16 Jan '05

Oki all, I was interested in a policy I came across recently at a cctld registry. If a domain has no (or few for some value of few) hits over some period of time post-registration, the registry will recover the string and let another user acquire it, and presumably actually use it. So if t = 3m, pokey.cctld could go to four users in the course of a single year, iff the first three made insufficient use of pokey.cctld during that time. I'm going to guess that panix.com is different from most of the multi-k domains that are dropping off the VGRS registry and into today's (well, yesterday's) drop pool, as measured by use. I'm going to guess that panix.com is different from most of the multi-k inter-registrar transfers of yesterday, today, and tomorrow, by the same use metric. IMHO, organizing policy around function, actually distinguishing between panix.com and the overwhelming majority of domain names for which some change of state at the registry occurs, is a better principle that to continue to organize policy around trademarks and their buyers and agents, indifferent to the frequency and distribution of use of a domain name. At some point, it really _is_ a name-to-addresss map, and not a cognate for a trademark-to-owner map. It is possible to distinguish risk, and a policy which chooses not to make distinctions isn't prudent. In case anyone's missed the obvious, we now have an incoherent dns, and caching resolver operators have introduced the incoherency, and no one in the operator community is visibly spitting blood at the intentional exception to rfc2826. This situation should not continue. Neither should the "new/hijacked" answers be served. Eric

1 0

Proper authentication model
by Kim Onnel 16 Jan '05

16 Jan '05

Hello, I'd like everyones 2 cents on the BCP for network management of an ISP PoPs, with a non-security oriented NOC, Most of my routers doesnt have crypto IOS images, couldnt agree with core members to do a major upgrade, just a promise of doign that when other needs to an IOS upgrade come up, So i need to workaround it and secure management traffic somehow, Usually the NOC logs to the PoPs 24x7, so i definitely need to hit a balance between encryption/security and usability, thats why i excluded OTP, My homework concluded: 1) Establishing an ipsec tunnel from each NOC Pc to a VPN concentrator, and of course on every PC, there would be static routes injected to take management traffic through the tunnel, Major advantage is usability and transperancy to the user, One major pitfall here is when ipsec tunnels break, my presence would be needed to troubleshoot that, 2) An OpenBSD bastion host(s), where the NOC would ssh in, get authenticated from TACACS+ or ssh certs, and then just telnet from there all day, One major advantage here is the heavy monitoring/limiting i can do on a *nix box, systrace their login shell to a policy (telnet/ping/traceroute only) 3) Or just an IOS based bastion router that also runs ssh, This has the advantage of IOS limitations in a way, not much maintaining is needed but being limited with 16 vtys is a problem, also vtys may get stuck and all these ssh sessions would kill the memory of the router, I would of course have multiple setups one at the Datacenter, another at some PoP, redundant solutions incase one fails, and For the record, I do run rancid, syslogging and we do AAA, so its just down to whats others experiences/ideas about secure management?

9 13

Re: panix.com hijacked
by Thor Lancelot Simon 16 Jan '05

16 Jan '05

Apologies for what may be another duplicate message, probably with broken threading. This is Alexis Rosen's original posting to this thread; we think the mail chaos caused by the hijacking of panix.com kept it from ever reaching the list (but, flying mostly-blind, we aren't sure). > On Sat, Jan 15, 2005 at 10:27:31PM -0500, Steven M. Bellovin said: > > panix.com has apparently been hijacked. It's now associated with a > > different registrar -- melbourneit instead of dotster -- and a > > different owner. Can anyone suggest appropriate people to contact to > > try to get this straightened out? > > Hi, all. > > I hate to pop my head up after years of lurking, only when things are > going bad, but probably better that than remaining silent. > > First of all, I'm going to be bounced from this list once its cache of > my DNS times out, which will probably be in about 2-3 hours, so if you have > anything to say that you'd like me to see, please copy me. We're temporarily > accepting mail at panix.net in addition to panix.com, so use alexis (at) > panix.net. > > A few points to respond to: > First, Eric, thanks for contacting Bruce and Eric on my behalf. While > nothing has happened so far, I hope that it will soon, and in any case > I appreciate your efforts to help a total stranger. > > Someone asked if we had registrar-lock set. It's not clear to me what > happened. Our understanding is that we had locks on all of our domains. > However, when we looked, locks were off on panix.net and panix.org, which > we own but don't normally use. It's not clear how that happened; dotster > has yet to contact us with any information about, well, anything at all. > They did answer a call this morning; they're apprently in the middle of > an ice storm. All I was able to larn from them is that according to the > person I talked to, they had no records of any transfer requests on our > domain from today back through last October. > > Someone suggested invoking a dispute procedure. We'll do that, as soon as > we can get someone to actually accept the dispute, but if it goes through > that process to completion, many people will suffer, and Panix itself will > be tremendously damaged. How long do you think even our customers will > stay loyal? (Forever, for many of them, but that doesn't mean the won't be > forced to start using a different service.) > > While it's true that MelbourneIT won't do anything before (their) Monday > morning, I don't want to paint them as bad guys in this drama. I don't > know how they're organized and I don't know how difficult it is for them > logistically. Of course I want them to move faster. Much faster. But I'll > take what I can get. > > And speaking of MIT, I don't intend to send them "nastygrams" - nor NSI > either. Neither of them owes me anything (at least directly) and being > heavyhanded would not be a good way to get what I want (restoral of the > panix.com domain to dotster) even if I thought they deserved it. I expect > that there will be criminal prosecutions arising out of this, but the time > for that sort of thing is later, when things are back to normal, and we've > fixed any systemic vulnerabilities that can be fixed before they're used > to wreak mass havoc. And it's anyone's guess who the target of those > prosecutions will be, but I doubt MIT or NSI will be among them. > > Lastly, someone expressed surprise that I'd call MIT's lawyer directly. > I didn't. I spent *hours* trying to find working contact info for MIT and > Dotster. I didn't find useful 24-hour NOC-type info anywhere. (Someone > obviously has this info; I expect it's restricted to a list of registrars.) > I reached Dotster's customer support when they opened for business Saturday > morning; the guy was polite, and did what he could, but I saw no evidence > whatsoever of the promised attempt to assist me after he got off the phone. > MIT apparently has no weekend support at all; I finally located their CEO's > cellphone in an investor-relations web page. I caled him, and he had his > lawyer call me back. That was his choice. FWIW, she's not "just" a lawyer; > she's apparently the person who has to make decisions about reverting > control of the domain. So she at least needs to be aware of our position. > My impression is that she didn't fully grasp the gravity of the situation, > and so treated us like she'd treat any other annoying customer who managed > to track her down on her day off. This is somewhat understandable (though > infuriating) which is why I'd hoped to talk to someone on their tech side > first. No luck there, but if any of this reaches them, maybe that will > start things going. > > Thanks again to everyone who has tried to help us today. > > /a

1 0