Real FreeBSD Tips

One common issue that all systems administrators face is brute force attacks, whether it be SSH, FTP, WWW, SMB and almost anything else on a system. One frustration for admins of web servers are bots trying to gain access to password protected areas, automated scripts looking for vulnerable software, or simply poking around where they shouldn’t. Previously we have looked at stopping SSH and FTP brute force attacks with Bruteblock and IPFW. Today I will be talking about how to use those same techniques to block pesky HTTP traffic.

If you haven’t read the previous post dealing with BruteBlock, I suggest reading it as we will not be covering how to install BruteBlock. Instead we will dive right into how to apply this to HTTP brute force, working with the most common webserver software around, Apache. If you’re not familiar with Apache HTTP Server, you can read about it here.

Looking for attacks.

Before we begin any code, we need to ask the question; “What are the traffic patterns I want to block?”. If you have a media heavy site, you probably already have anti hotlinking code installed already in your .htaccess (for info on how to do this, use the anti hotlinking generator. Once your hotlinking code is in place, it will generate 403 “access denied” errors for hotlinked images in your logs. This traffic can still take a toll on the server so perhaps we want to block that.

In my case, I work with a lot of companies using password protected areas for content, using HTTP Basic Auth. When a request comes in for one of these protected areas and a correct username or password is not supplied, it will generate a 401 “authorization required” errors. So for this tutorial I will focus on these two errors. There may be other patterns you are looking for, and thanks to BruteBlock, if you can create a regular expression for it, you can BruteBlock it!

Creating a log format.

Now we have our plan for blocking attacks, we need to get a log and send it to BruteBlock. You can use one of the built-in log formats for Apache, but if you only need specific information, I would suggest creating an entirely new log format specifically for your attack. This way you can simplify your regular expressions as much as possible for BruteBlock.

In our examples up above, we are really only looking for a HTTP error code, and BruteBlock needs and IP to firewall off, so we go and create a log format using these two options. I am assuming here you have installed apache from ports and the config files are in their default locations.

For Apache 1.3.x:

ee /usr/local/apache/conf/httpd.conf

For Apache 2.x

ee /usr/local/apache2/conf/httpd.conf

Once we are in the config, we want to search for where it defines the log formats (”LogFormat” directive). We then add this line to the config file:

LogFormat “%a %s” bruteforce

Lets break down the various parts of this directive. LogFormat tells apache we are defining a new log format, obviously. Everything contained in the quotes becomes part of the log format, in this case %a is the remote IP address of the attacker, and %s is the HTTP response code for the request. You can read more about Log format variables on the Apache website.

Creating the BruteBlock rule.

So we have our log, now its time to add it to BruteBlock and your sites configuration. We will use the built-in sshd.conf we used previously.

cp /usr/local/etc/bruteblock/sshd.conf to /usr/local/etc/bruteblock/httpd.conf

Now remove all the current regexp lines in the config and replace with this:

regexp          = (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) 401

regexp2          = (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) 403

These two lines will cover our two HTTP errors, 401 and 403, with the regex at the beginning designating a match for an IP address. Once this is done you can save and move onto adding it to Apache.

This can either be done for your server wide configuration or for virtual hosts. Find your site onfiguration and add this line:

CustomLog “|exec /usr/local/sbin/bruteblock -f /usr/local/etc/bruteblock/httpd.conf” brute

Now we can save the file and get ready to have BruteBlock all those nasty requests. It is a good idea before making any changes live, to check that your Apache configuration is correct and contains no errors:

# apachectl configtest

You should see “Syntax OK” if everything is working correctly. Now we are ready to restart Apache:

# apachectl restart

If for some reason it doesn’t restart correctly, check your error log and fix any issue you may come across. If you encounter any error from this leave it in the comments and I will help to debug with you.

Check its working.

If everything went smooothly, you should now have a working BruteBlock checking your logs for naughty behaviour. BruteBlock uses the auth log by default to print its messages, so you can check /var/log/auth.log to see for any issues. You will want to make sure you have added your IPFW table so it can block IPs correctly:

# ipfw table 1 list

If you do not receive an error from IPFW you are done! If you receive an error, you will need to re-read the previous post on SSH to see how to get the firewall rules set up correctly for initial deployment.

Now you have the power of BruteBlock at your fingertips, there’s no limits to what you can monitor and block with your Apache server. Once you have got a better grasp over regular expressions, you can monitor and block all sorts of things.If any of you come up with more creative ways to use BruteBlock, leave it in a comment and maybe we can post it!

No related posts.

(No Ratings Yet)

 Loading ...