-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joachim Schrod wrote:

koffiejunkie wrote:

...

Matthew Stringer wrote:

...

After having a similar problem I was recommended DenyHosts, swear by it now, blocks all these lamers.

http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts

I'll vote for this too, although I would like to get something that uses iptables instead - taking the load off sshd. But denyhosts works pretty good.

Then I can recommend fail2ban, http://www.fail2ban.org/wiki/index.php/Main_Page It works for several log files, not just for ssh.

It does also proper unblocking automatically, otherwise the deny-list tends to get very long. (You have very seldomly attacks from the same IP address several times.)

It only falls short when the ssh-login host is in a DMZ, the logs are actually stored and processed on a different host, and the firewall is a 3rd system. But even though I once thought that this is the canonical secure setup, this situation seems to be quite rare; I don't see requests for an SSH-blocker in that scenario.

Joachim

DenyHosts looks like another way of shooting oneself in the foot. It is a naive approach with the potential that a spoofed dictionary attack could end up blocking of large chunk of address space (or a particular address) from accessing your server, effectively allowing yourself to create your own vector for a kind of DoS attack. (I would be rather surprised if this had not been attempted already). fail2ban looks more sophisticated and potentially more useful in that it looks at password failures in logs not login attempts and is not restricted to ssh, and does link into iptables. To be honest this is the first of this kind of tool I have seen that looks worthy of further investigation. (The main issue would be developing a configuration that would work with SuSEs logging mechanisms). A dictionary attack is a nuisance because of the log sizes which can be created but should not be considered a major threat against a competent security regime. (i.e. timed disabled logins on password failure, restrictions on remote root login, ssh access constraints via PAM, and strong passwords with regular password changes). Most successful password related attacks are non-technological social engineering related approaches. Brute force cracks should usually only succeed against weak security. In protecting against this nuisance one should be wary of adopting any approach which could open new lines of attack. The main difficulty with automated site blocking is determining the difference between a genuine error, a genuine attack, or someone trying deny access from a location (an indirect attack). What is probably also needed is some kind of 'never deny but raise alarm' option to some parts of the address space to limit the latter scenario. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGm2KdasN0sSnLmgIRAl7oAKCL1w+HjMpXe7nBdyZQ4fCBZaQgSwCfV/Z5 JuEh4b9oBvIR9AYjH9unTz8= =JkPo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org