Google the SiteQuicksearchCategoriesSyndicate This BlogCreative CommonsBlog Administration |
Saturday, December 30. 2006Block Brute Force Attacks Against sshd and proftpd Using blockhosts
For a long time now I've had a lot of problems with brute force attacks against sshd and proftpd - attacks where a host will attempt to login with a dictionary of common usernames and passwords, trying each one until they find a combination that works. Apart from being a security issue, this uses up a lot of bandwidth so it's worth taking some measures to block these kind of attacks.
Both sshd and ftpd services have their own individual means for blocking individual connections, but unfortunately neither have an inbuilt method for detecting brute force attacks - counting how many failed login attempts are made from each individual IP address and then blocking that IP address if the number of failed login attempts is more than a certain number. This is where a 3rd party utility is required. There are a few utilities that can mitigate brute force attacks on services. For a while now I've used DenyHosts successfully to block sshd brute force attacks. DenyHosts works by constantly monitoring sshd logfiles and keeping track of how many failed logins have occured per IP address over time. If the number of failed logins reaches a certain threshold, DenyHosts adds an entry in /etc/hosts.allow that effectively blocks the IP address, stopping that host from connecting to the sshd service any more. DenyHosts is great, but unfortunately it's aimed only at blocking sshd brute force attacks and I need to protect the ftpd service as well as just sshd - and in future maybe adapt to block other services. With this in mind I decided to move to using a very similar script called BlockHosts (the documentation for BlockHosts actually mentions that it was inspired by DenyHosts). BlockHosts can scan a list of service logfiles in one go instead of just a single logfile as with DenyHosts, so is ideal for monitoring a number of different services for brute force attacks. The following describes how to install and configure BlockHosts on FreeBSD so it's executed every time the sshd or proftpd services are accessed using TCP_WRAPPERS - ie modifying /etc/hosts.allow so the blockhosts script is run each time sshd or proftpd are accessed. The BlockHosts script will then check if this current connection attempt is part of a brute force attack and if so, add a blocking rule to /etc/hosts.allow to deny further access. Installation of BlockHosts
We're now ready to run blockhosts.py for the first time. BlockHosts will parse each logfile mentioned in blockhosts.cfg and check for any brute force attacks and if it finds any, blocks will be added to the /etc/hosts.allow file. Note: This initial check does not take into account the period over which failed logins took place, so any IP that has more than the default 7 failed login entries will look like a brute force attacker. However, the ban BlockHosts adds will only last for the default 12 hours so this shouldn't cause a huge issue - just be aware of this and check the IPs that are added on the first run. For the very first time it's a good idea to try a 'dry run' just to see what blockhosts finds and what it'd do, without actually doing anything to the /etc/hosts.allow file. To do this, run blockhosts with the '--dry-run' flag: CODE: root@users /usr/local/etc# /usr/local/bin/blockhosts.py --verbose --dry-run blockhosts 1.0.5 started: 2006-12-30 14:15:30 ... will discard all host entries older than 2006-12-30 02:15 ... load blockfile: /etc/hosts.allow ... found both markers, count of hosts being watched: 0 Warning: no offset found, will read from beginning in logfile: /var/log/auth.log ... securelog, loading file, offset: /var/log/auth.log 0 Warning: no offset found, will read from beginning in logfile: /var/log/ftp.log ... securelog, loading file, offset: /var/log/ftp.log 0 ... updates: counts: hosts to block: 9; hosts being watched: 21 #---- BlockHosts Additions ALL: 203.88.192.225 : deny ALL: 200.71.192.7 : deny ALL: 212.227.81.146 : deny ALL: 218.25.62.75 : deny ALL: 200.46.108.164 : deny ALL: 201.57.163.2 : deny ALL: 205.129.191.11 : deny ALL: 200.68.51.91 : deny ALL: 82.38.68.217 : deny #bh: ip: 85.184.10.200 : 1 : 2006-12-30-14-15 #bh: ip: 84.158.231.209 : 1 : 2006-12-30-14-15 #bh: ip: 82.38.68.217 : 11 : 2006-12-30-14-15 #bh: ip: 82.153.28.16 : 2 : 2006-12-30-14-15 #bh: ip: 67.113.225.66 : 1 : 2006-12-30-14-15 #bh: ip: 59.108.34.228 : 2 : 2006-12-30-14-15 #bh: ip: 222.68.192.132 : 2 : 2006-12-30-14-15 #bh: ip: 218.25.62.75 : 20 : 2006-12-30-14-15 #bh: ip: 217.83.162.157 : 1 : 2006-12-30-14-15 #bh: ip: 212.227.81.146 : 29499 : 2006-12-30-14-15 #bh: ip: 210.1.132.178 : 4 : 2006-12-30-14-15 #bh: ip: 205.129.191.11 : 20 : 2006-12-30-14-15 #bh: ip: 204.141.87.14 : 3 : 2006-12-30-14-15 #bh: ip: 203.88.192.225 : 448 : 2006-12-30-14-15 #bh: ip: 202.108.40.109 : 1 : 2006-12-30-14-15 #bh: ip: 201.57.163.2 : 2867 : 2006-12-30-14-15 #bh: ip: 200.71.192.7 : 761 : 2006-12-30-14-15 #bh: ip: 200.68.51.91 : 10 : 2006-12-30-14-15 #bh: ip: 200.46.108.164 : 170 : 2006-12-30-14-15 #bh: ip: 200.105.255.90 : 7 : 2006-12-30-14-15 #bh: ip: 152.104.125.14 : 3 : 2006-12-30-14-15 From this you can see nicely what blockhosts makes of the service logfiles and the addresses that have tried to connect unsuccessfully. On my host, as you can see above, there are a few that are obviously dodgy (I would only expect a max of maybe 8 connections per ip per month, so clearly 29,499 connections is just wrong!). Once you're happy that the output is correct, run blockhosts again without the '--dry-run' flag and the /etc/hosts.allow file will be modified. Also from now on the logfiles will only be read from the last recorded offset which saves a lot of time if your logfiles are very big. Big thanks to the BlockHosts author Avinash Chopde ! Thursday, January 29. 2004FTP Transfer Failure With A Firewall
This is a question that crops up fairly often about why remote ftp clients using passive data transfer mode can't connect properly to the FTP server whilst a firewall is in effect.
See the extended article for a discussion of the problem. Continue reading "FTP Transfer Failure With A Firewall" Wednesday, January 28. 2004ProFTPD Delay Whilst Authenticating
When connecting to the proftpd server, a noticeable delay of around 5 seconds can be seen. To fix this I switched off ident lookups in proftpd.conf and all was fine:
CODE: # Don't do ident lookups: IdentLookups off Simple :P
(Page 1 of 1, totaling 3 entries)
|

