With the recent increase of break-in attempts via ssh, here's a little checklist of making sure your server is as secure as you can make it while still being able to access it from the outside.
- Do not run ssh in Protocol 1 compatibility mode. This is sadly, enabled by default in many installations, you can test yours by simply telnet-ing into it.
% telnet unix-girl.com 22
Trying 66.198.51.100...
Connected to cygnus.unix-girl.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.7.1p1
Mine's safe, unsafe configuration would show:
SSH-1.99-OpenSSH_3.7.1p1
To disable Protocol 1, set this in your sshd_config file.
- Do not allow root login via ssh at all. Root is probably the most common targeted account for brute-force attacks. To disable root login in sshd_config:
PermitRootLogin no
- Enable key authentication, keys are more secure than passwords. In sshd_config:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keysIn your home directory:
% vi ~/.ssh/authorized_keys
-- insert public key in the file -- :wq
% chmod -R og= ~/.ssh/
- Disable password authentication altogether: I'm not that sure of this one, it is a lot more secure but then you'll either have to sprinkle your private key in places (I don't want that) or keep a backup system with your private key on it to which you can access from everywhere without using a key.
PasswordAuthentication no
- Make sure you do not have any of these accounts on the system:
- admin
- test
- guest
- user
- webmaster
These are a huge magnet for brute-force attacks. - Make sure these common (and others) accounts use /bin/false or /bin/nologin for shell:
- mysql
- oracle
- server
- backup
- data
- apache
- web
- nobody
- Make sure you're using the configuration file for sshd that you think you are. I've seen many servers where the file used is in /usr/local/etc instead of the more intuitive /etc/ssh/. This is determined by the -f flag in sshd startup.
If you find two of these, it's probably best to just delete the one you're not using so as not to confuse yourself.
.. and have no passwords:
% passwd -l mysql
...
You do not need to login to those accounts, ever, if you do you're doing something wrong.
I'll add more as I think about it..
TrackBack URL for this entry: http://www.unix-girl.com/mt/mt-tb.cgi/1331
I'll run through these tomorrow morning... many of my boxen are firewalled to not accept ssh connections from anywhere but the office. ;-) (Good excuse, eh?)
Thanks for posting the list.
#You don't need to sprinkle your private key around! Just take the time to set ssh-agent up properly. I kept a bunch of notes about this at http://www.wlug.org.nz/SSHNotes
You can even fire up a ssh-agent locally on the machine you're on and ssh to your home machine with agent forwarding enabled just to add the private key, as in
ssh -A home.sweet.home ssh-add
So long as the remote SSH session is aware of the agent, the key will be added to your *local* agent and persist after you disconnect. Of course you'd need a password to get into the home machine in the first place, and it becomes a single point of failure/attack (so choose it well). But that affords you the opportunity to disable any password authentication whatsoever on all your other machines.
#I use key-forwarding all the time.. but it's a really bad idea to leave yourself one point of entry.
I'd rather use password authentication.
#Aristotle: SSH agent forwarding is fantastic, but it doesn't help much if you need access while on the road. If I'm onsite at a customer when an emergency arises on my own server(s), it's uncommon for me to have my key with me while at their site. Those who travel a lot almost always have to leave one point of entry via password into their own networks. From there it's easy to use the agent to get where necessary.
#You can add www-data and postgres to the list of nologin/no password users.
The postgres user is a bit tricky, as there are times you *should* do some things using that account (`initdb`, `pg_controldata`, etc.), but you should always `su -` to it from root instead of logging in directly.
#kasia: why's that so bad? Considering you're using a password to get into your point of entry and you're using a keyphrase over a (somewhat?) secure channel to actually attain access to the key, I'd think it rather safe, so long as the password and phrase are good. Is there something I'm overlooking or underestimating?
(I wasn't suggesting you don't know ssh-agent either. :) Maybe I was the only one to have taken so long to get keys added in a remote session to propagate back to the initial host, that I don't take it for granted.)
Steve: Yeah, that's pretty much what I was suggesting. :)
Alternatively, one could always get used to carrying a keydrive around, of course..
#Cause I've been in a situation before when I had to access a system, fast, and the only point of entry was off-line. It sucks :)
I'll take my chances with the password on this one.
#Ooh, doh. That would be painful indeed.
#What exactly is the risk with SSH Protocol 1 (man-in-the-middle is about all I know)? And why would OpenSSH continue to support it?
#…but only for those of us with servers or other boxen that are running sshd. Kasia has posted a good checklist for tightening up the ssh service in the face of the increasingly-common brute-force password scans (like the one we...
(read more)
September 13, 2004 11:26 AM
Kasia has compiled a good security checklist against the recent spate of ssh attacks. If you don't know about this attack, read your log files, particularly the auth.log files and if you see repeated attempts to login as root, guest,...
(read more)
September 14, 2004 04:37 AM
On the Kasia in a nutshell blog, there is a good post about how to make an ssh server as secure as possible, while still allowing connections fro
(read more)
September 18, 2004 01:22 AM
Kasia brings up a couple of good points in her blog entry Secure access to your server checklist. With the recent increase of break-in attempts via ssh, here's a little checklist of making sure your server is as secure as...
(read more)
September 18, 2004 05:30 AM