tail -f findings.out

After living with DenyHosts for some time, I have made some additional configuration changes that are quite helpful.

1. Whitelist known good IPs
   I found after not very long that my home IP address had been added to my webserver’s hosts.deny file by DenyHosts. This was a result of having messed up my own login a few times. This could easily be an issue if you are regularly connecting to the box running DenyHosts (from work, home, etc).
   A simple solution: Add your IP to an allowed-hosts file in your DenyHosts working directory. Once that is in place, you might also need to find and remove the entry for the IP in question from your hosts.deny file (if it has already been added). It would be a wise choice to add known good IPs to allowed-hosts when you first setup DenyHosts. Otherwise, you might find yourself blocked from your server with no way to get access!
   For more details, see the FAQ.
2. Blacklist bad users
   It is also a good idea to add users you know are not allowed in a restricted-usernames file in your DenyHosts working directory. This keeps users that should never be allowed to login from trying, even once. There are two handy scripts provided to help in generating this list (located in the scripts dir of your DenyHosts working dir).
   The first, restricted_from_passwd.py, scans your /etc/passwd file and outputs users who have nologin set (print daemons, etc). You can redirect this to your restricted-usernames file.
   The second script is only handy after you have been running for some time. restricted_from_invalid.py, when passed your working dir, prints out the users which bad SSH attempts use most often. By default, it prints the top 10. You could also pass it a large number, say 10000, and it would print all the bad users ever attempted since DenyHosts was first started. I take this list, remove the users I have in place and know to be good, and use it as my restricted-usernames list.
3. Set the purge threshold and purge rate
   In your denyhosts,cfg file, set PURGE_DENY to something reasonable, 1 – 2 weeks perhaps. Otherwise, your hosts.deny might good huge.
   Then, set the PURGE_THRESHOLD to 2 -3. This means that while entries older than your PURGE_DENY will be removed from the deny list, if it occurs more than your PURGE_THRESHOLD, they will not be purged. This is more likely to stop the entries most often attempted.
4. Rotate log files
   Assuming you have logrotate installed (and why don’t you?), the FAQ has a great example file for adding a rotate entry for DenyHosts.
5. Sync with central DenyHosts database
   One feature which really makes DenyHosts shine is the ability to share known rogue agents among DenyHosts instances. It is off by default, but to turn it on, edit denyhosts.cfg in your working dir. To enable synchronization, simply uncomment SYNC_SERVER. The value it is set to should be correct. By default, once synchronization is one, every hour the daemon will check with the server specified. It will upload hosts that you have denied, and download hosts that at least 3 others have denied. If you wish, you can tweak the timing of this process, just to upload, the threshold for downloading, etc.
   For more details, see the FAQ.

After these changes are made, be sure to restart DenyHosts via

.

While I knew that brute-force attacks on SSH servers are very common, I had not taken the time to look at the connection attempt logs on my home servers until recently. To do that on Ubuntu run:

I was seeing attempts every few seconds for some periods, mostly on non-standard ports!

So far as I knew, no one had gotten through, but why risk the worry. Instead I installed DenyHosts. DenyHosts is a Python script that watches your auth.log, and adds IPs that repeatedly try and fail to connect to the /etc/hosts.deny list, effectively denying them future access.

It’s rather easy to install. There is a package in the repos, but I was unable to get this to work on my servers for some reason (it is still in testing). [EDIT, 2009-08-03: In setting up a new server running Jaunty, I installed from the repo. It worked without issue.] I instead followed this handy tutorial.

It worked flawlessly, with one exception. I had to run

right before starting the service. Otherwise it threw an error that the file did not exist and closed. With the touch, all went fine. That fix was listed in this bug report.

In addition, while editing /usr/share/denyhosts/denyhosts.cfg according to the tutorial I recommend you also change this line:

to

This specifies the port to block per IP denied. Instead of just blocking a potentially malicious IP from SSH access, this blocks them from all other services.