For those of you who run a Debian machine (or heck, any UNIX-based OS):

If you run SSHD (Secure Shell Daemon) on your machine (which might be there by default and never explicity denied all outside traffic other than select IP's from gaining access, and you leave port 22 open to the world wide web, then try this command:

sudo grep sshd /var/log/auth.log

(Or, if you're already root, don't bother with using sudo.)
You may be surprised to find hundreds of lines describing failed attempts from various IP's from all around the world trying to log into your machine via SSH. Some may even have tried hundreds of logins just by themselves, using a dictionary attack. Running a whois on these addresses will often trace back to China or Korea, and emailing their ISP's abuse dept. is generally useless.

Now, if you're savvy enough when setting up your system, then you will have not used obvious names (like 'Joe') unless you tied them to very long and complicated passwords. Even if your login names aren't obvious, you should still have used very long and complicated passwords. And you will have set an especially difficult and complicated password for root. So if this is the case, your system is already fairly safe from dictionary attackers. (They're generally script kiddies and will give up and move on after a while.)

So even if your system is fairly bullet-proof in the login department, it's still fairly unsettling to just let it take repeated abuse from dictionary attackers. If you don't even use SSH to sign into your computer, then kill and disable SSHD. If you only ever sign onto it from specific IP addresses, then block all SSHD traffic with the exception of those IP's in your /etc/hosts.deny file. But if you like to keep it open for friends or your own general use from a school campus (or whatever), then you want to make it available. That is where DenyHosts comes in.

DenyHosts is a highly configurable program written in Python which can either be executed manually or via Cron, or can be run 24/7 as a daemon. Basically, it checks up on your /var/log/auth.log file periodically. It recognizes fishy activity from the log, picks up on malicious IP's and then automatically adds them to the /etc/hosts.deny file. Any IP listed in there will be actively ignored by your computer from then and on.

You can download that script from the webpage (linked above) and simply run an included Python script to install it. Or, if you're cool and you use Debian (or a derivative thereof), you can simply say:

sudo apt-get install denyhosts

(Drop the sudo if you're root.)
If you use the apt-get way, then it will automatically create a useful man page and will set itself up in /etc/inet.d so that you can easily start and stop the DenyHosts daemon. It also creates the config file (/etc/denyhosts.conf). In the config, you can specify all kinds of options (especially if you choose to run it in daemon mode, which I prefer). You can adjust tolerence levels (how many times someone fails to log in before it gives them the boot) and how often it checks the logfile (default 30 seconds). It can be set up to synchronize itself with the designer's central server so that you can also block out IP's that other people's computers have blocked. (I keep this disabled, which is default, since that would be a frighteningly huge hosts.deny file.)

Anyway, it works like a charm. As of writing this, my personal server has blocked 46 separate IP's in the past two weeks... very impressive. It's a bullet-proof machine as it is, but I like the satisfaction of watching it weed out all the losers who try to break in. You can check out a list of all the IP's my system has blocked using DenyHosts through the following link: http://www.tarlus.net

---

There are tons more features that go with DenyHosts, but I'd end up with an all-out HowTo if I type anything more about it. Heck, this is more of a HowTo than it is a blog. Oh well, I wanted to write it; I hope people will find this to be useful! At the very least, I hope more people will become aware of all the unsetting things that show up in their auth.log files!