April 2000 - Test - lists.nanog.org

Re: RE: SSH on IOS (was RE: ABOVE.NET SECURITY TRUTHS?)
by Shawn McMahon 30 Apr '00

30 Apr '00

There are lots of ways to make this work: Digiboard or Rocketport in the Linux box. Real terminal server (Livingston is good, Computone Powerrack is cheaper, has more ports per Rack Unit, and is good enough for this usage) in the rack with direct Ethernet connect to a Linux box racked right above it, so physical security is still easy, then SSH to the Linux box. If you lock that Linux (or Open/Free/Net-BSD) box down so it accepts NOTHING other than that SSH traffic, you could even slap a hub down and use it to direct Ethernet management traffic, although that opens you up to possible sniffing if a router is cracked. Best to stick with the serial solutions, but they can be pretty damn cheap. Certainly cheaper than breakins. Figure anywhere from $500 to $1,500 for the Linux server (depending upon the quality of components, and whether you put it in a rack-mount case or just drop it on top of the terminal server), and $2,500 for a Computone Powerrack (with ISP discounts, and using the pricing I remember from years ago, which could very well have changed), with no expenditure on software at all (unless you count $1.99 for a CD from CheapBytes) and you're looking at a damned cheap, damned secure system that your entire staff can use. You could even log all the traffic on the Linux box, provide scripts for common tasks and keep them on the isolated server where they're safe, or even (if you needed to) tcpdump all the traffic to the terminal server for infinite levels of security micromanagement. All for less than the cost of the consultants who'd sell you the less-secure versions of securing this traffic. On Fri, 28 Apr 2000, "Roeland Meyer (E-mail)" wrote: > Date: Fri, 28 Apr 2000 19:24:32 -0700 > To: "'John Fraizer'" <nanog(a)EnterZone.Net>, > "'Jason Ackley'" <jason(a)ackley.net> > From: "Roeland Meyer (E-mail)" <rmeyer(a)mhsc.com> > Reply-To: <rmeyer(a)mhsc.com> > Subject: RE: SSH on IOS (was RE: ABOVE.NET SECURITY TRUTHS?) > > > Actually doing that now, with a Linux box and an old Livingston PM2E. > Linux box runs SSHD, the portmaster runs directly into console ports > 'stead of modems. I figured that was obvious. However, I don't run a > co-lo either. Most of my systems reside in them. This is okay, until your > ladders have to run through semi-public space. There is also a 50 foot > length restriction, on RS-232 lines, unless you like running at less than > 115K baud. Also, figure the expense of the extra hardware. In my case, it > was unused sunk-cost anyway (surplus, for you non-suits).

3 2

Re: ABOVE.NET SECURITY TRUTHS?
by Hank Nussbacher 30 Apr '00

30 Apr '00

At 09:40 30/04/00 -0400, you wrote: Old version. Try: http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip -Hank >% TACACS encryption won't help if you follow the Cisco Essential IOS Features > > Good document! > (http://www.cisco.com/warp/public/707/EssentialIOSfeatures_pdf.zip > for anyone who hasn't seen it) > > >% "aaa accounting command 15 start-stop tacacs+" can be considered an >% unintentional backdoor for many. > > Use the source, Luke. Unfortunately you would still be shipping > the data over the network, but the free tacacs+ source can be > tweaked as you like to keep it from being logged. > >--------------------------------------------------------------------------- -- >Bryan S. Blank bryan(a)supernet.net > (443)394-9529 tele > (410)995-2191 page > (410)802-6998 emer > >

1 0

Santayana's Revenge
by Sean Donelan 30 Apr '00

30 Apr '00

On Fri, 28 April 2000, Paul Ferguson wrote: > Not that I'm a money-grubbing, stock-sucking bastard, but speaking > as a member of the "community", I'm a little spooked by how reckless > journalism, and off-hand comments on mailing lists, affect peoples > (read: companies) financial futures (this is actually just the tip > of the proverbial iceberg). Companies face a dilemma. On one hand the FBI doesn't want them to reveal critical information to the public. The FBI is setting up an InfraGuard program supposedly to allow companies to share "private" information without it getting out to the public. On the other hand the SEC wants them to keep all its investors informed about material information. Sharing information with only a few people outside the company may also get you in trouble. Is there a correct answer for all situations? I don't know. I've seen bad outcomes from both no disclosure and full disclosure. > If things/people/processes/architecture/etc. is at fault, then let's > discuss it as a community that wishes to propel ourselves into the > promising future. Otherwise, let's just demonize everyone whow learns > their lesson the old fashioned way -- with failures. But a lack of self-criticism does make a mockery of the claim that Internet is a mature institution, and it exposes the net to the risk, noted by Santayana, that those who dont understand their history are doomed to repeat it. (plagiarized from numerous places) Are there really any new types of attacks? Or is it just variations on existing themes?

1 0

Re: ABOVE.NET SECURITY TRUTHS?
by Steven M. Bellovin 29 Apr '00

29 Apr '00

In message <Pine.BSO.4.21.0004281457540.31198-100000(a)dqc.org>, Chris Cappuccio writes: > >On Fri, 28 Apr 2000, Mr. James W. Laferriere wrote: > > | > | > | Hello Dylan, Knew this was coming . But I'd hoped that > | the supported platforms would have been a little larger . > | Just the 7200 & UP . Seems cisco thinks ssh puts a bit > | of load on a cpu ? I can't see that for just a terminal > | session though . Twyl, JimL > | > >The ssh server should optimally generate new keys every so often (every few >hours?) Disable that feature; you probably don't need it in this situation. Here's what's going on. Stock sshd generates a new, relatively short, RSA key pair once an hour. This key is used to exchange the session key that actually protects the data. Your normal public/private key pair (the stuff that's in your identity and identity.pub files) is used to authenticate the exchange, rather than to transmit the session key. Why that whole song and dance? The idea is to approximate a cryptographic property known as "perfect forward secrecy". Perfect forward secrecy says that if, some time in the future, your machine is compromised, the enemy can't read past traffic. In this case, since that RSA key pair is discard hourly, and that is the only key that can decrypt the session key, our old traffic is protected. It's only readable if the machine is penetrated while that key is live. Now -- in this case, the generator of that key is the router itself. If the bad guys have enough control of the router to pry out a private RSA key -- a key for which there is no conceivable need for any API or CLI way to read -- those same bad guys can pry anything else they want out of the router, including its enable password. They can also change the configuration to make it possible to log back in without going through complicated shenanigans. The real purpose of that feature of sshd is to protect access to a multiuser system, where there's much more risk of compromise, and where more general secrets might be protected by the connection. As for the expense of ssh -- the big issue is login, when a lot of public key operations are taking place. But even output is rather expensive, since it's doing a 3DES operation for each eight output bytes. Worse yet, if the output is passed to the sshd piece a byte at a time, it will do a 3DES operation for each byte. That almost certainly happens for each keystroke, but most people don't type enough or fast enough for that to be an issue.

8 10

Re: ABOVE.NET SECURITY TRUTHS?
by Alec H. Peterson 29 Apr '00

29 Apr '00

Alexei Roudnev wrote: > > Yes. > > And (I add) with priv-level. Or with TACACS+ server-side modifications that allow you to use per-user enable passwords (it isn't standard with the public domain server, but the modifications are a piece of cake). > > But it's for the work from remote places - I don't thgink you'll use One Time Passwords (at least manually) for the every day > configurations... Don't be too sure; in a former life I did just that and it worked great (using one-time passwords for enable access). Sure people complained for a while, but once everybody gets used to it it's not a big deal. Alec -- Alec H. Peterson - ahp(a)hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"

1 0

RE: Cutting to the chase (was RE: ABOVE.NET SECURITY TRUTHS?)
by Roland Dobbins 29 Apr '00

29 Apr '00

There was no implication of 'dirty little secrets' intended; on the contrary, Cisco have been great to deal with on issues of this type, and very prompt to disseminate security-related information. I have no problem with Cisco, quite the opposite. What I have a problem with is people who point the finger and shout "J'accuse!" from the sidelines. You folks at Cisco are extremely forthcoming, and your efforts in this sphere are much appreciated. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Paul Ferguson [mailto:ferguson@cisco.com] Sent: Friday, April 28, 2000 4:44 PM To: Roland Dobbins Cc: nanog(a)merit.edu Subject: Re: Cutting to the chase (was RE: ABOVE.NET SECURITY TRUTHS?) Well, yes, we have been trying to do "due diligence to ensure that we publicly notify our customers, and the public at-large, of any known security problems with our products. These are not dirty little secrets -- we believe that our customers deserve to know, as soon as possible, when we have found vulnerabilities in out products. As stated in most on the advisories, we post these security advisories to: cust-security-announce(a)cisco.com bugtraq(a)securityfocus.com first-teams(a)first.org (includes CERT/CC) cisco(a)spot.colorado.edu comp.dcom.sys.cisco Various internal Cisco mailing lists Secondly, and to the best of my knowledge, I know of no instance where the Catalyst enable password vulnerability has been used by an attacker to exploit a customer's network. For further information, see: http://www.cisco.com/warp/public/707/advisory.html and http://www.cisco.com/warp/public/707/sec_incident_response.shtml Cheers, - paul At 02:16 PM 04/28/2000 -0700, Roland Dobbins wrote: >First of all, there -is- a bug in the Catalyst Supervisor software revision >5.4.1 which basically disables the functionality of the enable password. If >someone has the login password to the router, they can use the same password >to get to enable mode. Yes, someone has to either a) get his password >sniffed internally or b) re-use the password on some external network which >allows it to get sniffed or c) use a weak and/or easily-guessable password >for this exploit to be used. But your blanket statement about the enable >password on Cisco switches is incorrect. And while shared segments are >generally a Bad Thing, there are certain instances in which they make sense. > >See http://www.cisco.com/warp/public/707/catos-enable-bypass-pub.shtml for >more details. > >Secondly, there's also a bug in the Cisco telnet daemon for IOS 11.3AA, >12.0(2)-12.0(6) and 12.0(7), excluding 12.0(7)S, 12.0(7)T, and 12.0(7)XE, >which allows a very easy DoS attacks against routers and switches running >those revs. The bug ID is CSCdm70743, and more information can be found at >http://www.cisco.com/warp/public/707/iostelnetopt-pub.shtml . > >Thirdly, 12-series IOSes can make use of ssh, but there are a lot of other >issues with the 12.x revs (see the above paragraph for an example) which >have prevented their wide-scale adoption. Kerberos is certainly an option, >and a good one, but Monday-morning quarterbacking is really easy, especially >when one doesn't have direct knowledge of all the various factors involved, >nor any responsibility for maintaining the network in question.

3 3

Timeline
by Sean Donelan 29 Apr '00

29 Apr '00

Timeline 4/25/2000 9:45am PDT Approximate beginning of service interruption 4/25/2000 10:48am PDT First post to NANOG about problem 4/25/2000 10:57am PDT NANOG post "all circuits busy" calling provider NOC 4/25/2000 11:27am PDT First post from provider executive to NANOG 4/25/2000 2:09pm PDT Provider client communication (Switch Related Issues) 4/25/2000 5:30pm PDT First news report published in trade press 4/25/2000 7:43pm PDT Provider client communication (Network Issues) 4/26/2000 7:17pm PDT Customer letter from provider executive officers Overall a very impressive response by the provider.

1 0

Re: ABOVE.NET SECURITY TRUTHS?
by Michael Shields 29 Apr '00

29 Apr '00

In article <390A5FB7.3D969653(a)pluris.com>, Bora Akyol <akyol(a)pluris.com> wrote: > There is even a port of ssh to the Palm Pilot. Note that a Palmpilot has more CPU than a 2501. (But ssh is cheap enough for either.) -- Shields.

1 0

Example of good customer communication
by Sean Donelan 28 Apr '00

28 Apr '00

CSX experienced a communication outage this morning in their MCI/Worldcom supplied network. Here is an example of CSX's customer notification http://www.csxt.com/cus/pressview.cfm?ID=3191

2 1

Re: Cutting to the chase (was RE: ABOVE.NET SECURITY TRUTHS?)
by Danny McPherson 28 Apr '00

28 Apr '00

> I have suggested to Susan Harris (who does a FANTASTIC job > of putting the NANOG meeting agenda together) that it might > be interesting to have a panel session at the Albuqureque > NANOG consisting of several folks (including popular trade > press journalists) to discuss the "damage factor" in > disinformation. I think this is a good suggestion Paul, especially since NANOG is overflowing with disinformation experts :-) -danny

2 1