[nycbug-talk] Analyzing malicious SSH login attempts

[Isaac Levy]

Hi MW, All,

On Sep 12, 2006, at 9:53 AM, michael wrote:

>
> Recently, I have been moving toward keys vs. passwords (it makes  
> logons
> fast and fun).  But I still have lingering anxiety that once you have
> my desktop, you have my local network AND my datacenter network AND
> anywhere else I've dropped a key.
>
> Maybe I should, more seriously, consider the shear hassle of skeys.

To be straight, I've used and loved SSH keys for years- so I'm biased  
here, and I feel there's a lot of over-macho info out there about  
using keys, and little compiled on the important basics.

I tend to use huge keys, and replace them often- and not muck about  
with ssh keychain and the like, its' served me very well.

Basically, I feel that ssh-agent, SSHkeychain, and a other keychain  
apps people mention, can be really overwhelming for new key users to  
deal with.  I've also found them to be 'cumbersome under pressure'  
for experienced key users, but that's a matter of taste perhaps.
Since SSH is obviously a critical part of any of my infrastructure  
*gulp*, I prefer to keep it really simple.  (Again, this is all about  
threat models and one's use contexts, right?)

----------------------------------------------------------------------
With that, I'll explain what I feel are the important basics of my  
key use (some of this obvious stuff to key users), I'm obviously  
making suggestions based on my use patterns.  For the record, I  
manage 'a fistfull' of hardware machines in datacenter and office  
enviornments, and run lots and lots of jailed systems.  My threat  
models are pretty much all based around attacks from the internet.

--
First, use big keys, period (4096 bit are fabby).

I believe many older systems have problems with anything larger than  
4096 bit keys (32 bit architecture issues in older softwares?), but  
by today's CPU standards, this isn't really so big.  Common  
discussion on key size is that it would take serious crackers,  
(people with supercomputers), 3-5 years to crack a 4096 bit key  
outright.  This is assuming network auth. capture and replay.  This  
is of course only speculation, and it can be assumed people with  
supercomputers can do much better these days.
Using 4096 bit keys work just as fast as smaller keys in practical use.

--
Lock a key with a passphrase, so you unlock them on your local  
computer when you use them.

Some admins like the fact that unlocked keys let them jump to-and-fro  
between machines without having to enter passwords, I feel this is  
silly and have seen borderline irresponsible uses of keys in this  
manner.  If you don't lock your keys, anyone can use it- and you have  
to spend an inordinate amount of time protecting them against  
overwhelming threats.
This is where ssh-agent and the other keychain apps come into play,  
because they let you authenticate your keys once locally, but again  
this opens the door to various and common local threats.  Is it  
really that cumbersome to enter a passphrase for each ssh login?
**caveat** It does get messy to manage using multiple keys without  
ssh-agent.  However, a caveat to that caveat, is that using many keys  
discourages admins from changing their keys regularly,  which I see  
as a MUCH larger threat :)

--
If you lock your private keys with a local passphrase, you can then  
happily toss them around to different trusted systems, keep them on  
your iPod, whatever you choose to trust.

The threat here is that someone would run a dictionary attack against  
your keys themselves, so you still want to be very conservative with  
where they live.  Also, one must of course trust any machine where  
they *unlock* those keys, (any machine which you ssh OUT of).

--
Your public keys, can be tossed around pretty freely, and placed on  
remote systems you simply want to log IN to.

It's a cool way to work, because between savvy admins, there's no  
need to deal with passwords when setting up shell account access.   
(These keys are ~/.ssh/id_dsa.pub or ~/.ssh/id_dsa.pub respectively)   
This is great for shell accounts on systems you don't use, or don't  
entirely trust based on it's use.  If your not going to ever ssh out  
from said machine, there's no reason for you to have your private  
keys up there, weather they're locked with a passphrase or not.

--
RSA or DSA keys?

You decide, this is really a big ongoing debate by the hardcore  
crypto folks.  RSA is far older, comes from MIT in the late 70's.   
DSA comes from the NSA in the mid 90's.  Both are believed to be a  
secure signature algorithm given 'sufficently long keys'.  I believe  
the relative age of RSA is what prompted the 'RSAAuthentication yes'  
line in sshd_config.  In the late 90's, when DSA had become equally  
common, it was assumed RSA would be (or had been) cracked.  Since  
then, it's held up quite well, and at the time of this writing RSA is  
only twice as old as DSA (15 years compared to 30 years), so hrmph-  
it's all all about calculated risk anyhow, eh? :)

--
Dissalow password auth on your servers.
On 'high-security' host machines, simply disallow password  
authentication alltogether in your sshd_config file- (and noteworthy,  
on some systems [FreeBSD 6.x onward for example] one needs to disable  
PAM auth. in the config file too, to completely disallow password  
logins).

This is critical for any online system you wish to protect, password  
auth is low lying fruit.  A practical personal experience with this  
was with the 'SSH1 CRC-32' exploit from 2001, which of course  
rendered SSH protocol V1 useless:
http://www.cert.org/incident_notes/IN-2001-12.html
So basically, my experience was that systems that disallowed password  
auth weren't low enough fruit for the ssh feeding frenzy that ensued-  
giving us plenty of time to reconfigure the systems to disallow SSHv1  
alltogether, and run around unplugging any hardwired-ssh1 in network  
appliances of the time (PDU's, etc...).


----------------------------------------------------------------------
At the end of the day an exploit is an exploit- and everything is of  
course crackable (including one's brain), but ssh keys keep your  
system from being low-lying fruit- which is practical and important  
today on the internet.

So my key philosophy is simple- change your keys often, and do  
whatever is easiest for you according to your threat and usage models.

An awesome how-to, because it's simple:
http://pkeck.myweb.uga.edu/ssh/

>
> I'm curious, do NYCBUG talk subscribers consider this a "best
> practices" article?  Is anything misleading, wrong, missing.. or  
> right?

Hope my rambling primer is useful to folks out there.


>
> I am also curious.. where do we draw the line and just *trust* our OS?

When we turn our computers off, IMHO.  :P

Best,
.ike