Craig Hurley wrote: > Has anyone installed and configured DenyHosts > (http://denyhosts.sourceforge.net) so that it uses tcp wrappers on > debian?
I am confident that script kiddies shaking my doors and trying to lift my windows cannot break through my passwords and rsa keys. If reasonable passwords are used and care is taken to prevent them from being sniffed then I am confident that a brute force attack to crack through a user and password combination is computationally infeasible. Additionally if you ssh rsa keys then this type of attack cannot be successful even if the connection is insecure. I do however find the physical disk drive noise from one of my machines as it is hit annoying and the extra noise to the log file is also annoying. If you are finding 'denyhosts' difficult then you may want to install 'fail2ban' as one standalone method to stop this since it is extremely simple. It should work out of the box. sudo apt-get install fail2ban Both of these are python programs however and on some machines such as my very small firewall I am prevented from installing a full python environment due to disk space limitations. If anyone can recommend a similar solution that optimizes for disk space on a small dedicated firewall please post it. > I've read this blog: > http://tdot.blog-city.com/securing_ssh_with_denyhosts.htm but there are > differences in the files/paths used on debian and what the blog-author > uses. I've plugged along but I'm not sure if I have denyhosts > configured right. I don't see any file path problems. Did you install the Debian version? I would assume that the Debian package maintainer took care of getting all of the paths correct. In any case I believe you have the correct log file name /var/log/auth.log. apt-cache show denyhosts > Here are the main settings I've used to get denyhosts working (?): You will definitely want to time out blocked entries or you run the risk of a Denial of Service attack. > The thing is, if I attempt to login via SSH using a bad > username/password 3 times, there's a delay of approx 5-10 seconds before > my IP address shows up in /etc/hosts.blocked. Then it appears to be working. > I thought that by using tcp wrappers, denyhosts would put the IP > into /etc/hosts.blocked much quicker than that. I imagine (without looking and so may be quite wrong) that the delay is due to getting access to the log file information to detect this condition. In order to avoid burning a high cpu when nothing is happening most programs attempting this type of thing will need to sleep for short periods of time and 10 seconds seems reasonable to me. On averate half of that time would be waited before detection. The alternative to this delay would be FAM and I am not sure it is worth adding that as a dependency. > Also, if I change /etc/hosts.deny with the intention of blocking access > to ALL services to IPs listed in /etc/hosts.blocked, denyhosts stops > working as above. Here's what I changed /etc/hosts.deny to: > > /etc/hosts.deny > ALL:/etc/hosts.blocked > sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:allow I would avoid mixing simple and extended syntax in the same file. I would simply use the extended syntax and put everything in the /etc/hosts.allow file. Not sure this is the problem but I think it would be a better practice anyway. Also, dynamically updated files are better placed in /var/run rather than in /etc. Here is a suggested improvement. UNTESTED! ALL:/var/run/denyhosts/hosts.blocked:DENY sshd:ALL:spawn /usr/sbin/denyhosts --purge -c /etc/denyhosts.conf:ALLOW > If anyone can advise or post the relevant sections of their working > config I'd appreciated it. Sorry for jumping in with the above when I am not a user of denyhosts but hopefully it was a worthwhile contribution regardless. Good Luck, Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]