In view of all the brute force attacks still being attempted against Secure Shell (SSH), we have long since been extolling the virtues of forgoing passwords and moving to RSA/DSA keys instead. While key based login indeed nicely addresses the problem of password guessing attacks, it looks like many a Unix admin has been less than diligent in the implementation. In pretty much every Unix security audit recently, we've come across unprotected or badly protected SSH private keys (id_dsa, id_rsa). Some reside plain flat out in the open, in /tmp and such. Others are found in world-readable tar "backup" archives of user and administrator home directories. Some are even built into home-grown Linux RPM and Solaris PKG packages, ready to be plucked off an install server. It probably goes without saying, but let's repeat it nonetheless:
In a Unix penetration test within a company or academic institution network, we often first go looking for files and directories that can be read without authentication. Most large organizations have an "install server" from where they stage their new Unix systems, and often we find these install servers to openly share the package filesystem over NFS for"everyone". Other good choices are home directories, all too often also exported via NFS to "everyone". Once read access is established, we can go hunting: $find /mnt/some_exported_fs \( -name "id_dsa" -o -name "id_rsa" \) -exec ls -ald \{\} \; ...etc. Adapt as needed for your environment. To better protect your privates, please consider to
#find / \( -name "id_dsa" -o -name "id_rsa" \) -exec egrep -L "Proc-Type" \{\} \; 2>/dev/null Newer DSA/RSA Keys contain the string "Proc-Type" as part of the key file when a password is set on the key. The above command lists all those key files where this isn't the case ("egrep -L") If you got additional tips on how to protect SSH private keys on Unix, or how to best locate misplaced / unprotected private keys, please let us know.
|
Daniel 385 Posts ISC Handler Aug 11th 2010 |
Thread locked Subscribe |
Aug 11th 2010 1 decade ago |
Whenever I read phrases like "the virtues of forgoing passwords and moving to RSA/DSA keys instead." I feel compelled to point out that while this is good for internal access to remote systems, if you're using using SSH to allow external access to your network, keys are, in my view, potentially a bad idea.
Once a private key you created has left your network, its owner can easily reset the passphrase to null and leave lying about on every computer they use and there's nothing you can do to stop or track this beyond telling the user not to do it. And as I don't trust users that much, I find passwords, where I can enforced changes, complexity and existence much more secure. |
Steven 3 Posts |
Quote |
Aug 11th 2010 1 decade ago |
Its good to add:
umask 0077 to Your login scripts |
Steven 1 Posts |
Quote |
Aug 11th 2010 1 decade ago |
Further restricting how these key can be used on your client systems is also wise. The authorized_keys file has may options that can be useful (e.g. no-pty, no-X11-forwarding, from="pattern-list" and the especially useful command="command") which are listed in the sshd man page.
|
Tcone 1 Posts |
Quote |
Aug 11th 2010 1 decade ago |
I strongly believe that you should NOT make any login available to an untrusted IP in the first place. If you cannot get to the door you cannot get into the server(s) through it.
Lock down your SSH and any other remote access to trusted IPs only. This applies to inside nets as well. Keep an admin network range on a separate VLAN for administration of servers, routers, firewalls and switches. Those without a trusted IP don't get in. I always use the KISS method. It just works! -Al |
Al of Your Data Center 80 Posts |
Quote |
Aug 11th 2010 1 decade ago |
Al is right. In addition to using keys, you should restrict the locations for users where possible. Using "AllowUsers <user>@<ip>" you can limit access on an individual basis. There's also AllowGroups. man sshd_config for more options.
|
Frank 24 Posts |
Quote |
Aug 11th 2010 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!