This guide is intended as a basic introduction of Advanced Policy Firewall (APF) and Brute Force Detection (BFD). For more detailed information, feel free to contact A Small Orange and we’ll be glad to help you. See the end of the article for links to the developers website.
Looking for more answers to your hosting-related questions?
Check out the whole A Small Orange Knowledgebase here.
What are 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 aucthentication failures and blocks the offending IP’s to ward off brute force attacks on system services such as mail, SSH, FTP, cPanel and any authenticated service.
The Basics
When you order a new VPS or Dedicated Server from A Small Orange it 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. It is our 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, and in the past has resulted in constant unnecessary email notifications.
APF, Advanced Policy Firewall
APF’s configuration files are stored in
/etc/apf/
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
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 IP’s 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 as for incoming, but with a different pattern slightly.
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’d like to run a game server, or move SSH to another port. In that case you don’t want to use
allow_hosts.rules
, but rather 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 pretty 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 for 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, show that ’12.34.56.78′ was blocked because of login failures on the dovecot service.Dovecot handles POP and IMAP email, so its safe to assume that somebody at ’12.34.56.78′ was either trying to break in or simply forgot their password and tried 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 keeping out brute force attacks, where attackers try different username/password combinations over and over again. Too many, and they’ll be blocked.
The downside to this is that it can cause unwanted lockouts for things as basic as a user trying to login 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 how easy it is to work with BFD. A cron job runs every three minutes that activates BFD, and 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 be 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 then you’re better of leaving it alone.
If you need to disable a rule altogether you can do so by creating 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
I hope you’ve found this article useful. If you have any issues, please don’t hesitate to contact Support for assistance. We’ll be glad to help you with any issues 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/
Some other Knowledgebase articles to help simplify your hosting experience:
Click here to learn how to get started with SiteLock.
Learn how to set up an email address.
Click here to learn all about Nameservers.
