- Test - lists.nanog.org

RE: How to get better security people
by smd＠clock.org 26 Mar '02

26 Mar '02

| The problem right now is if you advertise for a job, you will get | blasted with literally tens of thousands of resumes. What should I | be telling the HR department to look for? New careers. Sean.

1 0

RE: Exodus/C&W Depeering
by Borchers, Mark 26 Mar '02

26 Mar '02

> -----Original Message----- > > AS3561 (InternetMCI) was once the number 1 ISP, by almost every > measure that existed. The marketplace has not been kind to C&W > since they bought AS3561. Why isn't Adam Smith's Invisible Hand > rewarding C&W? Is C&W number 5 or 6 these days? I think all that shows is that a well-engineered network does not sell itself. Those MCI sales and TSC people did a bangup job of taking care of data customers, from my limited point of view at the time. When the Transaction occurred, overnight my company's account team went from being 3 competent people in a local office to someone who worked out of her house on the other side of the state.

1 0

Re: How to get better security people
by Sean Donelan 26 Mar '02

26 Mar '02

On Tue, 26 Mar 2002, Tony Wasson wrote: > >> If I was looking for top security talent, what would I ask for whether > >> I was hiring directly or outsourcing? > > I agree with Steve Wilcox, incidents are important. I would ask for a > description of the 3 most interesting incidents they've ever worked on, and > what they contributed. I'm sorry, but that's confidential information and I can't disclose it. Would you hire a "security" person, who will likely be involved in the most embarrassing slip ups your company makes, if he tells people about "interesting" incidents at previous employers. Maybe, it depends on what he says.

1 0

RE: How to get better security people
by Jay Fielding 26 Mar '02

26 Mar '02

Jason, I don't know where you get your information, but E*Trade hasn't laid-off their network security department. In fact, we're currently adding to it. I know there are some good network security experts on this list so if you're looking for a position then send your resume my way. Jay Fielding E*Trade NetOps -----Original Message----- From: LeBlanc, Jason [mailto:Jml@ebay.com] Sent: Tuesday, March 26, 2002 11:28 AM To: 'Sean Donelan'; nanog(a)merit.edu Subject: RE: How to get better security people On that note, Etrade layed off their entire net sec team a few months back. I don't trade there no more. ;) > -----Original Message----- > From: Sean Donelan [mailto:sean@donelan.com] > Sent: Monday, March 25, 2002 7:05 PM > To: nanog(a)merit.edu > Subject: How to get better security people > > > > > According to a recent salary survey telephone companies have some > of the lowest paid information security professionals in comparison > with other technology corporations, federal government, or financial > companies. When the US Transportation Security Administration (aka, > the agency in charge of airport screeners) is paying their computer > security people more than telephone companies, its hard for phone > companies to attact top security talent. > > Customers need to let companies know that security and responsiveness > affects their purchasing decisions. I think some companies > are getting > the message. But in today's market, with tight budgets and layoffs, > security is often viewed as overhead. A lot of providers are lucky > if they have one network engineer who does security stuff in her spare > time. Full-fledge security departments are rare. > > > On Mon, 25 Mar 2002, Eric Whitehill wrote: > > UUNet, by far is the best. I've had mixed results with > Sprint. A couple > > of years ago I had to deal with Hurricane Electric and the > tech was really good about > > it - he added in the ACL I needed right over the phone. > > > > Also, I know of a couple providers in the upper midwest > that are pretty > > good at working with DOS stuff. Email me off list if you are > > interested. >

2 1

Re: Odd spam / virus - comments ?
by Steven M. Bellovin 26 Mar '02

26 Mar '02

In message <011301c1d4ad$b5676f10$2028a8c0@carpenter>, "Peter Galbavy" writes: > >OK - As a knowledgeable bunch, maybe you lot can give me pointers. > >A customer / friend phoned me last night saying that I sent him a virus by >e-mail. Now, I am far more careful than that - at least I hope. It turned >out that it wasn't me, but a forgery. Now, that is not unusual, but what is >that the recipient is someone I know. There are worms out there (such as Nimda.E) that use Outlook address books not just for lists of victims, but also as "From:" addresses. In other words, your involvement might be having sent email to someone else who is infected. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

2 1

Odd spam / virus - comments ?
by Peter Galbavy 26 Mar '02

26 Mar '02

OK - As a knowledgeable bunch, maybe you lot can give me pointers. A customer / friend phoned me last night saying that I sent him a virus by e-mail. Now, I am far more careful than that - at least I hope. It turned out that it wasn't me, but a forgery. Now, that is not unusual, but what is that the recipient is someone I know. I have come up with the following theories: 1. Clever virus distributor. Someone has e-mail address lists and is looking up MX records for senders and recipients and then matching the two, on the assuption that the MX for the recipient will accept mail from someone whose mail transits the same system, and that there may be a level of 'trust' in the recipient for a sender who uses the same MX relays. 2. Accident. It is just bizarre that someone is forging mail from me to someone I know. But then I would be getting many more complaints from complete strangers. I am not. Anyone seen 1. in active use ? Headers below - nothing confidential AFAIK - apart from e-mail addresses that are already 'public'. Peter Return-path: <peter.galbavy(a)knowtion.net> Envelope-to: jason(a)somadata.com Delivery-date: Mon, 25 Mar 2002 16:56:14 +0000 Received: from acba293e.ipt.aol.com ([172.186.41.62] helo=Xvfem) by mailstore-1.mail.knowledge.com with smtp (Exim 3.33 #1) id 16pXl2-00003E-00 for jason(a)somadata.com; Mon, 25 Mar 2002 16:55:45 +0000 From: peter.galbavy <peter.galbavy(a)knowtion.net> To: jason(a)somadata.com Subject: Introduction on ADSL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Sy82oU85e2CI78a2nsl20 Message-Id: <E16pXl2-00003E-00(a)mailstore-1.mail.knowledge.com> Date: Mon, 25 Mar 2002 16:55:45 +0000 Status:

1 0

Re: PacBell Security/Abuse contact
by Daniel M. Spielman 26 Mar '02

26 Mar '02

uchicago.edu At 03:05 PM 3/25/2002 -0600, you wrote: >On Mon, 25 Mar 2002 11:18:23 -0800 >"Daniel M. Spielman" <dspiel(a)pacbell.net> wrote: > > > I've had a similar experience with their tech team. I was > > being dos'd from a college in Chicago so I contacted them to > >Mind telling me what college? Hopefully it wasn't us, but since I know >most of my local colleagues it might help if I contact them about this >so they know people on nanog are talking about them (things like that >always help get security the attention it deserves :-). > >John

2 1

Re:RE: 1024-bit RSA keys in danger of compromise (fwd)
by rkuhljr＠uol.com.br 26 Mar '02

26 Mar '02

Does NSA need compromising US-based CA's private keys ? Probably not, because they either (a) already have the private keys, obtained thru a combination of political, financial and intelligence resources. or (b) already have proceedings with the CA's in order to issue valid look-a-like certificates for any domain they want. If you look from the NSA's point of view, the investment might still sound reasonable for cracking the private keys. Rubens Kuhl Jr. >> > >Since you are mentioning Verisign here, and CA authorities in general, has >anyone considered that factoring the CA authority's key is far simpler than >breaking the underlying key [no matter how large?]. Based on the >implementation, the CA's key cannot be changed often or easily. Key >revocations are not automatic or even respected, and the CA's key, once >compromised, can sign any other key you'd like for a beautiful >man-in-the-middle attack. > >The man-in-the-middle is the only attack these keys are designed to thwart, >because if you can't access the physical bits, you don't have anything to >decipher anyway. The beautiful thing about compromising the CA's key is that >its not easily traceable. > >Regards, > >Deepak Jain >AiNET > >-----Original Message----- >From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of >Len Sassaman >Sent: Monday, March 25, 2002 6:32 PM >To: nanog(a)merit.edu >Subject: Re: 1024-bit RSA keys in danger of compromise (fwd) > > > >I discussed this in detail with Lucky before he posted it. I'll give a >summary of how this affects the readers of NANOG here -- feel free to >forward if you like. > >Prior to Bernstein's discovery the row-reduction step in factorization >could be made massively parallelizable, we believed that 1024 bit keys >would remain unfactorable essentially forever. Now, 1024 bit RSA keys look >to be factorable either presently, or in the very near future once Moore's >law is taken into account. However, at a price tag of $2 billion for a >specialized machine, we have a few years before anyone outside of the >intelligence community attempts this. > >What is most concerning to me is a few discoveries that were made while >looking into the problem of widespread use of 1024 bit keys: > >First: Verisign appears to have no minimum requirements for the key sizes >it will sign. I have discussed at length Verisign's active contributions >to the hindrance of security on the Internet in the past (see the >archives of my presentation at DEFCON 9), but I somehow missed this gem. A >few months ago, in fact, Verisign issued a 384 bit certificate. (You could >factor this on your desk top machine in days.) 512 bit keys are also >fairly commonly signed by Verisign. (Ugh.) > >Question for people who know: Does Verisign allow you to submit CSRs for >2048 to 4096 bit certificates? > > >Second: As far as I can tell, OpenSSH (and I assume the commercial >versions of SSH as well) offer no mechanism for enforcing the size of >users' keys when public key authentication is turned on. This means that >users could be placing (factorable) 512 bit keys in their >~/.ssh/authorized_keys files, which is in effect worse than using weak >passwords (as an attacker would leave no false login attempts for you to >detect in your logs). > >I've mailed Theo de Raadt asking if OpenSSH has an undocumented mechanism >for specifying minimum permitted key size that I don't know about. If >there is one, I'll certainly post a follow-up. > > >Lucky also mentions S/MIME, which has so many flaws I'm not going to >address it; PGP, which places the risks squarely on the key-holder and >doesn't prevent the use of 2048 bit keys (which should be safe even taking >Bernstein's findings into account), so I'm not to concerned with that; and >IPsec, which sadly isn't in widespread use. > > >So, my main concerns are TLS, (which is damaged due to poor engineering on >the part of Netscape and Microsoft, and uncouth policy issues on the part >of Versign) and SSH, which may suffer from an easily correctable >engineering flaw. Note that the biggest concerns don't have to do >specifically with 1024 bit keys, but rather, small key sizes in general. > > >--Len. > > >On Mon, 25 Mar 2002, Todd Suiter wrote: > >> >> (forwarded w/o permissions, though this hit bugtraq earlier...t) >> >> >> ---------- Forwarded message ---------- >> Date: Sat, 23 Mar 2002 17:38:02 -0800 >> From: Lucky Green <shamrock(a)cypherpunks.to> >> To: cypherpunks(a)lne.com >> Subject: 1024-bit RSA keys in danger of compromise >> >> As those of you who have discussed RSA keys size requirements with me >> over the years will attest to, I always held that 1024-bit RSA keys >> could not be factored by anyone, including the NSA, unless the opponent >> had devised novel improvements to the theory of factoring large >> composites unknown in the open literature. I considered this to be >> possible, but highly unlikely. In short, I believed that users' desires >> for keys larger than 1024-bits were mostly driven by a vague feeling >> that "larger must be better" in some cases, and by downright paranoia in >> other cases. I was mistaken. >> >> Based upon requests voiced by a number of attendees to this year's >> Financial Cryptography conference <http:/www.fc02.ai>, I assembled and >> moderated a panel titled "RSA Factoring: Do We Need Larger Keys?". The >> panel explored the implications of Bernstein's widely discussed >> "Circuits for Integer Factorization: a Proposal". >> http://cr.yp.to/papers.html#nfscircuit >> >> Although the full implications of the proposal were not necessarily >> immediately apparent in the first few days following Bernstein's >> publication, the incremental improvements to parts of NFS outlined in >> the proposal turn out to carry significant practical security >> implications impacting the overwhelming majority of deployed systems >> utilizing RSA or DH as the public key algorithms. >> >> Coincidentally, the day before the panel, Nicko van Someren announced at >> the FC02 rump session that his team had built software which can factor >> 512-bit RSA keys in 6 weeks using only hardware they already had in the >> office. >> >> A very interesting result, indeed. (While 512-bit keys had been broken >> before, the feasibility of factoring 512-bit keys on just the computers >> sitting around an office was news at least to me). >> >> The panel, consisting of Ian Goldberg and Nicko van Someren, put forth >> the following rough first estimates: >> >> While the interconnections required by Bernstein's proposed architecture >> add a non-trivial level of complexity, as Bruce Schneier correctly >> pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA >> factoring device can likely be built using only commercially available >> technology for a price range of several hundred million dollars to about >> 1 billion dollars. Costs may well drop lower if one has the use of a >> chip fab. It is a matter of public record that the NSA as well as the >> Chinese, Russian, French, and many other intelligence agencies all >> operate their own fabs. >> >> Some may consider a price tag potentially reaching $1B prohibitive. One >> should keep in mind that the NRO regularly launches SIGINT satellites >> costing close to $2B each. Would the NSA have built a device at less >> than half the cost of one of their satellites to be able to decipher the >> interception data obtained via many such satellites? The NSA would have >> to be derelict of duty to not have done so. >> >> Bernstein's machine, once built, will have power requirements in the MW >> to operate, but in return will be able to break a 1024-bit RSA or DH key >> in seconds to minutes. Even under the most optimistic estimates for >> present-day PKI adoption, the inescapable conclusion is that the NSA, >> its major foreign intelligence counterparts, and any foreign commercial >> competitors provided with commercial intelligence by their national >> intelligence services have the ability to break on demand any and all >> 1024-bit public keys. >> >> The security implications of a practical breakability of 1024-bit RSA >> and DH keys are staggering, since of the following systems as currently >> deployed tend to utilize keys larger than 1024-bits: >> >> - HTTPS >> - SSH >> - IPSec >> - S/MIME >> - PGP >> >> An opponent capable of breaking all of the above will have access to >> virtually any corporate or private communications and services that are >> connected to the Internet. >> >> The most sensible recommendation in response to these findings at this >> time is to upgraded your security infrastructure to utilize 2048-bit >> user keys at the next convenient opportunity. Certificate Authorities >> may wish to investigate larger keys as appropriate. Some CA's, such as >> those used to protect digital satellite content in Europe, have already >> moved to 4096-bit root keys. >> >> Undoubtedly, many vendors and their captive security consultants will >> rush to publish countless "reasons" why nobody is able to build such a >> device, would ever want to build such a device, could never obtain a >> sufficient number of chips for such a device, or simply should use that >> vendor's "unbreakable virtual onetime pad" technology instead. >> >> While the latter doesn't warrant comment, one question to ask >> spokespersons pitching the former is "what key size is the majority of >> your customers using with your security product"? Having worked in this >> industry for over a decade, I can state without qualification that >> anybody other than perhaps some of the HSM vendors would be misinformed >> if they claimed that the majority - or even a sizable minority - of >> their customers have deployed key sizes larger than 1024-bits through >> their organization. Which is not surprising, since many vendor offerings >> fail to support larger keys. >> >> In light of the above, I reluctantly revoked all my personal 1024-bit >> PGP keys and the large web-of-trust that these keys have acquired over >> time. The keys should be considered compromised. The revoked keys and my >> new keys are attached below. >> >> --Lucky Green > > >

1 0

RE: PacBell Security/Abuse contact
by Joe Blanchard 25 Mar '02

25 Mar '02

Pacbell's Abuse/Security Depts are totally useless with regard to assisting its own customers, let alone defending them. For the better portion of a few months now, I've emailed/called many times with regard to CodeRed boxes (On their netblocks) and have yet to see them take any action. Anyone I talked with there indicated, after giving them the offending IPs, that someone would contact the customer and get it resolved. To date nothing has been done. I still see the same anonying IPs looking for codered stuff on my Apache systems. I won't even get started about the Caymen routers that have no password set on them, and the list of 30 of them I emailed to thier NOC/Abuse and a sales rep. That was over 3 months ago, and still they seem to be wide open, at least a few (I suspect someone changed them, probably were hacked given this amount of time.) I can understand their wanting to keep their customers anonymousness, but if they won't followup with them to (in this case help themselves) erraticate infected boxes that are on their business customer's DSL, doesn't that place them in the area of liability? Don't know, Just my 2¢s -Joe > ---------- > From: Jeremy T. Bouse[SMTP:Jeremy.Bouse@undergrid.net] > Sent: Sunday, March 24, 2002 11:11 PM > To: nanog(a)merit.edu > Subject: PacBell Security/Abuse contact > > > Anyone have a telephone number that can reach a live person > within Pacific Bell's Security/Abuse department? PacBell's technical > support is completely inept with trying to help their customers when > under any form of network attack other than passing you to a toll-free > number which informs you to send email to an address that goes without > answer. > > Respectfully, > Jeremy T. Bouse > UnderGrid Network Services >

2 1

RE: long distance gigabit ethernet
by LeBlanc, Jason 25 Mar '02

25 Mar '02

The new 15540 is a much better box, not much more $ either. There are some other people making extremely killer products, ONI being one that is very popular. I wouldn't invest in a 15454 anymore with all the new products out there, we still use them, but anything new will be a better box. > -----Original Message----- > From: Barton F Bruce [mailto:barton@cent.net] > Sent: Friday, March 22, 2002 5:17 PM > To: Antony; Greg Pendergrass > Cc: Richard A Steenbergen; 'Nanog@Merit. Edu' > Subject: Re: long distance gigabit ethernet > > > > The Cerent 454 (now cisco 15454) has 2 port Gig-E cards that > cost a little > more than a PA-GE card. The pair of ports shares OC-12 > available to that > slot (I'm assuming this is NOT an OC-192 equipped shelf) and > the bandwidth > can be split in certain multiples of STSes (OC-1), or used > totally for one > port. You only need as many STSes between boxes as you want to use. > > You can play some nice games with 802.1Q VLANs and multiple > sites, too. > > There is a newer 4 port Cerent gig-E card I have not seen, > but that probably > can do a FULL gig-E on at least 2 of the ports (i.e. use a > full OC-48 if the > box has the OC-192 cross connect matrix installed). This > newer card I think > is only for point to point and does not "understand" VLANS, > though probably > can carry them. > > Some DWDM boxes have their own gig-E ports. We have Sycamore > ones that give > us several Boston, NYC, and Reston routers on the same ethernet. > Consider also that many switches support what cisco calls > ether-channel. If > one gig-E isn't enough, add more in parallel. Any router on > this "ethernet" > can freely talk to any other. > > You are not stuck with just one router talking to one at the > other end. > > ----- Original Message ----- > From: "Antony" <antony(a)phenome.org> > To: "Greg Pendergrass" <greg(a)band-x.com> > Cc: "Richard A Steenbergen" <ras(a)e-gerbil.net>; "'Nanog@Merit. Edu'" > <nanog(a)merit.edu> > Sent: Friday, March 22, 2002 12:28 PM > Subject: Re: long distance gigabit ethernet > > > > > > On Fri, Mar 22, 2002 at 11:54:05AM -0500, Greg Pendergrass wrote: > > > > > > I'm going to take a stab and assume that you're actually > more interested > > > in finding a longhaul line with GigE on the ends, and not > so much how > many > > > miles you can get with whatever optics... > > > > > > Absolutely right, I don't care what's in between as long > as I have GigE > at > > > the end. Other options include using wave (too > expensive), or ethernet > over > > > MPLS (worth considering although latency may be too high > for longer that > > > 1000 miles). > > > > there are solutions of this type. SURFNet line, currently > used for test > > and network research is an example. > > It is from Amsterdam to Chicago. It is presented as GigE at > the ends. > > > > So fairly long distance, RTT is 93 msec.Actually it terminate as > > SONET OC48 that goes too TDM Switch which has GigE interfaces. > > So there is SONET encapsulation in the middle. In theory we can get > > upto 2.5Gbps. > > > > Line is provided by Teleglobe. End equipements are > > CISCO, ONS 15454. This don't do any routing. > > > > This page may be interesting to browse. > > http://carol.wins.uva.nl/~delaat/optical/index.html > > > > You can probably find different variants of such non > standard technology > > from other carriers. > > > > -antony > > > >

1 0