Posted by chr0nik on Mon 30 Jan 2006 at 14:02
Brute force attacks are a weekly issue on my Debian box and until now, I've manually managed my hosts.allow and hosts.deny files. The issue isn't so much the actual security threat as brute force attacks are usually unsuccessful, but seeing log files that are just loaded up with thousands of failed login attempts is unnerving at best.
I've searched for solutions from the black list daemon (bld) that's available as a Debian package to more complicated iptables based protection. I haven't really found whether any other services actually use bld and as far as iptables, I have a great firewall script already that I don't want to tinker with anymore.
The Solution:Enter BlockHosts; a python script that even a novice can setup, unless the existing log file patterns do not meet your needs... then you'll need a regex guru.
BlockHosts v1.0.3 has built-in support for OpenSSH, ProFTPD and vsftpd. By built-in support, I mean that blockhosts.cfg already contains regular expressions to match failed login attempts for those services. Because of the fact that the installation is so trivial and well documented in the text files included in the BlockHosts distribution, I will only cover the steps at a high-level.
Installation:BlockHosts needs Python 2.3. It will also need the development package as it will look for the Python Makefile when you run BlockHosts' setup script. These packages are installed easily with apt-get:
apt-get install python2.3 python2.3-dev
Additionally, you'll need to ensure that the services you wish to protect are being invoked by inetd and not running in standalone mode. You will also need to ensure you're using tcp_wrappers. My /etc/inetd.conf looks like this:
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/vsftpd ssh stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sshd -i
Once you've downloaded and unpacked the GZIPped tarball from the download page, the installation is fired off by executing this command:
python setup.py install --force
This copies the main script, blockhosts.py, to /usr/bin and places the configuration file, blockhosts.cfg in /etc. There is really only one thing you have to be concerned with in /etc/blockhosts.cfg and that's the line that specifies where your system log files are. Again, there are examples and abundant comments in the config file so you shouldn't have any difficulty maintaining it. Mine looks like this:
LOGFILES = [ "/var/log/auth.log", "/var/log/vsftpd.log", ]
Finally, modifications are required to your /etc/hosts.allow file. The overall format of hosts.allow is defined as:
My /etc/hosts.allow file now looks like this:
# permanent whitelist addresses - these should always be allowed access ALL: 127.0.0.1 : allow ALL: 192.168.1. : allow # permanent blacklist addresses - these should always be denied access ALL: 10. : deny ALL: 192. : deny ALL: 172. : deny # ---------------------------------------- # next section is the blockhosts section - it will add/delete entries in # between the two marker lines (#---- BlockHosts Additions) #---- BlockHosts Additions #---- BlockHosts Additions # ---------------------------------------- # finally, the command to execute the blockhosts script, based on # connection to particular service or services, for example, here's what # I use: sshd, vsftpd, in.vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allowConclusion:
BlockHosts will now evaluate my log files on each connection attempt, maintain a "watched" host list between the markers in /etc/hosts.allow, and maintain the current blocked hosts in /etc/hosts.deny. The default configuration is to block a host after 7 failed login attempts and to reset the block list after 12 hours (+/- some tolerance based on the timing of log file writes, etc.)
BlockHosts is easy to install and quite effective. If nothing else, I know I'll sleep better knowing that now after 7 failed logins instead of thousands of failed logins, the attacker will be dissuaded.
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Simple, effective, no configuration needed.
See also:
Keeping SSH access secure http://www.debian-administration.org/articles/87
[ Parent ]