A periodic security review at our co-op suggested switching PasswordAuthentication no on even more hosts. One of those caused a bit of a heated discussion about the benefits of increased security and the drawbacks of making emergency access harder, reminding me of the old joke about a secure computer being one encased in a block of concrete, not connected to anything and buried in a secret location.
More usefully, I found a Discussion summary on improving SSH which seemed to cover the basics pretty well. It also suggests that “nearly two thirds of all SSH private keys were stored on disk with no password protection” which is scary and can server admins even detect that sort of risky behaviour?
One thing I’ve not really noticed before is how common brute-force ssh attacks are. There are some denyhosts statistics which make interesting pictures and Strong passwords no panacea as SSH brute-force attacks rise summarises some data from last year.
So what can we do? libpam-cracklib seems like a first step, along with denyhosts. While searching around, I noticed sslh – ssl/ssh multiplexer which looks like a useful trick that I might try somewhere. It entered debian testing earlier this week and looks simple to backport to the stable version.
What tips would you give? Do you think it’s worth having at least one reasonably secure host with PasswordAuthentication enabled, just in case of disasters disabling private keys? Are you a fan of port-knocking and other more sophisticated things? Do you know more numbers about ssh security?
[…] Published ssh security http://www.news.software.coop/ssh-security/811/ […]
No, server admins cannot detect passwordless SSH keypairs. As such, if you don’t trust your users, they should be turned off, period.
SSH brute-force attacks are common, but some papers ((http://people.clarkson.edu/~owensjp/pubs/leet08.pdf ; linked from the arstechnica article, but the article itself is entirely crap) have shown that if you get owned by one, you basically deserved it: they really are as stupid as they look.
Denyhosts does nothing but turn down your log noise. In fact, the smart guys are already bypassing it (http://isc.sans.org/diary.html?storyid=4045 )… you can’t turn it low enough without locking yourself out.
Port-knocking and other stuff is silly, it just makes life harder for your users for no real gain (especially in an emergency situation): while I’m not aware of anyone preceding an SSH brute force with a port scan, if they’re smart enough to avoid denyhosts, they’re smart enough to bypass simple port moving too.
Mandate “strong” passwords (reasonably long, not in a dictionary is more than good enough), ensure your authentication mechanisms are configured correctly (that’s how they got me), and you should be safe. What you should look for in your logs, of course, isn’t failed attempts, but successful login attempts. The best thing to do is use the ‘AllowUser’ directive to limit who can login over SSH and limit the IPs allowed, whenever possible.
[slef: edited to fix links]
Just tar/gpg encrypt ~/.ssh including your private key and put that on every workstation you use. The key is putting > 1 ssh key in authorized_keys for impt accounts.
With key based auth only, logging in directly as root isn’t bad so long as you know what you’re doing.
https://twitter.com/timb_machine reminded me about AllowGroups and suggested MaxStartups. I’ll double-check AllowGroups, but I’m undecided about MaxStartups and the risk of opening a denial-of-service attack.
I agree with much of what Adam Skutt writes above, but I think there has to be one host without an IP limit so that you can do a repair from a Spanish high-speed train after a customer error or a Quebec internet cafe (and yes, those really did happen to me). Or if one of your ISPs decides to change IP address blocks without warning (which seems depressingly common among the UK mobile phone confusopoly). Most of the other points are good. Is sslh less detectable than simple port moving?
I’m still trying to decide whether the rise of ssh-capable mobile phones (see past articles) means I can always log in with private keys or not. I’m not quite that confident yet and I don’t think all workers have them yet. I still wouldn’t PermitRootLogin if I don’t have a very good reason.
For emergency rescue I’ve always used serial console access – which means that I don’t need to rely upon the host(s) having IP connectivity at all.
That doesn’t solve the problem entirely; just shifts the issue of protecting the serial-console-server’s SSH. For that I use a single URL.
Go to http://example.com/cgi-bin/ssh.cgi and SSH is enabled via iptables for the requesting host. Otherwise it appears closed – I guess thats basically the same as your portknocking.
I haven’t implemented such, but I would think that public key access should be the default, and long one-time passwords would provide for emergency access.
If your admin doesn’t have their key with them, they likely aren’t at their own machine — so any password they use should only allow access once.
I disagree on with Adam on the issue of moving the port.
Sure it is easily worked around, but it is the difference between standing in the middle of the road, and standing on the pavement.
For as long as you don’t rely on it, it will prevent you being hit by some lucky script kiddie or bot who guesses a valid combination on the first attempt, or other access indistinguishable from normal usage.
My auth log on the one server I do that only has SSH attempts related to my own IP address, even though there is no IP restriction on the servers accessing it. So this doesn’t appear to be being checked for randomly.
No doubt if different ports for ssh becomes common we can expect routine port scans, but anything that makes attacks noisier is probably good.
I haven’t seen the multiple IP in same block trick described, but saw FTP attack last week which was one username/password attempt from each bot in a botnet. They were “guessing” user names from website names, and had one existing username right from the three they were trying.
No, it isn’t. It’s the difference between having your house number on your mailbox and not having on your mailbox: which is to say they may drive past your house, but they’ll be back soon enough.
If a bot can get in through a brute-force attack, then they’ll get in when they do start port scanning. The only reason they don’t bother is because of the enormous amount of low-hanging fruit. Once they’ve gotten all of that though, they’ll start getting smarter.
If a bot can’t get in through a brute-force attack (because your passwords are strong), then they’ll never get in regardless of the port. So why waste the time and energy of everyone you care about (i.e., your users) trying to prevent something /that will never, ever happen anyway/? It makes no sense.
MJ:
Yes, you may need a bastion box that’s set wide open in case of true emergencies I suppose, but I also don’t feel qualified to tell you the best way to set one up.
I agree with a lot of the sentiment here that many of the ssh-related security “add-ons” don’t help with serious vulnerabilities that affect almost every machine and network – passphraseless ssh keys, social engineering, etc..
However, I still find that they add value. I value turning down log noise very much. Trying to debug a legitimate process is much easier when Admin and root don’t keep trying to login! Plus, I run a lot of minimalistic machines which don’t have the memory, processor power or storage to spare for the drones.
Here’s the tactics I employ in my attempts to increase security and the manageability of security while limiting information levels to be clear without being burdensome:
I use netfilter’s HASHLIMIT in a similar manner to denyhosts, as well as fail2ban to stop brutes from annoying me and filling my logs.
I’m starting to run sshd on non-standard ports. Some machines that I’m concerned about always having access to run dropbear as well via inetd.
If you can’t whitelist certain networks or use portknocking, then changing the port SSH runs on is the single easiest thing you can do to improve your SSH security.
The reality of the current situation (read those words until they sink in) is that the botnets and worms and script kiddies only target port 22.
If someone is scanning your entire network on ports 1-65535 looking for SSH servers then you have much bigger problems.
If you are going to focus on ‘potential’ issues, then strong passwords and ssh keys and crap like denyhosts will not protect you if there is a 0day exploit against openssh. What will help you is not having your SSH server running on port 22 so you don’t get broken into by a script kiddie before you have time to patch.
$ipt -A INPUT -i $extif -p tcp –dport ssh -m state –state NEW -m recent –set –name SSH
$ipt -A INPUT -i $extif -p tcp –dport ssh -m state –state NEW -m recent \
–rcheck –seconds 240 –hitcount 3 –name SSH -j LOG –log-prefix “SSH_brute_force”
$ipt -A INPUT -i $extif -p tcp –dport ssh -m state –state NEW -m recent \
–rcheck –seconds 240 –hitcount 3 –rttl –name SSH -j DROP
$ipt -A INPUT -i $extif -p tcp –dport ssh -m state –state NEW -j ACCEPT
Fun discovery: the ssh client from dropbear gets sent to https by sslh. Anyone seen that and/or know a fix? I’ll keep looking when I get time and will update this page if I find a solution.
OK, I think I’ve narrowed it down to session_identification in common-session.c trying to write before it reads. I’ve made a patch and I’ll post it if it compiles, but it’ll be a while, unless anyone wants it sooner.
It seems that it isn’t stated in the SSH RFC that the client cannot write first – it just works because many don’t. Later versions of sslh (like the current 1.10) can work with dropbear and similar so-called “Bold” clients.