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