15 Mar
2010
15 Mar
'10
2:24 p.m.
On 03/14/2010 09:51 AM, Andy Smith wrote:
Hello,
This very long email is about possible pro-active measures I could
take to prevent customers being compromised by SSH dictionary
attacks. The first part is just a recap of how we got here and what
happens. If you want to make it shorter by skipping that, then skip
to line 59 which begins with "Being compromised by an SSH dictionary
attack..."
Lots of people have already said lots of smart things, so I'll keep it
short.
I REALLY appreciate the fact that Bitfolk gives me a VM with full
absolutely full access to and from the net. I do however see all the
potential problems. So, my view on "what to do"
* Monitor/ratelimit outgoing connections. Fine by me, as long as the
limits are high enough. Yes, I do need the occational outgoing nmap.
* Strong passwords. Default password should certainly be strong, I
wouldn't mind a default install of pam_cracklib to keep passwords strong
* Default ssh for root should be without-password or no. I use
without-password + keys for off-site backup and would be somewhat
annoyed if I had to jump through sudo-hoops as well.
* Fail2Ban/DenyHosts - I use fail2ban everywhere, and would probably be
happy with denyhosts as well. Would not mind default images to be set up
with either.
* A field for ssh-pubkey(s) in the signup-form would be nice.
* OpenID for web-based stuff would be NICE!
Please don'ts :
* Please don't move sshd to another port. It will stop a host from being
low-hanging fruit, but it'll only give a false sense of security untill
the bots get just a bit smarter.
* Please don't restrict valid usernames for ssh. But, documentation for
how-to-restrict it (AllowGroups/AllowUsers in sshd_config) would be nice.
No matter what gets or doesn't get implemented. Documentation is king. I
think I'd go with a wiki and tie the authentication to the customer-db
or something.
Ok, I lied. This wasn't short at all - however, I'm sure I'm entitled to
parttake in the "Reply-to:" poll now :-)
- Ole-Morten Duesund