Archive for May, 2008

LCOD – 5.17.08 – Locking down ssh access

In light of an increase in ssh attacks , vulnerabilities and scans I am writing this guide to help you keep unwanted people from connecting to your server via SSH.

If you have generated any of your SSH keys on a Debian or Ubuntu system they are likely very vulnerable to guessing, e.g. someone could login to your box if they know the name of one of your users that you allow in via ssh within 30 minutes!
See here for more info: http://metasploit.com/users/hdm/tools/debian-openssl/

This applies to any PAM enabled Linux (or other PAM-enabled *nix like OS)

This guide will walk you through configuring your OpenSSH server to only allow public key authentication and limit that to specific users and groups. Errors in this guide or mistakes or differences in system configurations could lock you out of your own systems, be very careful and do not proceed unless you understand and assume the risk you are taking.

I assume no responsibility for YOUR actions. This guide was tested on Ubuntu 7.10 and fairly recent Gentoo system.

1. Limit SSH access to public/private keys only, deny X11 and TCP forwarding, and deny root ssh access
Step 1 Discussion:
Public/Private keys are not necessarily more secure than passwords, but it’s harder to guess a private key, and if your users put passwords on their keys then an attacker must have or guess 2 things, the key and its password.

The root user is GOD on almost every Linux/*nix system out there, and nobody should be able to login directly as root remotely. In addition it’s a very common user, on almost every Linux/*nix system.

TCP and X11 forwarding is one of the coolest features of an ssh server. Unless you want people to be able to use your ssh server like a full access vpn to your local network, or any other network (bounce their attacks through your server), then you want this disabled. And X11 forwarding is great, but I never run an X11 server on something that is a “production” environment. If something requires an X11 server, like Oracle, then I run vncserver and allow ssh port forwarding so people can connect via ssh. I make sure to have full deny by default firewalls on all machines like this, limiting outbound access.

Step 1 HOWTO
Edit /etc/ssh/sshd_config
Make sure the following lines are not commented out, and don’t say something different

Protocol 2
PermitRootLogin no
UsePAM yes
PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AllowTcpForwarding no
X11Forwarding no

2. Create an ssh remote users group and add users to it who need remote ssh access
Step 2 Discussion:
The main reason I want to limit who has remote ssh access is because there are frequently system accounts or other automatically created accounts that I don’t want to have to monitor to make sure the installer didn’t just make a new user with a simple password or key. I want to have the default be nobody can ssh, and then I’ll add ssh permissions to users who need it.

Step 2 HOWTO:
Let’s call our remote ssh users list rsshusers, we create it with the command
groupadd rsshusers
Now let’s say we have a user named mikey already setup, let’s add him to our new rsshusers group, with the command
usermod -a -G rsshusers mikey
Do this for every user you want to have ssh in remotely. Note that if you’re used to logging in remotely as root and are going to stop doing that, make sure you user can su to root with the command su.
Login as the user, run
su
Put in your root password, if it accepts it and you are root (run whoami to verify) then you’re good to go. If it fails to let you su and you’re sure you have the password right you may need to be in the wheel group to us (default on FreeBSD and Gentoo).
Back as root run the following command to add your user (again, mikey in this example) to your wheel group.
usermod -a -G wheel mikey

Now we’re going to edit 2 files to limit remote ssh users to the group we made called rsshusers.
First, edit /etc/pam.d/sshd (this was ssh on my Debian/Ubuntu systems)
Add the line
account required pam_access.so

This enables access accounting based on the /etc/security/access.conf file, which is the next one we are going to edit.
On both my Gentoo and Debian system this file had every line commented out.
At the end I added the following lines.

-:ALL EXCEPT root mikey:LOCAL
+ : (rsshusers) : ALL
- : ALL : ALL

Initially I tried to use a group like @rsshusers, however this didn’t seem to work, but () designates explicitly a group.

Restart sshd
Gentoo:
/etc/init.d/sshd restart
Debian/Ubuntu:
/etc/init.d/ssh restart

Now, without closing your root terminal, open a new one and make sure you can ssh in as mikey, and su to root.

Assuming everything went well you could try ssh’ing in as another user whose public key is correctly in place, but who isn’t in the rsshusers group.

Related links:

PAM:

http://devmanual.gentoo.org/tasks-reference/pam/index.html

http://linuxdocs.org/HOWTOs/User-Authentication-HOWTO/x101.html

http://tldp.org/HOWTO/User-Authentication-HOWTO/

http://www.faqs.org/docs/Linux-HOWTO/Secure-Programs-HOWTO.html

OpenSSH:

http://www.openssh.com/

http://thinkhole.org/wp/2006/10/30/five-steps-to-a-more-secure-ssh/

http://www.cyberciti.biz/tips/rhel-centos-linux-install-configure-rssh-shell.html

http://geekzine.org/2007/09/28/easy-sftp-and-chroot-sftp-with-scponly/

Misc:
Securing RedHat

http://help.unc.edu/?id=1859

Debian SSLkeys

http://wiki.debian.org/SSLkeys

Links in post:

http://www.securityfocus.com/news/11518

http://metasploit.com/users/hdm/tools/debian-openssl/

, , , ,

No Comments

Easy AdSense by Unreal