- Test - lists.nanog.org

Re: A watched pot never boils: The Return of Code Red
by Vern Paxson 01 Aug '01

01 Aug '01

> I checked my apache logs this morning, and I do see some Code Red > activity: We've seen > 800 attacks so far. The growth rate is a clear exponential, no sign of any slowdown yet. Vern

3 2

Visio icons
by Grant A. Kirkwood 01 Aug '01

01 Aug '01

My apologies for the non-operational content. I'm trying to find the Cisco Visio icon set, would anyone have a copy they could shoot me? TIA, -- Grant A. Kirkwood - grant(a)virtical.net Chief Technology Officer - Virtical Solutions, Inc. http://www.virtical.net/

5 4

A watched pot never boils: The Return of Code Red
by Sean Donelan 01 Aug '01

01 Aug '01

After eight hours of Code Red II, I haven't seen any impact. So far the only website I can't reach is WWW.KEYNOTE.COM Everything else seems to be humming along just fine. Of course, exponential growth starts out small. Any updates from the field?

2 1

RE: telnet vs ssh on Core equipment , looking for reasons why ?
by Roeland Meyer 01 Aug '01

01 Aug '01

> From: Rafi Sadowsky [mailto:rafi-nanog@meron.openu.ac.il] > Sent: Tuesday, July 31, 2001 10:43 PM > > On Tue, 31 Jul 2001, Charles Sprickman wrote: > > > > > On Tue, 31 Jul 2001, Kevin Steves wrote: > > > > > On Tue, 31 Jul 2001, Charles Sprickman wrote: > > > :6) Finding a unix ssh that supports 3DES and DES. > > DES(not 3DES) is a compile time option for SSH1 > (default is not to support DES) > > Try to convince to person in charge of SSH that even > SSH1+DES while weak > is much better than cleartext tel-net .... SSH1, properly deployed, is not all that weak and scads better than (any version) telnet.

1 0

RE: Hard data on network impact of the "Code Red" worm?
by Roeland Meyer 01 Aug '01

01 Aug '01

> From: Hank Nussbacher [mailto:hank@att.net.il] > Sent: Monday, July 30, 2001 11:41 PM > bandwidth - typically FastEthernet. So targetting IIS > servers is a sure > way of maximizing your zombie power (the only more powerful > worm would be > an Apache zombie which has about 18M potential clients or a > bind worm-zombie). Cut it out! You're making my blood run cold. Four years ago, I had three systems cracked by mwsh. The entry was via BIND. They were a Linux boxen and the exploit downloaded mwsh source code and compiled it. It could, just as easily, do that with CodeRed sources. Fortunatelyy, most BIND installations have been upgraded since then. But, I'll bet that there are a few that haven't been. Is Raul Dhesi listening? <shudder>

23 39

RE: telnet vs ssh on Core equipment , looking for reasons why ?
by Roeland Meyer 31 Jul '01

31 Jul '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Tuesday, July 31, 2001 3:10 PM > > On Tue, 31 Jul 2001 14:59:25 PDT, Roeland Meyer said: > > > You are probably aware, but EFF published the DES crack. I > understand that > > it is now an issue of cracking DES in less than 12 hours. > 3DES is better > > but it only amounts to DES with a 128-bit key. > > Actually, 3DES has a 112 bit effective key. However, > although that's only > double the key length, the *difficulty* is a bit more than > twice as much. > Assuming a brute-force of a 56-bit key in 12 hours, then a 112 bit key > will take (given the same resources) 2**56 * 12 hours, which is about > 864,691,128,455,135,232 hours which works out to > 98,709,032,928,668 years, > which is about 4,000 times the current estimated age of the universe. > > This analysis of course assumes that the EFF crack is a brute-force, > and not a result of differential cryptanalysis or exploitation of a > flaw in the DES S-boxes or similar. Schneier's 'Applied Cryptography' > lists an attack that's around 2**47 rather than 2**56, > assuming you can > get the victim to encrypt several gigabytes of text of your > choosing with > his key.... ... and then they load it on www.distributed.net

2 1

RE: telnet vs ssh on Core equipment , looking for reasons why ?
by Dave Israel 31 Jul '01

31 Jul '01

Sadly, there are two good reasons to use telnet to connect to core equipment, even in this day and age: 1) You have legacy equipment that does not support ssh, and/or your vendor does not include ssh in every release of code (specifically, code you need to run.) 2) Your vendor's ssh authentication creates a secure connection, and transfers the password securely, only to then send the password, unencrypted, to an authentication server for verification, making ssh moot. -Dave On 7/31/2001 at 11:54:38 -0400, Daniel Golding said: > > I believe that folks are having problems saying why they use SSH instead of > telnet, because the best practice is simply so self-evident. > > SSH gives you a measure of protection against bad people sniffing out your > passwords. Telnet does not. SSH is encrypted. Telnet is not. It's pretty > easy - only use telnet if you must. Use SSH if you possible can. Of course, > this also holds true for using scp instead of ftp, although scp isn't as > widely supported, yet. > > - Daniel Golding > > > -----Original Message----- > > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > > Mr. James W. Laferriere > > Sent: Tuesday, July 31, 2001 11:25 AM > > To: nanog(a)merit.edu > > Subject: Re: telnet vs ssh on Core equipment , looking for reasons why ? > > > > > > > > > > Hello All , Thank you for the disertations & insight into the > > possible methods of compromising an authentication attempt . > > > > But , I am really interested more in 'Why' each responsible > > indidvual(s) chose either telnet or ssh to manager their Core > > equipment . > > > > ssh > > 1 ) Has been the encrypted authentication . > > > > telnet > > 1 ) Has been legacy OS's / Equipment olny supporting telnet . > > > > On Tue, 31 Jul 2001, Mr. James W. Laferriere wrote: > > > Hello All , I have charged myself with trying to find a statistic > > > on how many individuals responsible for IP core equipment > > > recommend telnet or ssh & why particularly . I will summarize . > > > > Tia , JimL > > > > +------------------------------------------------------------------+ > > | James W. Laferriere | System Techniques | Give me > > VMS | > > | Network Engineer | P.O. Box 854 | Give > > me Linux | > > | babydr(a)baby-dragons.com | Coudersport PA 16915 | only > > on AXP | > > > > +------------------------------------------------------------------+ > > > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

5 4

RE: telnet vs ssh on Core equipment , looking for reasons why ?
by Grace, Terry 31 Jul '01

31 Jul '01

Actually, we do this now for our VPN users. Cisco Secure ACS 2.6 for NT proxies authentication requests to an ACE/Server 5.0 (works with 4.1 as well). Fairly stright forward to set up. I believe you can get evals of both products. Both servers have replication partners for redundancy and sit in a firewall DMZ. VPN users must log into a VPN web site using their tokens to obtain the VPN client. Gonna try this with our routers RSN. -----Original Message----- From: Mike Hoskins [mailto:mike@TELEVOKE.COM] Sent: Tuesday, July 31, 2001 4:04 PM To: Grace, Terry Subject: Re: telnet vs ssh on Core equipment , looking for reasons why ? I've been thinking of doing precisely this... Any pointers to info on something like this? I haven't researched it much yet (busy with IDS atm). Thanks, -Mike > "Grace, Terry" wrote: > > Here's an alternative that might work. Authenticate via Radius which > in turn proxies the authentication request to a SecurId server. With > one time passwords, who cares if they get sniffed? You also get the > benefit of having your Radius server being able to do > accounting/access control on the sessions as well. > > -----Original Message----- > From: Dave Israel [mailto:davei@biohazard.demon.digex.net] > Sent: Tuesday, July 31, 2001 2:43 PM > To: alex(a)yuriev.com > Cc: nanog(a)merit.edu > Subject: RE: telnet vs ssh on Core equipment , looking for reasons why > ? Get to know us http://www.thestar.com - Canada's largest daily newspaper online http://www.toronto.com - All you need to know about T.O. http://www.workopolis.com - Canada's biggest job site http://www.torontostartv.com - Webcasting & Production http://www.newinhomes.com - Ontario's Largest New Home & Condo Website http://www.waymoresports.com - Canada's most comprehensive sports site

1 0

RE: telnet vs ssh on Core equipment , looking for reasons why ?
by Dave Israel 31 Jul '01

31 Jul '01

[Yeah, I know, we've wandered off topic. But security is fun to talk about.] On 7/31/2001 at 12:41:23 -0400, alex(a)yuriev.com said: > > > > > 2) Your vendor's ssh authentication creates a secure connection, and > > transfers the password securely, only to then send the password, > > unencrypted, to an authentication server for verification, making > > ssh moot. > > Establish reasonable path for trust propagation and you have solved the > problem. Except, of course, if I had a reasonable path for trust propigation, I would have a trusted path for telnet logins. ;-) Any compromise on a clear-text telnet password is going to be viable against any other clear-text password transmission. Even restricting logins to certain host ranges only pushes security to those networks. If you're going to sniff my backbone passwords, the networks that are wrapped in are presumably compromised already. Network security is a beast. There's no sure method. Of course, the compromises get progressively more unlikely as time goes on (including keyboard sniffing and signal analysis.) So the question becomes, what is secure enough? If you're only using telnet, with clear passwords, restricted to a certain range (which, by the way, despite a recent post to nanog, we are doing; I'd like to say we left that router open so folks could read my poetry, but the truth is, we were morons and missed it) you're secure as long as your backbone links and backend aren't being sniffed. Physically tapping fiber isn't terribly easy for the average hacker, and careful routing protocol selection and implementation should keep you from external intrusion. So really, your back-end that's the most likely way in. So... does anybody know how long it takes to hack an ssh key given identity and identity.pub? Because, if I have your machine, I have these... it's just a matter of unlocking your passphrase. (And not even that, if you're running ssh-agent and I can get to that...) -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

2 2

UPDATED: Cisco Security Advisory: "Code Red" Worm - Customer Impact
by Cisco Systems Product Security Incident Response Team 31 Jul '01

31 Jul '01

-----BEGIN PGP SIGNED MESSAGE----- UPDATED: Cisco Security Advisory: "Code Red" Worm - Customer Impact The Cisco Security Advisory regarding customer impact from the "Code Red" worm has been updated with new information. It is available at "http://www.cisco.com/warp/public/707/cisco-code-red-worm-pub.shtml". The document has been updated with newer information about the worm. A side-effect that can lead to a denial of service on the Cisco CSS 11000 Content Service Switches is described. Older network management products that originally shipped with IIS are listed in case they have been reconfigured such that they are vulnerable and are still in use. The changes were not determined to be large enough to justify mailing out the entire advisory. If you are unable to view the advisory on the web, please request a text copy directly from the PSIRT team. Address any comments or questions to "psirt(a)cisco.com". All published Cisco Security Advisories are found at "http://www.cisco.com/go/psirt/". Thanks. Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. <http://www.cisco.com/warp/public/707/sec_incident_response.shtml> E-mail: <jnduncan(a)cisco.com> Phone(Direct/FAX): +1 919 392 6209 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQEVAwUBO2dNLWiN3BRdFxkbAQFVCggAmii/lpWtYOGH921/7+GcRzHwdEtzSG7G YtTwhRH23Gdgjp4YU1wgkUDa3nrcLREmKiXurpyepd7rQ8TKIYGzBAt1MXRnUKWB aO6kh6827eUNqvers/tBndSkPatALXJ2eUloaFdoEmTxkAPpLIRip5dv9fxpaLL+ u+btLGublIkL2Tv1gG6frNMw8xeHRzKuqC/O6rkLKLZCdLqph3ByqFIgkB2ffd2g +43mVcg7F4HpNdPOnXsHIs1ZG9JNSA1HWkqkwN+9coQzSVQlQtsNAMtCxGKV9FVQ YkQYdtqck67CuFF+eyqs5J21XRyV26IVjuOGbwTDSUqnvSaMmsvzzA== =BN1T -----END PGP SIGNATURE-----

1 0