Post from: Real FreeBSD Tips Blog

Youtube ZFS Videos

No related posts.

Post from: Real FreeBSD Tips Blog

Real FreeBSD Tips is now iPhone Friendly

No related posts.

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!

Post from: Real FreeBSD Tips Blog

Stopping HTTP brute force attacks with BruteBlock & IPFW

No related posts.

1. BSD license allows users/companies to modify a program’s source code and not to release changes to the public
2. BSD has the so-called “core system” (without packages)
3. On BSD systems, all add-on packages are strictly installed into the /usr/local directory
4. BSD systems use the system of “ports”, which are fingerprints of applications in the /usr/ports directory

….and so on.

Read the full list here. Do you think this is an apt description? Let us know in the comments.

UPDATE: Feb 3 2009

There has been a nice discussion over on the FreeBSD forums about these differences too, you can check out the hread here.

Post from: Real FreeBSD Tips Blog

Differences Between Linux and FreeBSD

No related posts.

According to the forum:

The FreeBSD bugbusting team is coordinating a network bugathon, which will be held from 2009-01-30 to 2009-02-01 (Fri-Sun). The plan is to work through all network related PRs still open in GNATS. Everyone is welcome to join and help this effort.

Lots of more information is available on the FreeBSD wiki: http://wiki.freebsd.org/Bugathons/January2009

IRC channel where all the fun stuff will happen: #freebsd-bugbusters on EFNet

Jump on IRC and pay them a visit if you feel like lending a hand. On a side note, what do you find to be some of the biggest issues or problems you face with FreeBSD networking?

Post from: Real FreeBSD Tips Blog

FreeBSD Network Bugathon Begins Today

No related posts.

pfSense is a free, open source customized distribution of FreeBSD tailored for use as a firewall and router. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. pfSense is a popular project with more than 1 million downloads since its inception, and proven in countless installations ranging from small home networks protecting a PC and an Xbox to large corporations, universities and other organizations protecting thousands of network devices.

If you are interested in the development of new snapshots coming out for pfSense, you can now follow them on Twitter. Check them out as its an exciting project.

Post from: Real FreeBSD Tips Blog

pfSense Commits Now Available Via Twitter

No related posts.

Although not very heavy on details the video gives a good history of how some of the internals of unix were born out of older concepts on early 60’s and 70’s operating systems. Definitely worth checking out.

You can read more about Dr McKusick at his personal site.

Post from: Real FreeBSD Tips Blog

New YouTube Video Explains FreeBSD Kernel Internals

No related posts.

You’ve got your FreeBSD web server up, server is running smoothly, and you’re getting a lot of hits. Great! Until your webserver stops responding, you log in, see no load, but all your httpd processes are running in zoneli state. You can’t kill them, the only way you can fix it is to reboot the server. Not so great. What happened?

The “zonelimits” state in FreeBSD appears when you have run out of “mbuf clusters”, groups of mbufs that carry information up and down the network stack. As the mbuf man page states, “An mbuf is a basic unit of memory management in the kernel IPC subsystem. Network packets and socket buffers are stored in mbufs.” So how do we see usage of these mbuf clusters?

$ netstat -m

You should see an output like this:

390/255/645 mbufs in use (current/cache/total)
389/129/518/25600 mbuf clusters in use (current/cache/total/max)

By default FreeBSD comes with 25600 mbuf clusters for network usage. This is fine for servers with small amonts of network connectivity, but too low for a system with any real network usage (e.g, a webserver).

So how do we get rid of this zoneli state? We increase the mbuf clusters of course!

# sysctl kern.ipc.nmbclusters=65535

kern.ipc.nmbclusters: 25600 -> 65535

This will allow more kernel memory to be allocated to the mbuf clusters, allowing more network data in memory, allowing more tcp connections. Too easy.

But wait, my server is still going into zoneli state!

Ok so we have increased mbuf clusters, but our server is still hitting the limit. Now we look at the buffers we have for tcp sending and receiving, and reduce as needed:

net.inet.tcp.sendspace: 32768

net.inet.tcp.recvspace: 32768

The higher the buffer, the more mbufs will be used for network connections. Lowering these buffers down will reduce your memory usage and save yourself some mbufs.

sysctl net.inet.tcp.sendspace=8192

sysctl net.inet.tcp.recvspace=8192

This should dramatically reduce your mbuf usage and get your server out of zonelimits once and for all.

Post from: Real FreeBSD Tips Blog

Zonelimits State: The Silent Killer

No related posts.

Technically, on FreeBSD it should be FAMP, but who are we to nitpick, it is linux.com after all. Comprehensive and easy to understand, a great tutorial based on FreeBSD ports, definitely worth a read.

Post from: Real FreeBSD Tips Blog

Comprehensive Guide to Apache/MySQL/PHP on FreeBSD

No related posts.

BSDConferences aims to provide full video lectures about FreeBSD and other BSD flavours. From the press release:

This channel allows us to post full hour long lectures from FreeBSD conferences. The first four videos that Julian Elisher recorded at MeetBSD have been posted, and more are on the way.

There is now also an official discussion forum for FreeBSD, in addition to their mailing lists:

The FreeBSD project is finally, after much work, pleased to announce the availability of an official FreeBSD web based discussion forum. It is our hope that this forum will serve as a public support channel for FreeBSD users around the world and as a complement to our fine mailing lists.

Post from: Real FreeBSD Tips Blog

FreeBSD YouTube, forums now live

No related posts.