I liked this quote,

About 43% of respondents said they're using the Secure Shell (SSH) protocol to protect data, secure remote access, and perform network management. But while the current SSH2 is considered to be significantly more secure, nearly 45% said they are continuing to mostly use the older SSH1 protocol. A cause for greater concern, according to the surveyors, is that 54.9% said they continue to configure their network devices via Telnet, which is known by network security experts to be severely vulnerable to intruders because it sends data as clear text and offers only weak password authentication.

The part about Telnet is truly scary... Among people who have "clue", the biggest reason I have heard to continue running ssh1 is for emergency access via hand-held smartphones or other pocket sized devices. The Handspring Treo 180 and similar keyboarded cellphone-pda devices don't have the CPU power necessary for a SSH2 key exchange, unless I'm drastically mistaken about the FPU abilities of a 33 MHz Motorola Dragonball...

JS> Date: Thu, 3 Jun 2004 14:26:01 -0700 JS> From: Jeff Shultz JS> I wonder if they asked the people using Telnet if they were JS> using over the internet - or inside a corporate intranet, JS> shielded from the outside? Good to know that malicious things are always on the other side of the router. I must be hallucinating when I encounter pwned boxes with sniffers running inside of a network. Everyone restricts MAC addresses at their switches. Nobody is vulnerable to cable taps, wireless sniffing, ICMP redirects, or any other trickery. Sarcasm aside, I don't think being shielded from the outside makes that much difference. It's foolish to assume that a corporate intranet is squeaky clean. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.

On Thu, 03 Jun 2004 13:16:44 PDT, Eric Kuhnke <eric@fnordsystems.com> said:

...

The part about Telnet is truly scary... Among people who have "clue", the biggest reason I have heard to continue running ssh1 is for emergency access via hand-held smartphones or other pocket sized devices. The Handspring Treo 180 and similar keyboarded cellphone-pda devices don't have the CPU power necessary for a SSH2 key exchange, unless I'm drastically mistaken about the FPU abilities of a 33 MHz Motorola Dragonball...

Cisco 26xx, 36xx routers at least, current 12.3 IOS, no ssh support in the basic loads that I can find. Telnet is the only way in other than the console port.

DS> Date: Thu, 03 Jun 2004 17:56:55 -0400 DS> From: Daniel Senie DS> Cisco 26xx, 36xx routers at least, current 12.3 IOS, no ssh DS> support in the basic loads that I can find. Telnet is the DS> only way in other than the console port. Correct. One must shell out more money for a bigger feature set to obtain SSH. I don't recall specifics off the top of my head, and don't have a javascript-cable machine handy to use Feature Navigator[*], but certain { feature sets | trains } only support SSHv1. [*] Quick gripe: Did anyone at Cisco ever consider that people might like to use Feature Navigator without javascript? What's next? Mandatory Flash Player? Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.

## On 2004-06-07 10:29 -0400 Daniel Corbe typed: DC> DC> DC> You have to have an IOS image with the 3DES feature set to run ssh Not quite: single DES will do fine (if you use an SSH client that supports it) -- Rafi DC> DC> Edward B. Dreger wrote: DC> DC> >DS> Date: Thu, 03 Jun 2004 17:56:55 -0400 DC> >DS> From: Daniel Senie DC> > DC> > DC> >DS> Cisco 26xx, 36xx routers at least, current 12.3 IOS, no ssh DC> >DS> support in the basic loads that I can find. Telnet is the DC> >DS> only way in other than the console port. True for(at least) 72XX and 75XX as well SSH support is definitely in "IP IPSEC" (or or SP/SSH ;-) feature sets DC> > DC> >Correct. One must shell out more money for a bigger feature set DC> >to obtain SSH. I don't recall specifics off the top of my head, DC> >and don't have a javascript-cable machine handy to use Feature DC> >Navigator[*], but certain { feature sets | trains } only support DC> >SSHv1. DC> > DC> >[*] Quick gripe: Did anyone at Cisco ever consider that people DC> > might like to use Feature Navigator without javascript? DC> > What's next? Mandatory Flash Player? DC> > DC> > DC> >Eddy

I've heard there's an SSH2 client for the Treo. Ah, here it is: http://sealiesoftware.com/pssh/

The Danger Sidekick can do SSH2 with "Terminal Monkey" which was free up until recently. :) It's fun, but kind of hard to get any real work done with the tiny screen.

I've been reasonably pleased with using the Idokorro client. It's at http://www.idokorro.com It uses SSH2 w/3DES & AES. It's useful for emergencies, but nothing of great detail or scope for the screen size on my 6820. -John

I like my Tungsten C, but I don't do security-stupid things with it. :) Another neat trick, for those who haven't seen - Intel has maps.yahoo.com setup so it'll show you where alot of the hotspots are - here's a map of downtown SF as an example: http://tinyurl.com/36s5y John On Thu, Jun 03, 2004 at 10:13:24PM -0700, Jonathan Nichols wrote:

Wow. $195 for the Blackberry client? I'll carry around the PowerBook and get a T-Mobile account, thanks! :) It's a lot easier to find a Starbucks in San Francisco than anything else. Just spin around a few times and you'll find one.

I received adv., in russian, saying: ======================================== Dear sirs. We are glad to you to give qualitative service, on elimination of sites. We can kill any site by our attack, which have name 'DDos attack'. We have already killed hundreds Russian and foreign sites. If you have enemies, and It is necessary to get rid of them, ask us and we will help with pleasure. The prices at us low, 60 dollars for 6 hours. 150 dollars day. Destroy any project on the Internet with the help of ours DDos service. Payment prinimaetsja in sisteme WebMoney. Contacts: ICQ 783603. ========================================= (I'll send original text separately). Not 'we kill your enemy - $1000 for simple murdering, $10000 for hidden one, when deadth looks natural' yet, but I am impressed...

Paul Jakma wrote:

What's really scary is that the people here complaining about a certain vendor charging extra for SSH and hence forcing them to use "insecure" telnet havnt the cop-on to read that vendor's "AAA" documentation and realise that the base feature set _already_ includes capability to do secure authentication.

And that provides protection against MITM attacks how?

* Paul Jakma <paul@clubi.ie> [2004-06-06 09:03]:

On Sat, 5 Jun 2004, Mike Lewinski wrote:

...

And that provides protection against MITM attacks how? kerberised telnet can be encrypted (typically DES - sufficient to guard MITM).

this is not nearly the same league as (proper) ssh. complaining that cisco charges extra for such a critical component is exactly the right thing to do; it is fucking scary. every damn network device which used to have telnet should ship with ssh, it's free. well, I understand that cisco has problems with their 3$ CPUs with the crypto load, bit that's an extremely poor excuse.

complaining that cisco charges extra for such a critical component is exactly the right thing to do; it is fucking scary.

every damn network device which used to have telnet should ship with ssh, it's free.

Why? The typical network architecture of an ISP sees routers located in large clusters in a PoP or on a customer's site directly connected to a PoP. Since it is dead simple to place a 1U Linux box or similar SPARC server in a PoP to act as a secure gateway, why should router vendors encourage laziness and sloppiness? IMHO routers should not have SSH at all and should not accept any packets directed to them unless they are coming from a small set of known addresses on the network operator's management network. Once you open the router to SSH from arbitrary locations on the Internet you also open the router to DDoS from arbitrary locations and to attacks from people with inside info (SSH keys stolen or otherwise). It makes more sense to funnel everything through secure gateways and then use SSH as a second level of security to allow staff to connect to the secure gateways from the Internet. Of course these secure gateways are more than just security proxies; they can also contain diagnostic tools, auditing functions, scripting capability, etc. Now there is nothing fundamentally wrong with ADDING to that type of architecture by enabling SSH between the routers and the security gateways. But I believe that it is fundamentally wrong to consider SSH on the router to be equivalent to opening the router to any staff member, anytime, anywhere on the Internet. There are still possible man in the middle attacks that cannot be protected against by SSH. Consider the case of a staff member lounging in the backyard on a lazy Saturday afternoon with their iBook. They have an 802.11 wireless LAN at home so they telnet to their Linux box in the kitchen and run SSH to the router. Ooops! The only way to protect against that sort of situation is to encourage everyone to be security-minded and not take risks where the network is concerned. Funneling all access to routers through a secure gateway is part of that security-mindedness and is just plain good practice. --Michael Dillon

That was well spoken and certainly the smartest move that I have in this entire conversation, thanks. -Henry --- Michael.Dillon@radianz.com wrote:

...

complaining that cisco charges extra for such a critical component is exactly the right thing to do; it is fucking scary.

every damn network device which used to have telnet should ship with ssh, it's free.

Why?

The typical network architecture of an ISP sees routers located in large clusters in a PoP or on a customer's site directly connected to a PoP. Since it is dead simple to place a 1U Linux box or similar SPARC server in a PoP to act as a secure gateway, why should router vendors encourage laziness and sloppiness? IMHO routers should not have SSH at all and should not accept any packets directed to them unless they are coming from a small set of known addresses on the network operator's management network.

Once you open the router to SSH from arbitrary locations on the Internet you also open the router to DDoS from arbitrary locations and to attacks from people with inside info (SSH keys stolen or otherwise).

It makes more sense to funnel everything through secure gateways and then use SSH as a second level of security to allow staff to connect to the secure gateways from the Internet. Of course these secure gateways are more than just security proxies; they can also contain diagnostic tools, auditing functions, scripting capability, etc.

Now there is nothing fundamentally wrong with ADDING to that type of architecture by enabling SSH between the routers and the security gateways. But I believe that it is fundamentally wrong to consider SSH on the router to be equivalent to opening the router to any staff member, anytime, anywhere on the Internet. There are still possible man in the middle attacks that cannot be protected against by SSH. Consider the case of a staff member lounging in the backyard on a lazy Saturday afternoon with their iBook. They have an 802.11 wireless LAN at home so they telnet to their Linux box in the kitchen and run SSH to the router. Ooops!

The only way to protect against that sort of situation is to encourage everyone to be security-minded and not take risks where the network is concerned. Funneling all access to routers through a secure gateway is part of that security-mindedness and is just plain good practice.

--Michael Dillon

[use telnet+ACL instead of SSH]

while this protects the router such that it allows packets in only from known addresses, it does not allow packets in only from known MACHINES. Addresses can be spoofed. Vendor C (at least in recent history) did/does not allow binding of the host stack only to specific interfaces. Thus it is (if you are determined) not impossible to spoof a telnet session especially if the first thing you do is inject a return route. This is why we were all good chaps and secured our BGP sessions, remember? Of course SSH should ALSO be secured so it only comes from known source addresses, mainly for administrative reasons (I'd like to know just WHICH NOC member of staff logged in from where and when).

There are still possible man in the middle attacks that cannot be protected against by SSH. Consider the case of a staff member lounging in the backyard on a lazy Saturday afternoon with their iBook. They have an 802.11 wireless LAN at home so they telnet to their Linux box in the kitchen and run SSH to the router. Ooops!

Umm, I get seriously worried when people suggest they allow people with router access to telnet from box A to box B, then SSH to a router. Firstly, they should be logging into a secure set of machines first in all sensible security models I've seen (even if an ACL doesn't force them to do that, they should do it as good practice). Before you say "that requires them to have connectivity to those machines in the case of network meltdown", in all sensible authentication schemes the router is going to challenge some remote box(es) anyway, and you can provide multiple such boxes - anything beyond that is failover. But the major point is: what kind of people do you (a) give enable access on your router, and (b) do not appreciate that telnet, then ssh, is a seriously bad idea in terms of security (and can't instead install ssh on whatever box it is). Are engineers really that dumb these days? Doing that sort of thing was a disciplinary offence last time I ran a large network - not something to try and work around with security policy. Note we even had this degree of protection (no passwords in the clear over wires not controlled by us) when IOS did not even have an ssh build. Alex

...

Consider the case of a staff member lounging in the backyard on a lazy Saturday afternoon with their iBook. They have an 802.11 wireless LAN at home so they telnet to their Linux box in the kitchen and run SSH to the router. Ooops!

I see. SSH doesn't solve all problems, and therefore must be worthless.

No. SSH doesn't solve all problems because it is only a protocol. The human element is the most important one to consider in network security.

Now let's look at kerberized telnet. Someone logs in via kerberized telnet over an insecure network, then decides to change his/her password. Oops.

Exactly! Technology is worthless if it is not used properly. Network engineers are technology experts not security experts. They often need training to raise their awareness of security issues. Remember the study a while back that found that the largest single factor that caused network failures was human error?

...

The only way to protect against that sort of situation is to encourage everyone to be security-minded and not take risks where the network is concerned.

Definitely. Alas, I'm seeing more "it won't happen to me" than in the past. It's almost as if the "logic" is "I hear more about this, but haven't noticed anything awful, and therefore must be invincible."

The question in that case is: "Do you know, in enough detail, what is going on in your network that you can confidently say that nothing awful is happening?". --Michael Dillon

Once you open the router to SSH from arbitrary locations on the Internet

i don't think anyone (sane) was suggesting that. but my competitors are encouraged to do so.

It makes more sense to funnel everything through secure gateways and then use SSH as a second level of security to allow staff to connect to the secure gateways from the Internet. Of course these secure gateways are more than just security proxies; they can also contain diagnostic tools, auditing functions, scripting capability, etc.

and all the other things single points of failure need. like pixie dust, chicken entrails, ... randy

...

and all the other things single points of failure need. like pixie dust, chicken entrails, ... Where did the word "single" come from, given he had an "s" on gateways? Replicate them across POPs

glib, but ignores the massive cost and bureaucratic insanity it takes to install yet one more box in a real pop. we already go through that for the out-of-band and serial console management device(s). we have in-band access; so one uses the in-band for ssh to devices; with acls, of course. telnet stopped being an option before most of the readers of nanog ever met a router. randy

--On 07 June 2004 17:50 -0400 Valdis.Kletnieks@vt.edu wrote:

Well, either you have one per POP (and that, as Randy Bush points out, can be quite the headache in itself), which is still a single point of failure for that POP, or you're advocating that the routers be reachable from the magic box at *any* POP (which is right back into the "large number of machines" issue....)

Well the way we did it, all routers were accessible from 2 (large) POPs, two being in the NOC, and one being elsewhere (now you mention it, it was a datacenter & POP combined). So the "large" number of machines was 3. I am sure we could have scaled this to (say) 4 without substantial difficulty. I agree one in every POP would be both painful and pointless. But that wasn't what I meant. Alex

At 12:50 AM 6/6/2004, Paul Jakma wrote:

On Sat, 5 Jun 2004, Mike Lewinski wrote:

...

And that provides protection against MITM attacks how?

kerberised telnet can be encrypted (typically DES - sufficient to guard MITM).

Am I the only one who really likes devices to handle their own login authentication? I've had more than one occasion to need to get into and manage a device when the link between the device any anything resembling an authentication server is toast, and the reason I'm bothering to talk to the device in the first place? Yes, terminal servers can be an answer. But SSH can be a perfectly good path in across whatever link(s) are still functional. Even an inexpensive managed layer 2 switch I installed recently for a client had decent ssh support (yes, it supported other methods of authentication too, including the use of server-based authentication).

Thus spake "Priscilla Oppenheimer" <po@priscilla.com>

It's egregious that SSH isn't standard in all IOS images, especially when you consider that choosing the right image is almost an NP-complete problem even with feature navigator! :-)

There are plenty of folks at Vendor C that would love crypto in every image, but that would run afoul of export regulations; the BXA has lightened up, particularly for open source projects, but it's still not trivial to export commercial crypto. Vendor C's anemic flash and RAM limitations in various platforms also restricts what's possible to put in a default image. The code continues to bloat, so it's only going to get worse. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin

At 07:14 PM 6/6/2004, you wrote:

On the SSH/SSL front: IMHO these technologies give a false sense of security. Sniffing cleartext management sessions is a concern, yes, but actual incidents where it occurs, especially within your own network infrastructure, are vanishingly rare compared to the commonplace compromise of individual hosts. Creating a secure link between hosts is wasted effort at best if you can't trust the host at the other end of that link.

Agreed. I really truly don't see the problem with plaintext telnet management of routers. We have access-lists on vty 0 15 specifying which networks can even connect. We can't connect except for from a trusted internal management network and I control all the routers and circuits in the path. If someone is in the middle of one of my circuits doing some type of dump of the data to disk, they are probably the NSA or CIA, and I've got much bigger problems. Can someone please provide a situation where doing this can lead to compromise or any type of problem at all? I just don't see it. However, I see people having unpatched servers running without proper ACLs every day and this is rarely discussed and as Stephen Sprunk points out, lot of people here on nanog don't apply bogon filters or even source filter their customers - and this doesn't require a feature set upgrade to IOS. (All of which we do, btw) So I'm still not convinced that SSL on routers is needed. Nice, sure, but needed? no. Please convince me otherwise if you feel this is such a hugely pressing need or at least explain your position. R Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

At 12:11 PM 6/7/2004, you wrote:

ever heard of multilayer security?

Absolutely and I am a huge believer in it and all of our systems and our network is designed with many layers of protection... which is why I am against running ssh AND leaving it open to the world since that leaves only a single layer of security. My point is simply that having SSH is a good tool, but I still don't think that having SSH relieves any of the other responsibility for proper network security.

some little problem somewhere that allows an attacker to sniff your telnet traffic and you are d00med. that might be as simple as a routing fuckup.

That would have to be a pretty major screwup.

You loose nothing with using ssh instead of telnet. You win a lot.

I agree 100%. However, is that worth $x thousand more per IOS image? Maybe. Should it be included by default, yes.

ssh is a basic component for secure network management. it is not the one magic piece that turns a collection of crap into an ubersecure network of course, as some people seem to imply.

Exactly and that is my point. Especially when leaving SSH open to the world on all routers because it is "secure" is LESS secure than having secure passwords and ACLs and using telnet from the local LAN only. In an ideal world, you would have an ACL, a secure password, AND SSL.

not seeing the problem with cleartext telnet for remote logins in 2004, wether ACL'd or not, is just ... oh man, I don't have words for this.

I see the theoretical problem with telnet, but in the real world, I think there are many other more basic security practices which should be focused on perhaps even before worrying about ssh for routers. How many people have a dictionary word as their password for SSH? How many times have you purchased a used router which was used by (insert big ISP here) and found the password to be a simple dictionary word - on multiple routers purchased from multiple ISPs. My only point is that there are many other things to worry about for building comprehensive security as part of a network than simply enabling a protocol for remote management. That should be one of MANY issues which should constantly be addressed. R Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

Thus spake "Henning Brauer" <hb-nanog@bsws.de>

* Robert Boyle <robert@tellurian.com> [2004-06-07 14:08]:

...

I really truly don't see the problem with plaintext telnet management of routers.

It is exactly this belief in the security of your networks that gets this industry in so deep shit.

Mostly agreed.

You loose nothing with using ssh instead of telnet. You win a lot.

You lose money and time because you have to license more expensive code, upgrade RAM and flash to handle larger images, have to train your staff how to use SSH, have to test and roll out changes enabling SSH and disabling telnet, have to deal with sub-300-baud interactive performance on older router models, etc. In spite of all that, I do encourage using SSH whenever possible, but believing there is no cost associated with doing so is foolhardy. Depending on the perceived level of threat, one might consider other security projects to be a higher priority. We all have to deal with limited funding and staffing for projects, even for critical functions like security. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin

* Stephen Sprunk <stephen@sprunk.org> [2004-06-08 13:05]:

Thus spake "Henning Brauer" <hb-nanog@bsws.de>

...

You loose nothing with using ssh instead of telnet. You win a lot. You lose money and time because you have to license more expensive code, upgrade RAM and flash to handle larger images

this, again, is an exclusive cisco problem. blame them. -- Henning Brauer, BS Web Services, http://bsws.de hb@bsws.de - henning@openbsd.org Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)