[Triumf-linux-managers] FYI, SSH dictionary attacks ramping up

[Konstantin Olchanski]

On Tue, Dec 08, 2009 at 05:44:52PM -0800, Andrew Daviel wrote:
>
> >If users use non-passworded ssh keys to get into root,
> >root security is reduced to the security of the user account (read: none).
> 
> SSH passphrases are more resistant ...


Andrew, you missed my point. ***what ssh passphrases***?

How do I enforce that only ssh keys that have passphrases can be used
for root access? I can tell my users to never use keys that have
no passphrases, and maybe they do maybe they do not. I cannot tell,
I cannot check, I cannot enforce, it becomes an honor system.

Also, why do you say that ssh passphrases are "more resistant" than
normal passwords? Is there some data published on this? I would expect
users who use password "123", to also use ssh passphrase "123". Easy
victim to dictionary attacks.


> ... steal the private key, too ...


And what's hard about stealing private keys? Are those well protected
somehow? They travel in clear-text over the network all the time. They
can be taken from stolen backup tapes and from discarded hard drives.
Maybe yours and mine private keys are pretty safe, but those are not
the keys "they" would target for an attack.

So the attack is to steal private keys *first*, then guess the passphrases,
(if there are any), and you are root.

Or break into the user account via a firefox vulnerability, guess the passphrase
and you are root.


> ... but also because an attacker needs to steal the private 
> key, too). Anything totally reliant on a human typing characters on a 
> keyboard is at risk to keyloggers - not so uncommon in Windows malware - 
> or other surveillance such as cameras or audio analysis.


No need for private key. The "internet cafe" attack works with ssh keys
the same as with plane-jane passwords. The "internet cafe" keylogger
will see my password getting into my user account, then they see
me type the ssh passphrase, then they replay the session and they are root.

One solution to this is one-time-passwords, which also solves
the dictionary-attack problem.


> ... setting up a trust relationship between a weakly 
> protected machine and a strongly protected machine is dangerous ...


This is the normal situation - you always login from a less secure
machine to a more secure machine. If you always come for a trusted
machine, you do not need passwords at all.


> Disabling root SSH login entirely (keys, too) and forcing users to login 
> as themselves then use "su" would get the audit benefit, though still 
> exposing some risk to keyloggers.


In this scheme, how do we revive the machine if we cannot login as normal
user? Say the .login file prevents login? Home directory is over quota, etc?
Before you say, "login as root form console", what if the machine
is in Japan? What if root login from console is disabled - some Linuxes
do this? What if there is no console?


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada