CentOS - Aug 2009 - protecting multiuser systems from bruteforce ssh attacks

Hello,

What is the best way to protect multiuser systems from brute force
attacks?  I am setting up a relatively loose DenyHosts policy, but I
like the idea of locking an account for a time if too many attempts
are made, but to balance this with keeping the user from making a
helpdesk call.

What are some policies/techniques that have worked for this list with
minimal hassle?

Thanks!

-Eugene

On Thu, 2009-08-20 at 15:14 -0500, Eugene Vilensky
wrote:
> Hello,
> 
> What is the best way to protect multiuser systems from brute force
> attacks?  I am setting up a relatively loose DenyHosts policy, but I
> like the idea of locking an account for a time if too many attempts
> are made, but to balance this with keeping the user from making a
> helpdesk call.
Along with DenyHosts, consider the SSH server options "AllowGroups"
and
"AllowUsers" to specify the users/groups allowed to connect.  My
experience is that this will deal with the majority of brute-force
attacks, since many of these target "known" user accounts (
"root",
"daemon", etc. ) as well as "common names" ( joe, jane, etc.
).

If an attempt is made to log in with a user name not specified by the
"AllowGroups" or "AllowUsers" options, the ssh server will
reject it as
an "invalid user" and throw the connection on the floor, which seems
to
lighten the load for DenyHosts.  Refer to "man sshd_config" for more
info.

For myself, with a pretty small user population, I just create a group
called "sshusers" ( of course, the name can be whatever you choose )
and
put users in that group who need SSH access from outside.

As always, YMMV. ;>
> 
> What are some policies/techniques that have worked for this list with
> minimal hassle?
> 
> Thanks!
> 
> -Eugene
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
-- 
Ron Loftin                      reloftin at twcny.rr.com

"God, root, what is difference ?"       Piter from UserFriendly

Eugene Vilensky wrote on Thu, 20 Aug 2009 15:14:58 -0500:
> What is the best way to protect multiuser systems from brute force
> attacks?  I am setting up a relatively loose DenyHosts policy, but I
> like the idea of locking an account for a time if too many attempts
> are made, but to balance this with keeping the user from making a
> helpdesk call.
Google for SSH rate-limiting.

Kai

-- 
Kai Sch?tzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com

On 21/08/2009, at 5:44 AM, Eugene Vilensky wrote:
> Hello,
>
> What is the best way to protect multiuser systems from brute force
> attacks?  I am setting up a relatively loose DenyHosts policy, but I
> like the idea of locking an account for a time if too many attempts
> are made, but to balance this with keeping the user from making a
> helpdesk call.
>
> What are some policies/techniques that have worked for this list with
> minimal hassle?
As an additional question to the above, would forcing users to log in  
with SSH keys rather than passwords avoid requiring any anti brute  
force attack measures to be put in place?

Thanks,
Oliver
>
> Thanks!
>
> -Eugene
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

-----Original Message-----
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
Behalf Of Eugene Vilensky
Sent: Thursday, August 20, 2009 10:15 PM
To: CentOS mailing list
Subject: [CentOS] protecting multiuser systems from bruteforce ssh
attacks

Hello,

What is the best way to protect multiuser systems from brute force
attacks?  I am setting up a relatively loose DenyHosts policy, but I
like the idea of locking an account for a time if too many attempts are
made, but to balance this with keeping the user from making a helpdesk
call.
What are some policies/techniques that have worked for this list with
minimal hassle?

Hi Eugene,

Depends on the number of users (as you mentioned "mutisuser" ) And how
strong you want your system to be protected.
If its not a couple of thousands, i would suggest:
Disabling password-login alltogether, and use keys only.

On the other hand, you can also demand that all connection must be made
by using a vpn-connection (openvpn/ipsec). 
After that you can be assured that any attempt is from a local user.

Both are a much stronger protection than allow/deny or
firewall-mechanisms

Hans

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de
geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u
verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat
aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband
houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are
not the addressee or if this message was sent to you by mistake, you are
requested to inform the sender and delete the message. The State accepts no
liability for damage of any kind resulting from the risks inherent in the
electronic transmission of messages.

Eugene Vilensky <evilensky at ...> writes:
> 
> Hello,
> 
> What is the best way to protect multiuser systems from brute force
> attacks?  I am setting up a relatively loose DenyHosts policy, but I
> like the idea of locking an account for a time if too many attempts
> are made, but to balance this with keeping the user from making a
> helpdesk call.
> 
> What are some policies/techniques that have worked for this list with
> minimal hassle?
> 
> Thanks!
> 
> -Eugene
> 
I found that moving sshd to listening on a non-standard port cut back
significantly on the number of brute force attacks I was getting.  Obviously,
this doesn't do anything to really protect your system from a brute force
attack.  Some of the other response had some fairly good suggestions for
preventing brute force attacks.

I was seeing several such attacks each week and frequently more than one a day
until I moved my ssh port.  What this mainly does is cut down on the number of
script-kiddie attacks.  The problem is that the script-kiddie attacks cause so
much noise that they potentially hide someone attacking you who you really need
to be concerned about.  If the port/service is open, you really want to be able
to monitor it and cutting down on the noise helps.

Cheers,
Dave