SSH and Telnet [was Re: [Ma-linux] Two Sun Announcements]
mstone at mathom.us
Tue Feb 13 21:13:26 EST 2007
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"
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:
I don't see any data to support the claim.
"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.
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
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
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
>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. :-)
More information about the Ma-linux