This get’s past both iptables and denyhost type approaches since they can trickle in the attacks from various bots. And your right that’s when port knocking and fwknop come in handy.

1. I need to update one of my ssh posts. I typically set MaxAuthTries to 1 or 3 depending on the system to help with this. When possible, I get rid of password auth completely.

2. I suspect the distributed monitoring is not as effective as people think. Yes, it sounds great but how many attacks do you actually block due to the pooled list? I used to use Dsheilds in the capacity and stopped as I found it helped with less than 1% of the hits on a pool of 50 servers. I would love to see numbers on this but based on my own observations these distributed tools on the scale of DenyHosts are of limited value.

Now, I am a big fan of collating data within your own environment. I’ve had great success with that approach due to the sequential scanning nature of many bots.

3. In case, I missed citing it, here’s a good reference on attacking log tools:
http://www.ossec.net/main/attacking-log-analysis-tools
The point is that ssh does not sanitize log output, so using log analysis tools can introduce new vulnerabilities.

4. For those environments, I just use VPN and lock out public ssh access completely.

Don’t get me wrong, I like the concept of denyhosts, fail2ban and similar items, especially for shared hosting environments where end-user control is not well monitored. However, when these tools turn a potential security issue, e.g. weak password, into a known exploitable issue, I tend to leave them off of my systems. For example, what if I spoof your DNS resolvers, google’s IPs, hotmail, etc. Targeting these IPs with injections could have serious impact to your operations.

1. By only looking at new connections, the scripts or attackers can attempt to enter a password up to the configured “MaxAuthTries” value configured on the ssh server. e.g. If the server is configured for 5 password attempts (5 is the default), multiplied by the number of new connections, you get 15 password attempts in a minute time frame. While a far cry from 100′s or 1000′s of password guesses, it still too many to be considered best practice IMO.

2. Rate limiting based on new connections doesn’t have the added benefit of distributed behavioral pattern analysis. DenyHosts for example obtains many thousands of reports on offending IP addresses from it’s many thousands of clients around the globe. This list is not simply “ever growing”, as there are configurable rules regarding entry tolerance and lifetime.

3. I agree that log analysis tools provide the platform for “potentially” one attack vector, as long as the application (in this case openssh) sanitizes log output, this risk is fairly low. Plus, new connections from repeat offenders are blocked by the systems tcp wrappers, reducing the risk even lower since most connections are simply refused.

4. Both Log Analysis tools like DenyHosts simple IPTables rate-limiting do not prevent zero-day attacks against vulnerable openssh servers. A much more secure method of protecting against application layer attacks is not even allowing ANY connection up the stack until the client has been authenticated by crypto system. For that I recommend Fwknop for “Single Packet Authorization”.

http://cipherdyne.org/fwknop/

No crypto authentication, the port doesn’t even respond as being open. Thanks for your comments. I also enjoyed your site.

I’ve since turned to using IPtables to rate limit connections.
http://www.rackaid.com/resources/how-to-block-ssh-brute-force-attacks/