Patrick Shanahan wrote:

* Ronald Wiplinger [09-24-06 23:10]:

...

I see on all machines available on the Internet a permanent login try via ssh with all login names you can imagine (or even not anymore).

I would like to set-up something, that temporary closes access from this IP address for 5 minutes, if a wrong password was provided.

I use a python script, denyhosts.py. http://denyhosts.sourceforge.net/

there are others

Thanks! I tried to install it: DenyHosts-2.5 # python setup.py install Traceback (most recent call last): File "setup.py", line 4, in ? from distutils.core import setup ImportError: No module named distutils.core I use 10.1. What do I miss? bye Ronald

In 10.1 what is the name of the logging file that sshd uses that this script leverages off of. /var/log/ ?????

I use a python script, denyhosts.py. http://denyhosts.sourceforge.net/ Thanks for the info. I wasn't actively looking for this but I saw this

Patrick Shanahan wrote: post this morning and got interested because it is something I have wanted to do but haven't gotten around to dealing with it. Damon Register

James Knott wrote:

Ronald Wiplinger wrote:

...

I see on all machines available on the Internet a permanent login try via ssh with all login names you can imagine (or even not anymore).

I would like to set-up something, that temporary closes access from this IP address for 5 minutes, if a wrong password was provided.

Is something like that or even better available????

A safer method is to use a key, rather than password. That way, no key, no acess.

Still, all these accesses and the resulting error log entries are a nuisance, I block even then. I missed the start of this thread, so here are my 0.02 EUR: the OP is looking for fail2ban, http://fail2ban.sf.net/. There are dozens of other systems with similar functionality; but this is one of the more comprehensive and flexible ones. We use it with great success on several hosted systems. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany

Damon Register wrote:

...

There are dozens of other systems with similar functionality; but this is one of the more comprehensive and flexible ones. We use it with great That is your main reason for choosing this one? Did it do some

Joachim Schrod wrote: particular thing for you that the others did not?

Since I don't have much time, I just copy&paste from an internal note. HTH. BlockSSHD and fail2ban were the two best, from our POV. I cannot report practical experiences with BlockSSHD; fail2ban is used with success on some of our CTAN nodes where we have dozens of attacks daily. For the DMZ scenario mentioned below, I had to develop an own internal system, since this seems to be a rare requirement. THE REQUIREMENTS: It would be best to react only on attacks, and not on arbitrary ssh connections. Alternatively, reacting on lots of ssh connections from the same IP address in a short time frame is possible and can be used as an approximation for an attack situation. It would be good if other services would be observed as well, e.g., our ProFTP server. Manually mantained configuration files should not be changed permanently by automatic procedures. This makes those file hard to maintain and makes them differ from their committed version. (Most configuration files are under version control.) If the protection mechanism needs to keep state, it shall do so in its own file. The ssh server is not necessarily run on the firewall. I.e., the firewall may forward ssh connection to a system in the DMZ. The solution must be integrated into the operations environment. I.e., proper integration into boot procedures, monitoring, log rotation, and other operation processes is mandatory. False positives may happen, i.e., categorization of ssh requests as attacks that aren't. It must be possible to manually correct false positives. Observation has detected that attacks from the same IP address are rare for a longer duration. Using all IP addresses where any attack has ever happened for ssh request rejection is therefore overshoot. It reduces performance and is not good for manual inspection in case of connection problems or false positives. As risk mitigation strategy, it is sufficient to keep connection reject lists for the duration of server uptime, i.e., the list can and should be discarded at boot time. SOLUTION APPROACHES: There are several scripts available that parse log files for failed password attempts and modify /etc/hosts.deny after an attack has been detected. These scripts modify a manually maintained configuration file. The deny rules in this file grow without bounds, no purging is ever done. Integration in boot and log rotation processes does not exist. Therefore we have chosen to skip this approach. The ipt_recent module for iptables allow to specify thresholds for amount of connections in a given time, specific for IP addresses and protocols. That solution would be a decent choice -- if it would work. But ipt_recent doesn't work correctly when Jifies in the Linux kernel overflow. Then it blocks every request, even though they didn't pass the threshold. Therefore we have chosen to skip this approach. RELATED SOFTWARE AND INFORMATION ================================ Articles, Explanations ---------------------- http://www.linux.com/article.pl?sid=05/09/15/1655234 presents Daemon Shield, BlockHosts, and sshdfilter. Software -------- BlockSSHD: http://blocksshd.sourceforge.net/ Similar to logsurfer-ssh-defend, can deblock IP addresses after some time. Probably does not handle DMZ scenario, whitelisting is unclear as well. BlockHosts: http://www.aczoom.com/cms/blockhosts/ Adds attack hosts to /etc/hosts.deny; uses tcpwrappers to spawn the check program, no problems with log rotation. Manages discarding of obsolete entries. implemented in Python Daemon Shield: http://daemonshield.sourceforge.net/ Uses iptables to block, handles temporary blocks. According to reviews, has problems with long log files and log rotation. implemented in Python DenyHosts: http://www.denyhosts.net/ Uses tcpwrappers files to block and record state. Supports expiration of blocks. Handles log rotation. implemented in Python Fail2Ban: http://fail2ban.sourceforge.net/ Uses iptables to block, handles temporary and permanent blocks. Can also use tcpwrapper. Handles log rotation. Works for other software as well. implemented in Python pam_abl: http://www.hexten.net/pam_abl/ Blocks failed login attempts by a PAM plugin. Generic solution, beyond sshd. sshdfilter: http://www.csc.liv.ac.uk/~greg/sshdfilter/ Efficient add block rules to iptables. Does so by wrapping sshd and capturing the log output on stdout. Don't know if ssh log records end up in syslog after that; i.e., if they are logged by sshdfilter afterwards. implemented in Perl Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany