[lug] root password

[Kevin Fenzi]

>>>>> "Rob" == Rob Nagler <nagler at bivio.biz> writes:

Rob> Sean Reifschneider writes:
>> These days, we also recommend that SSH password authentication be
>> disabled, because of the number of scans going on looking for weak
>> passwords, and the rate of escalation of those scans.

Rob> I have always wondered about this.  It seems to me that you can't
Rob> crack passwords through the sshd; it's computationally impossible
Rob> afaik.  I don't think the "standard" GNU password program will
Rob> let you use a dictionary word as a password.  Given that, the
Rob> universe of passwords is not crackable on a single machine, that
Rob> is, even if you get a distributed attack, there's still a single
Rob> machine (the computer under attack) doing the password checking.

Yeah, you are mostly correct, however anoyingly root can bypass the
"good password" checks on any of the Linux distos I have seen. This
results in people making an account called 'test' with password 'test'
for some demo and then thats one of the ones the ssh scanner uses. ;(

Rob> And, if you come under a distributed attack, I assume you might
Rob> see a high load average, and your system will issue warning
Rob> alarms.  You can also rate limit the requests per second to the
Rob> ssh port, although it's not clear this is necessary.

Yeah, I have done this one some setups. Use the iptables hashlimit
module and you can restrict per IP how many connections are allowed
per minute or the like.

Rob> A couple of important things we set in the sshd_config that isn't
Rob> set by default:

Rob>     VerifyReverseMapping yes PermitRootLogin no

Rob> This prevents a lot.  We also limit the access to the machines
Rob> which can be accessed via certain networks for all but a couple
Rob> of machines, and those "open" machines have limited data on them.

Always a good idea.

Rob> We don't use ssh keys except for automated logins, but those
Rob> logins are sandboxed with scponly, and they aren't root logins,
Rob> and they don't have any privs except to look at the files they
Rob> have already rsynced.

Also a good idea.

Rob> Keys stored on disk are therefore not more secure.  Indeed, they
Rob> are more convenient to login if you use ssh-agent (see below),
Rob> which most people do.  Even if you don't use ssh-agent, they key
Rob> can be subject to a local exploit that leads to a remote exploit.

Of course you need to make sure your machine with keys on it is
secure. Also you need to make sure and password protect all your ssh
keys that are used for non cron/priv access.

Rob> If you only use passwords, and you require the "open" ssh machine
Rob> login to have a different password than the "inside" machines,
Rob> you have higher security, because no local information on the the
Rob> "open" machine can be exploited to gain access to the "inside"
Rob> machines.

Can you expand on this? AFAIK if you login to 'open' with a ssh-key it
makes you no more vulnerable than if you logged in with a password.
If you are using authentication forwarding, then the compromiser can
use your agent to authenticate against other machines, but thats a
good reason to not use auth forwarding except on trusted machines.

>From the ssh man page:

             Agent forwarding should be enabled with caution.  Users with
             the ability to bypass file permissions on the remote host (for
             the agent’s Unix-domain socket) can access the local agent
             through the forwarded connection.  An attacker cannot obtain
             key material from the agent, however they can perform opera-
             tions on the keys that enable them to authenticate using the
             identities loaded into the agent.

Rob> And, if you tunnel your ssh sessions (LocalForward
Rob> <port> inside.my.com:22) from the outside machine to the the
Rob> inside machines, you aren't subject to sniffing on the "open"
Rob> machine even if it is cracked.

Not sure what you are saying there... anything that runs on "open" if
it's compromised can be assumed to be sniffable by the compromiser.

Rob> ssh-agent is a convenience, and therefore easily exploited.  Once
Rob> you have root access on the "open" machine, all "inside" machines
Rob> are yours with nothing to stop you.  It's the "soft, chewy
Rob> center" problem.

You should indeed only run ssh-agent on your single inside secure
machine. If the machine that has ssh-agent running on it is
compromised you are lost.

Rob> Security is very tricky, but at the root of all secure systems is
Rob> a password.  You should have a password for different classes of
Rob> access ("open", "inside", "su", imap, random website, etc.).  You
Rob> should only have a few of them so you can remember them without
Rob> writing them down, and you should change them often.

Yeah, those are often contradictory issues... ie, all systems have
diffrent password, and you should only have a few you can remember.
SSH-keys help there.

Rob> My rule of thumb is this: If you can change an access level
Rob> without a human (or crypto device) entering a new password, you
Rob> have a security hole.

ssh-agent on my laptop is my crypto device. ;)

But yeah, I agree.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20060802/8fbdeb2d/attachment.pgp>