[CentOS] ssh security

Fri Jun 19 19:47:22 UTC 2009
Giovanni Torres <torresgi at ninds.nih.gov>


Linux Advocate wrote:
> 
>>> [Normal log stuff from dictionary attack deleted...]
>> This is common, and, presuming you have good passwords or only
>> accept authorized_keys, not a real problem other than large log
>> files.
>>
>> Look at fail2ban for a method that will automatically add
>> iptables blocks when this occurs.
>>
> 
> yes fail2ban is very useful. but also good to change to a non standard port.
> 
> 
> 
>       
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

Another quick security addition is deny root logins via ssh and also 
only allow from certain users.  That way, they can brute-force all day 
and will keep getting denied.

in /etc/ssh/sshd_config, edit the following two parameters:

PermitRootLogin no
AllowUsers johnny numberfive at 192.168.10.*


So, root cannot directly login, if this is feasible for your 
environment.  And also on this machine, johnny can login from anywhere 
but the user 'numberfive' can only login from a 192.168.10.x address.

I agree with the other users, fail2ban and others (I use DenyHosts for 
ssh) are excellent.  You can use configure these applications to add the 
remote users' IP addresses into hosts.deny or even IPtables.  Even 
further, you can have IP addresses that attempt to log in as root get 
blocked immediately and have attempts to other users get blocked after 3 
or 5 attempts, whatever you are comfortable with.

Changing the default port to something other than 22 also works wonders 
to sidestep bruteforce attempts. Take a look at the output of the 
following command:

utmpdump /var/log/wtmp

You will see all the attempts to login to your machine, locally and 
remotely.  If you were to change the ssh listen port to something other 
than 22, close to all the brute force goes away. (damn script kiddies) 
Going with authorized_keys only for logins eliminates password 
brute-force attempts altogether.

Take these and the other users' recommendations as part of your 
defense-in-depth approach, along with revising the firewall ssh rules 
for your DMZ.

Hope this helps,
Giovanni