Loading...

Knowledge Base
Categories: , , ,

Advanced Policy Firewall and Brute Force Detection Overview

Did you find this article helpful?
Copy Link

 
* Your feedback is too short
Share

This guide is intended to introduce Advanced Policy Firewall (APF) and Brute Force Detection (BFD). 

APF and BFD

Advanced Policy Firewall (APF) - simple and powerful manager of the iptables firewall built into Linux. 

Brute Force Detection (BFD) –  shell script that tracks authentication failures and blocks the offending IPs to ward off brute force attacks on system services such as mail, SSH, FTP, cPanel, and any authenticated service. 

The Basics

Ordering a new VPS or Dedicated Server from A Small Orange will come with APF and BFD pre-installed. Some folks prefer to rip it out and install ConFigServer Security and Firewall (CSF) simply because it has a cPanel module that makes it seemingly easier to control. We hope that you'll give APF/BFD a chance! You'll find it very easy to use once you know a few things about it. 

If you use APF/BFD with cPanel, do not enable cPHulk Brute Force Protection, as it will conflict with BFD, resulting in constant unnecessary email notifications.

APF, Advanced Policy Firewall

APF's configuration files are stored in /etc/apt/ and are just standard text files, as are most Linux configuration files. You are encouraged to open them and take a peek! Here are some common tasks and how they can be accomplished with APF:

Basic Control

To start, stop, and refresh APF, use the following commands:

apf -s      ----- Start

apf -f       ----- Stop

apf -r       ----- Restart

apf -e      ----- Refresh APF rules

 

Opening an Inbound Port for a Specific IP

In this case, we want to allow a remote MySQL connection through the firewall. We know the IP of the remote computer (1.2.3.4), and the port for MySQL is 3306. So, we add the following line to /etc/apf/allow_hosts.rules:

tcp:in:d=3306:s=1.2.3.4

       ^

    = not -

Then refresh the firewall rules with the command by typing:

apf -e

You can do this all on one line:

echo “tcp:in:d=3306:s=1.2.3.4” >> /etc/apf/allow_hosts.rules && apf -e

You can substitute any port and any IP. You can also use Classless Inter-Domain Routing (CIDR) notation if you are so inclined, in case you need to allow IPs in a whole subnet or range to be allowed. For example:

tcp:in:d=3306:s=1.2.3.0/24

Opening an Outbound Port for a Specific IP

The same steps apply for outgoing but with a slightly different pattern.

out:d=22:d=1.2.3.4

This would allow an outbound port 22 connection to 1.2.3.4. 

Opening Inbound and Outbound Ports

Maybe you want to run a game server or move SSH to another port. In that case, you don't want to use allow_hosts. Rules, but instead, you'll want to add those in /etc/apf/conf.apf. Open up /etc/apf/conf.apf and look for the following line:

Note: the example has been shortened for brevity.

IG_TCP_CPORTS=”21,22,25,26,53,80,110”

On that line, you'll see some familiar ports, such as 22, 25, 110. Let's say that you wanted to move SSH to port 2345. All you'd have to do is change 22 to 2345:

IG_TCP_CPORTS=”21,2345,25,26,53,80,110,2345”

Save the file, and refresh APF rules with :

apf -e

This will apply to any port you want to open to the world on your server. If you were going to run a Minecraft server on port 25565, you'd use:

IG_TCP_CPORTS=”21,2345,25,26,53,80,110,25565”

Again, use the following to refresh the firewall rules:

apf -e  

Outbound Ports and UDP

If you need outbound ports opened up, use the same procedure as above, but instead edit the line for EGress:

EG_TCP_CPORTS

The same rules also apply for UDP with the entries IG_UDP_CPORTS and EG_UDP_CPORTS. As always, when done with any edits, use:

apf -e 

Whitelisting IP Addresses

Note: whitelisting IP addresses is not recommended because it allows unfettered access to all ports on the server. If you're having issues with BFD blocking somebody's IP address, see the BFD section below for information on how to resolve that.

An IP address can be whitelisted with the following command:

apf -a 1.2.3.4 && apf -e

To remove the whitelist:

sed -i '/1.2.3.4/d' /etc/apf/allow_hosts.rules && apf -e

Blocking and Unblocking IP Addresses

You might run into a situation where BFD (described below) automatically blocks an address, and you need to unblock it manually. You also may wish to block an IP manually. If the IP in question were '12.34.56.78', then you would use the following commands:

To Deny or Block:
apf -d 12.34.56.78

To remove a blockage:
apf -u 12.34.56.78

To check why the IP was blocked, to begin with, you can look in /var/log/bfd_log. It is easiest to search by IP:

root@server [~]# fgrep 12.34.56.78 /var/log/bfd_log

Nov 28 00:06:01 shiny bfd(21191): {dovecot} 12.34.56.78 exceeded login failures; executed ban command '/etc/apf/apf -d 12.34.56.78 {bfd.dovecot}'.

The above command and the resulting entry from the log shows that '12.34.56.78' was blocked because of login failures on the Dovecot service. Dovecot handles POP and IMAP email, so it's safe to assume that somebody at '12.34.56.78' was trying to break in or forgot their password and pushed the wrong one too many times. 

BFD, the Brute Force Detector

If your server were a dance club, BFD would be the bouncer. Its basic function is simple: if an authentication request fails too many times from the same IP, it will be blocked for 10 minutes. This is very good for avoiding brute force attacks, where attackers repeatedly try different username/password combinations. Too many, and they'll be blocked. 

The downside is that it can cause unwanted lockouts for things as basic as a user trying to log in with webmail and not typing their password correctly. Unless BFD is causing issues, we recommend leaving the configuration alone.

BFD Configuration

This is not meant to be exhaustive. We're just going to look at some basic settings that you can tweak and give you an idea of how easy it is to work with BFD. A cron job runs every three minutes and activates BFD, so it is not a service that is started or stopped. 

BFD's main configuration file is /usr/local/bfd/conf.bfd. Only the first few lines should be edited. The main one we're concerned with is this:

TRIG="20"

We recommend leaving this at the default value (which may not match the example above). If you want to change the trigger points, you should do so for individual rules. A popular one to change is:

/usr/local/bfd/rules/dovecot

You can change the 'TRIG' value to whatever you want. This can help to prevent mail users from getting locked out due to too many password attempts. If you're not having this problem, you better leave it alone.

If you need to disable a rule, you can create a directory such as 'rules. Disabled' and moving the rule into it. 

mkdir /usr/local/bfd/rules.disabled/

mv /usr/local/bfd/rules/ruleyoudontwant /usr/local/bfd/rules.disabled

If you have any issues, please don't hesitate to contact Support for assistance. We'll gladly help you with any problems with APF or BFD. 

For further reading on APF or BFD, please visit the following URLs:

https://www.rfxn.com/projects/advanced-policy-firewall/

https://www.rfxn.com/projects/brute-force-detection/

Did you find this article helpful?
Copy Link

 
* Your feedback is too short

Loading...