- NANOG - lists.nanog.org

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 29 Apr '00

29 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 29 Apr '00

29 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

Proposed NANOG topics
by Sean Donelan 29 Apr '00

29 Apr '00

On Fri, 28 April 2000, Paul Ferguson wrote: > What does the list, in general, think about this proposal? I think it is a fine idea. Although some may think it isn't a technical topic, instead handled by PR people and those worried about stock prices, not by engineers. On a more proactive stance, I'd like to see a Best Common Practice for how a service provider configures its management network. We've all seen those USR modems stuffed in ISP racks for "out-of-band" management which are likely connected to POTS lines anyone could call if they knew the "secret" phone number. Secure - A relative term, but secured against at least "common" attacks known and used. Fault-tolerant - The management access stills works, even when the network doesn't. Maintainable - People come and go, if you revoke access is it really revoked everywhere. I've seen several proposals, each with their plus and minus. TACACS, Kerberos and other centralized authorization mechanisms tend to have poor fault-tolerant qualities when dealing with misbehaving networks. SSH distributes the authorization, but tends to be difficult to be sure you have revoked everything, everywhere. SecureID does everything, include slice bread, according to the SecureID sales people. But how well does it work when everything isn't working. Using POTS as your out-of-band access tends to be vulnerable to others having access to the public switched network. Using frame-relay or some other closed-user group data transport tends to have nasty fate-sharing properties with your IP network. Do you have "backup" administrative passwords configured in your network equipment for use only when the network is down. How do you prevent someone from taking down your network, just so they can use those backup passwords. If you don't have backup passwords, what do you do if your password doesn't work. At what point do you punt, and if Murphy still gets you, can you say you did everything reasonable to avoid it with a straight face.

3 2