It looks like the command \”sudo ln -s /usr/share/denyhosts/daemon-control denyhosts\” should be run from the directory \”/etc/init.d\”, but the article isn\’t clear on this point.

Better, IMHO, because attacker can\’t even attempt to log-in…even if they know the server exists.

Also, you should disable password authentication in favor of certificates which are much harder to brute-force.

My only question is: Does having lots of entries in hosts.deny cause a degradation in network performance? I ask this as denyhosts has a \’purge\’ feature to remove blocked addresses once they reach a certain age. I have mine set to 1 year but I wonder if it should be less to improve network performance – bear in mind that hosts.deny is referenced for all network connections, not just ssh.

I\’ve gotten more mileage out of Fail2Ban because it handles multiple services (ssh, ftp, pop3, imap, smtp, www); offers multiple blocking methods (iptables, netfilter, TCP wrapper); is easily extensible (write your own filter patterns and include arbitrary log files); and automatically un-bans IP addresses. This makes it more suitable for public servers that host a number of different services for multiple clients.

Another simple trick is to rate limit connections in your firewall. For example, this limits any IP address to 4 connections in 60 seconds:

iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j DROP

You could also save an SSH key to a usb keychain that you have on your keyring (which is *always* on your person, right?) and disallow password authentication entirely. This is far more secure because the likelihood of anyone brute-forcing a DSA signature in your lifetime is smaller than winning the lotto 14 weeks in a row.

These methods make password attempts go away entirely.

Also, it\’s pretty obvious that the author of this article has never even been a professional sysadmin. If you\’re going to write about security, you should have some experience either in this profession, or as a security expert.

Did anybody do any statistics on the number of attempts/denials per IP?

Portsentry, logcheck, logsentry, and hostsentry are part of the sentry tools package at sourceforge, and even though I like fail2ban I find that in a production environment I need something that is working in realtime.

Be careful though, some parts of portsentry can be setup with hair triggers, and you need to make sure you have your exceptions in or else you may find yourself clearing out your /etc/hosts.deny and iptables for a few days until everything settles down.

I used to add the intruder\’s IP to host.deny, buy again, their IP keep changing and I got a bit tired. So…

I changed my SSH port to 1234 instead! and that really helps (in my case). Now, after a month of monitoring, I can proclaim I face no trace of brute force attacks. Alternatively, if you\’re more technical advance, can try knockd.

True real-time reaction requires deep packet inspection. The defensive system must have an application-level knowledge of the protocols and up-to-date attack signatures. It also introduces a significant performance impact, especially when the host is under stress or attack from multiple sources.

We use Fail2Ban in daemon mode. After adjusting our log file buffering, we see response times in the 1-2 second range. Since we also implement rate limiting on SSH, FTP, POP3, IMAP, and SMTP services, an attacker\’s window of opportunity is fairly limited.

I considered Trisentry (PortSentry, LogSentry, HostSentry) three years ago. Here are my concerns:

- The package hasn\’t been updated since May 2003. Seven years is a LONG time in the security world.

- FreeBSD and several Linux distros have dropped third-party maintenance in favor of more active projects.

- PortSentry\’s signatures are hard-coded in the base C code. The open source scanning tool, nmap, provided workarounds for PortSentry five years ago.

- Logcheck\’s pattern matching is fairly limited — simple keywords with wildcards — no regular expressions. That makes hacking your own signatures unnecessarily difficult.

- The package analogous to DenyHosts and Fail2Bail — HostSentry — hasn\’t been publicly available since Cisco acquired Psionic Technologies in late 2002. That leaves us without the ability to review warnings from the applications themselves (especially useful with web applications).

- While watching for port scans can provide some forewarning, there is no guarantee a subsequent attack will be immediate. On our production systems, we see port scans occur up to a week prior an attack. Blocking IP addresses for extended lengths of time — especially proxy or gateway servers — causes far more harm than good.