** Andy Smith <andy@???> [2010-03-14 16:22]:
> 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..."
<snip>
> Being compromised by an SSH dictionary attack is far and away the
> most common thing that I see, and reacting to it by monitoring the
> rate of outbound SSH connections is no longer good enough. Reacting
> to it and cleaning up after it is wasting too much time, and when
> I have customers that have it happen to them repeatedly at some
> point I have to say enough is enough and not turn their service
> back on at all.
>
> Do you think there's any pro-active measures that would be
> acceptable to VPS customers? Typical ways to foil SSH dictionary
> attacks:
>
> 1) Only use strong passwords.
Is there any option to provide a facility to generate passwords to encourage
customers to use better passwords. Either an https based web system or
something like apg and some documentation. Perhaps a password change utility
that generates a password as part of the process. Anyone less familiar with
hosting would possible tend to use the documented system and hence get better
passwords.
> 2) Don't use passwords at all, only keys.
It may be less popular, but would it work by creating a key that is available
through the admin console with instructions on how to download it and use it to
access the server for the first time using openssh or putty? I had been
thinking about a slightly higher cost for a VPS with password access rather
than key, but it is too easy to go for one and switch to the other, and a major
nightmare to 'police'. A more practical suggestion may be an extra setup cost
for anyone wanting password access on installation, but key by default. That
would encourage learning how to use keys, and perhaps lead to continued usage.
The sales pitch is increased security and with decent documentation it
shouldn't be too much hassle.
> 3) Disable root login.
Should be standard to my mind, although as has been said, a compromised Ubuntu
account has sudo access with the password that has already been compromised.
> 4) Restrict the list of usernames that are valid, in combination
> with (1) and (3).
Possibly not workable, again it depends on how easy it is for non-technical
users to add usernames. SSH access my well be something that only the original
account needs for non-technical customers. Perhaps looking into a control panel
that allows some of these features to be set to make them easier to manage. Not
a quick fix though. As a comparison, I have to manually create mail addresses
allowed to be sent out through my ISP mail server relay for any domains not
part of the sub-domain they provide. The system could be much better in that
you can't use wildcards before the @ or delete entries without tech. support,
but I assume they don't have too much complaint about it.
> 5) Install DenyHosts or Fail2Ban.
I'd go for Fail2Ban as default personally, and it should be fairly easy to
promote this as a benefit to hosting for the less technical customers. Those
that are technical can easily disable it if preferred - again with some good
documentation :)
> 6) Move sshd to another port.
Not something I'm a big fan of. I suspect that many attacks will check for
something as basic as this, although I've not seen any evidence or analysis of
this theory!
> More?
Perhaps some of this could be incorporated into the admin console, and this is
the first place you log into. How easy would it be to run a script on first
login to choose these options, with the defaults being the more secure choices?
With the right 'blurb' I would expect many of the less experienced would choose
those options described as more secure. Perhaps with a bit of gentle but firm
'encouragement' along with some custom documentation you can improve customer
setups without upsetting anyone!
> I can't do anything about (1), since the password the VPS comes with
> is strong and it's presumably made weaker later on.
>
> A lot of people have trouble setting up SSH keys and I would guess
> that very few customers have them before they get a VPS, so setting
> it up out of the box to require keys would be rather limiting. So
> that's (2) out.
>
> (3) is already the case for Ubuntu of course, but not any of the
> other distributions offered. I haven't kept track of how many
> compromises have been of root and not some other user but disabling
> root access by SSH and requiring some other username seems a
> reasonable starting point, would at least limit the damage.
>
> (4) sounds too confusing unless I stated in the setup email that SSH
> has been locked down to only the one non-root user they had when set
> up.
>
> Doing (5) in the base images would be controversial but I think
> actually very effective. Would it be an outrage for you to find
> DenyHosts or Fail2Ban installed for you?
>
> Moving the SSH port is probably the most effective of all, but I
> think it would be really confusing and not accepted by people, to
> find that their SSH was provisioned e.g on port 2022 to begin with.
>
> Any thoughts?
>
> --
> http://bitfolk.com/ -- No-nonsense VPS hosting
>
> "It is I, Simon Quinlank. The chief conductor on the bus that is called
> hobby." -- Simon Quinlank
> _______________________________________________
> users mailing list
> users@???
> https://lists.bitfolk.com/mailman/listinfo/users
** end quote [Andy Smith]
--
Paul Tansom | Aptanet Ltd. | http://www.aptanet.com/ | 023 9238 0001
======================================================================
Registered in England | Company No: 4905028 | Registered Office:
Crawford House, Hambledon Road, Denmead, Waterlooville, Hants, PO7 6NU
