SSH and Telnet [was Re: [Ma-linux] Two Sun Announcements]

[Michael Stone]

On Tue, Feb 13, 2007 at 07:49:05PM -0500, jason wrote:
>If the attacker grabs the key, yes.  It depends on their level of 
>sophistication.  A lot of the script kiddie scripts I've seen do little 
>more than run grep on the incoming stream looking for the strings "login" 
>and "password".  

I've seen kiddies that go after keys. 

>>>SSH will help dramatically if your switch gets compromised.  The majority 
>>>of cracking comes from inside.
>>
>>And 80% of statistics are made up on the spot. That's a good example of a 
>>statistic that's been passed around as true without any critical review. 
>>If you research its origins you'll find that it has to do with numbers 
>>reported to the fbi (therefore inherently self-selected) more than a 
>>decade ago (essentially pre-internet). Again, be cautious of security 
>>based on "everyone says so".
>
>No critical review?  "based on everyone says so"?  Try again:
>
>http://news.zdnet.com/2100-1009_22-5520016.html

I don't see any data to support the claim.

>http://urlkick.com/1e5b

"o More than three-quarters (78 percent) of financial institutions 
reported a security breach from outside the organization in the past 
year, up from 26 percent in 2005; almost half (49 percent) experienced 
at least one internal breach, up from 35 percent in 2005.
o More than one quarter (26 percent) of life sciences & health care 
companies experienced a breach of their security systems within the past 
year (17 percent external breaches and 9 percent internal breaches).
o More than half of TMT companies had a breach in the past year; about 
half of these were internal."

Those numbers contradict the claim that most breaches are internal.

>http://www.eweek.com/article2/0,1895,1941428,00.asp

This one is basically saying that user's can't effectively manage their 
security--just what I said. (The article blames the employees for not 
following policy, I blame the technology for leading to incomprehensible 
policies, and both of us think the employee actions lead to breaches by 
external parties.)

>http://urlkick.com/1e5c

I didn't see anything relevant there, did I miss it?

>And that's just with 15 seconds on Google.

Thank you for saving me the trouble. :)

>Most attacks *do* come from 
>inside: employees are more trusted than outsiders, security is weaker and 
>most importantly insiders tend to have much better knowledge of the 
>systems they're attacking.  There are myriad other reasons, but those are 
>the biggest.

My first response is that nobody really knows, because the state of the 
technology is such that most compromises probably aren't discovered. My 
second response is that such a position completely disregards the 
malware an botnet trends of the past five years. I'm *way* more worried 
about a secretary opening a word attachment from a client these days 
than about the secretary having malicious intent.

>I was mainly being flip, 

I know, which is why I responded as I did. :)

>but let me rephrase: what complexity does it add 
>for day-to-day operations?  Yes, it's something additional for the 
>sysadmin to understand, but a really good sysadmin will do that anyway. 
>As part of a nutritious breakfast, er, good security profile SSH is one 
>more tool to use.

My first response is that sysadmins of the caliber to understand the ins 
and outs of all the protocols they're using are getting thinner on the 
ground as the industry changes. My second response is that the *users* 
need to understand it also, in order to be sensitive to the indicators 
that they may be facilitating an intrusion. Remember, the encrypted 
channel pushes all of the security responsibility to the 
endpoints--historically, the part of the system with the weakest 
security--and severely restricts the ability for centralized/independent 
monitoring or control; at the client endpoint the user is generally the 
biggest part of the security equation--do you want to suggest that *all 
the users* of ssh generally understand everything that it can do, how it 
can be abused, what things might suggest a security problem, etc.?  
(Rhetorical, I know you already acknowledged the user problem.)

>>>You say SSH makes it harder to monitor what's going on?  Well, if SSH 
>>>adds so little to security it should be easy enough to get around, right? 
>>>If it's hard for you, the legitimate admin, to get around it'll make it 
>>>harder for the black-hat too.
>>
>>That's simply a facile assertion; you're raising a straw-man argument about
>
>No, that's really not what I did.  Re-read my original response.

"if SSH adds so little to security it should be easy enough to get 
around" The straw man is the argument that ssh security is "easy to get 
around". I didn't say that. For the purpose of network monitoring, the 
complication is the encryption--could anything I said be interpreted as 
saying that ssh has weak encryption? If you meant "easy to get around" 
in a different context, like potential coding errors caused by protocol 
vulnerabilities, it should be obvious why that's tilted toward the bad 
guys rather than the admins (the bad guy only has to exploit *one* 
error, the defender has to be perfect). And if you meant "easy to get 
around" by compromising the clients, well, a lot of places frown on 
their admins hacking business partners and employee home systems and 
such. :-)

>Tunneling can open up all kinds of security holes - so turn it off. 

That's the thing--you can't turn off the general problem of a bad guy 
taking over control of the channel assuming a compromised client. That's 
right in the ssh rfc (the assumption that the end points are secure).

>Funny, you claim I dismissed what you wrote "out of hand" and then you 
>turn around (as Joe pointed out) with ad hominem attacks 

Where? You admitted to being flip and I responded in the same tone. I 
used more smileys to this email, maybe that will help. :-) The closest I 
think I came was when I said "if you don't know that" in reply to you 
saying "what complexity does ssh add". I assumed that you didn't really 
think that ssh was no more complex than telnet and were being 
hyperbolic, so I responded in kind.

>And you conveniently deleted the part of my post where you and I are 
>saying the exact same thing:  

I call it "eliminating redundancy". Very few interesting discussions 
revolve around the points on which you *agree*, no?

>Or, better yet, show me an example of the "ssh monoculture" on this list.

The ssh monoculture refers to the proportion of unix systems that are 
running a single implementation (openssh) of the ssh protocol, or the 
ssh protocol for remote access generally. If I asked for a show of hands 
of folks using an ssh *other than* openssh there'd probably be a couple 
of people whose boss made them use the commercial version, maybe someone 
who tried lsh, and that's probably about it. 

>Like I said layers and no security scheme is complete without user 
>training and education.  

Well, as I said, I don't think it's reasonable to expect users to 
understand all the things they need to do to be secure. To large degree 
I think that the focus on user education is a cop-out--"if only the 
users did things right, we'd be fine". The reality is that there's too 
many ways for users to get caught by doing things that are reasonable to 
a rational person, and that's the fault of technology that just plain 
isn't good enough. Maybe the IT industry needs to be held to a 
"reasonable person" standard, like the insurance industry.

>i.e. don't just tell them not to write down their 
>passwords on their monitors - teach them why not.

I think it's best to tell them to put the passwords in their wallets. 
The reality is that people can't remember as many passwords as they're 
expected to, so the goal should be protecting those passwords rather 
than keeping users from doing something they're going to do anyway. 
Users do generally know how to protect their wallets. :-) I'd definitely 
be *far* happier if users write down *good, unique* passwords rather 
than rotating the same couple of passwords between all their systems. 
But that's a different discussion, for a different subject line, lest we 
annoy Joe. :-)

Mike Stone