Real FreeBSD Tips

Brute force attacks are becoming more and more common in todays security landscape; if you receive security cron logs from your FreeBSD server you will know exactly what I mean. These attacks usually use automated software to try thousands of username and password combinations on SSH and FTP, continually aiming to find a weak account on your system and exploit it.

If an attacker can get access to one system account, that is the first step to doing some very bad things on your system, a nightmare for users and administrators. Luckily, there is a way to stop these attacks, and they’re freely available in the ports collection.

IPTables on Linux has the ability to dynamically add rules to block brute force attacks, however IPFW, a widely used firewall and packet filter, does not have an ability. We are forced to turn to look for 3rd party apps, lucky for us there are some very good ones out there, and we will look at 2 here.

Before we start, we will need to make sure ipfw is enabled in the kernel:

# ipfw show

If you receive an error like this:

ipfw: getsockopt(IP_FW_GET): Protocol not available

then IPFW is not enabled. You can learn how to enable it over here.

SSHGuard

The first one I looked at when trying to solve this problem was SSHGuard. It is available in the ports and is very easy to implement (This tutorial assumes you understand how to build and install ports; if not, consult the FreeBSD documentation). SSHGuard actually support all major firewall software, however for the purpose of this tutorial I am using the IPFW version.

To install, simply run this:

# cd /usr/ports/security/sshguard-ipfw; make install

Once that is built, open /etc/syslog.conf, uncomment the line added by SSHGuard, and save. Then all we need to do is reload the syslog configuration:

# /etc/rc.d/syslogd restart

Congratulations, SSHGuard is now up and running!

The good thing about SSHGuard is the rules work for common software right out of the box, so if you are running OpenSSH, you can close this window because your job is done. However, like I found, if you run something else (Commercial SSH for example), it will not add the rules as it does not have support for its log format. The only way to add rules to is request them from the vendor, which is not ideal. Which brings us to our second solution.

BruteBlock

After needing a custom ruleset, I stumbled upon BruteBlock, which allowed custom rulesets using regular expressions. Installation of this is not quite as simple, but still fairly easy:

cd /usr/ports/security/bruteblock; make install

Once it is installed, we can look at our rulesets, located in /usr/local/etc/bruteblock/ssh.conf. As you can see there is already some rules there for OpenSSH, but lets add a rule for Commercial SSH 2.

regexp2 = sshd2.*connection from \”(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\”

This will add our ruleset to catch connections through SSH. If you fee like tinkering with the amount settings and times, this is the place to do it, however the defaults should be ok.

Now we need to tell the system we want to use bruteblock. This is achieved by editing /etc/rc.conf:

bruteblockd_enable=”YES”    (is enabled YES)
bruteblockd_table=”1″        (Which table – 1)
bruteblockd_flags=”-s 60″    (How frequently to review the ipfw table for entry removal)

Next, lets add a rule to the firewall. This creates a “table”, a list of IPs that will all have a common firewall rule attached to them, in this case deny everything:

add deny ip from table(1) to any

You can add this to /etc/rc.firewall to have it load automatically on boot.

Now lets modify the syslog conf again, this time for bruteforce:

auth.info;authpriv.info      |exec /usr/local/sbin/bruteblock -f /usr/local/etc/bruteblock/ssh.conf

Now lets start bruteblock:

/usr/local/etc/rc.d/bruteblockd.sh start

Great, now reload the rules as was shown earlier in this piece. You should now be all set. You can check blockd IPs in this way:

ipfw table 1 list

And there you have it, two solutions for stopping brute-forcers dead in their tracks. One less security issue to worry about.

No related posts.

(4 votes, average: 4.75 out of 5)

 Loading ...