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@centos.org http://lists.centos.org/mailman/listinfo/centos
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
Hi,
fail2ban is good choice, not only for ssh.
bye On 20.8.2009, at 23:31, Kai Schaetzl wrote:
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
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hodja Nasredin nasredin@sutra.cz
My system is Centos 5.3. and I want to study the kernel, for example, write myself kernel module. So I download the kernel source *.2.6.18.tar.bz2 and compile it in my system. make bzImage && make && make modules && make modules_install && make install. When reboot, I find I can not mount the ntfs disk to the system and some other software have the problems. Before compile the kernel source, I have installed the kernel-module-ntfs-* , and when compile the *.tar.bz2 kernel source, I added sata support with modue style. I want to know if anything I do not do ? when modify the kernel, how to update all the software? If I install the *.src.rpm kernel, is it difficult to start kernel with it? Fox example, if write myself module, it needs to make rpm then can debug it?
Hanmo wrote:
My system is Centos 5.3. and I want to study the kernel, for example, write myself kernel module. So I download the kernel source *.2.6.18.tar.bz2 and compile it in my system. make bzImage && make && make modules && make modules_install && make install. When reboot, I find I can not mount the ntfs disk to the system and some other software have the problems. Before compile the kernel source, I have installed the kernel-module-ntfs-* , and when compile the *.tar.bz2 kernel source, I added sata support with modue style. I want to know if anything I do not do ? when modify the kernel, how to update all the software? If I install the *.src.rpm kernel, is it difficult to start kernel with it? Fox example, if write myself module, it needs to make rpm then can debug it?
Take a look at this wiki article:
Hanmo wrote:
My system is Centos 5.3. and I want to study the kernel, for example, write myself kernel module. So I download the kernel source *.2.6.18.tar.bz2 and compile it in my system. make bzImage && make && make modules && make modules_install && make install. When reboot, I find I can not mount the ntfs disk to the system and some other software have the problems. Before compile the kernel source, I have installed the kernel-module-ntfs-* , and when compile the *.tar.bz2 kernel source, I added sata support with modue style. I want to know if anything I do not do ? when modify the kernel, how to update all the software? If I install the *.src.rpm kernel, is it difficult to start kernel with it? Fox example, if write myself module, it needs to make rpm then can debug it?
Also this article:
Hanmo wrote:
My system is Centos 5.3. and I want to study the kernel, for example, write myself kernel module. So I download the kernel source *.2.6.18.tar.bz2 and compile it in my system. make bzImage && make && make modules && make modules_install && make install. When reboot, I find I can not mount the ntfs disk to the system and some other software have the problems. Before compile the kernel source, I have installed the kernel-module-ntfs-* , and when compile the *.tar.bz2 kernel source, I added sata support with modue style. I want to know if anything I do not do ? when modify the kernel, how to update all the software? If I install the *.src.rpm kernel, is it difficult to start kernel with it? Fox example, if write myself module, it needs to make rpm then can debug it?
to compile your own modules in an RPM based distribution, you just need the kernel-devel RPM installed, that has all the includes and such your module should need. if you wanted to build the complete .el5 kernel from the .src.rpm, you would use rpmbuild, which would compile it according to the.spec file and would generate your own kernel .rpm. Typically when you do this, you modify the spec file and various patchfiles so your custom built kernel has its own version number suffix
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@centos.org http://lists.centos.org/mailman/listinfo/centos
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?
You are right, but that is not feasible for most shared systems.
Its hard enough to get customers to use SSH, SFTP, and SCP instead of telnet and FTP.
Getting them to use keys would be impossible.
Another problem to consider is what other ports are open on the machine. Are any of them prone to brute force attacks? I don't think you can use keys for them.
Neil
-- Neil Aggarwal, (281)846-8957, www.JAMMConsulting.com Will your e-commerce site go offline if you have a DB server failure, fiber cut, flood, fire, or other disaster? If so, ask about our geographically redundant database system.
Oliver Ransom wrote on Fri, 21 Aug 2009 11:12:35 +0930:
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?
Regarding SHH: yes. Nevertheless, you will want to handle these with rate -limiting, to avoid overflowing the logs and to protect your ressources.
Kai
Eugene Vilensky <evilensky@...> 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
-
David G. Miller -
Eugene Vilensky -
Hanmo -
Hodja Nasredin -
John R Pierce -
Johnny Hughes -
Kai Schaetzl -
Neil Aggarwal -
Oliver Ransom -
Ron Loftin