- NANOG - lists.nanog.org

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

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

31 Jul '01

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 ? [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 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

2 1

Code Red round two
by Jeff Ogden 31 Jul '01

31 Jul '01

So what, if anything, are people planning to do differently as 8 pm EDT today and the possibility of a new round of Code Red Worm activity approaches? Are there things that we as network operators can and should be doing beyond encouraging end users to patch their vulnerable systems? -Jeff

3 3

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

31 Jul '01

> From: Stephen J. Wilcox [mailto:steve@opaltelecom.co.uk] > Sent: Tuesday, July 31, 2001 6:52 AM > so thats my main logic, authentication... i cant understand the big > paranoia on people sniffing tho! If ANY part of the link, between the NetAdm and the CORE system, even accidently, transits ANY part of an untrusted network, then that link is sniffable. Now, if you are accessing said equipment, via in-band means, this is virtually guaranteed to be the case (with a small number of anomalous exceptions). Even out-band networks are vulnerable if someone accidently leaves one host, in router-mode, and one of the NICs is on the Admin LAN. With dynamic routing, this is even less deterministic. Given a Firewall, one contractor/sales-person, with a lap-top and an 802.11b (or even Ricochet) connection to the outside world, on your inner-LAN; Your Firewall becomes a potential Maginot Line ... useless. [side-bar: A Compaq Ipaq can do this, running Linux. As PDAs get more powerful, they also become potential stealth cracker tools] Ergo, all networks are potentially sniffable. Many of them leak like sieves. You also imply another fallacy, that of only encrypting sensitive traffic. Given the above and in a stack full of needles, when you know that only the encrypted ones are interesting, you will only sniff the encrypted ones (this is the essential fallacy of SSL, it's even conveniently segregated by port number). This measurably cuts down the search time. Now if all needles were equally encrypted you add steganographic effects, to the LAN, and it becomes orders of magnitude more difficult to crack. I submit that all packets, on all networks, even SANs, should be strongly encrypted, at all times. I further submit that all hosts, even those behind a Firewall, should be hardened against attack. Never assume that you are safe.

1 0

Re: Hard data on network impact of the "Code Red" worm? (fwd)
by Larry Sheldon 31 Jul '01

31 Jul '01

> : >NTBUGTRAQ is carrying informatiion that says that is not right. > : > > : >They say that currently extant copies of the thing will sleep forever, > : >or until the host is re-booted--at which time the thing ceases to exist. > : > : There seems to be some disagreement about this point. CERT, in fact, > : notes that explicitly (http://www.cert.org/advisories/CA-2001-23.html) > : They also claim that enough infected machines have their clocks set > : wrong that there may be a new outbreak tonight (EDT) -- that one > : strikes me as less plausible. > > Less plausible in the (statistical) abstract... however as CERT also > points out (emphasis mine): > > "Our analysis estimates that starting with a *SINGLE* infected > host, the time required to infect *ALL* vulnerable IIS servers > with this worm could be less than 18 hours. " > > It only takes one. Well, some of us think it take vulnerable IIS servers too. Some of us think we listened to the wake-up call and have plugged some of the holes, learned how to detect the occurrence of un-plugged holes and so on. Some of us are wrong. > : >The hazard tomorrow is the introduction of new copies of the thing. > : > > : > : That hazard isn't specific to August 1. > > Well... maybe... but suppose July was just practice? Another worm with > the same time-pattern encoded, but with different targeting and/or > capabilities. Clever malice trumps predictability any day... Well... maybe... but suppose the sky really is falling, or that some completely unrealted vermin has been released, or that my "atheletes foot" really isn't cured. Can't deal with most of the 'sposes--not able to handle all of the "is"'s. If ordinary diligence, prudence, care, craftsmanship and skill don't do it, then the bad guys have won, and we will (probably) rethink how we use wires.

1 0