How to Create a CSF Cluster to Sync Whitelists and Blacklists

Posted on Updated on

We’ve seen that the ConfigServer Firewall (CSF) package is a powerful industry-standard security solution for servers running WHM. One of the most active components is called lfd – Login Failure Daemon which tracks and records all attempts to login either via SSH or through the GUI interface and creates whitelists and blacklists of IP addresses in order to prevent brute force attacks. If you have a number of servers running WHM – and if you set up a DNS cluster you surely will – each instance of CSF will be maintaining its own white and black lists. Instead of replicating this effort each time, wouldn’t it be easier if your servers could share this information among themselves? So if one of them detects a brute force attack originating from a certain IP address, the others don’t need to wait before they too are besieged. They can pass this information along to others to preempt attacks instead.

This is known as a CSF cluster. Groups of servers sharing white and black lists. Setting it up is quite easy and only requires a few changes in the “csf.conf” file on each cluster member. Here’s how you go about it:

Configuring the Servers

To participate in a CSF cluster, the servers must be running either WHM or DNSONLY with CSF installed.In addition, within the “csf.conf” file, the “TESTING” parameter must be set to “0” or else the lfd won’t start. Fresh CSF installations have TESTING turned on by default, so this is something you have to do for every server.

In these examples, I’m going to use ConfigServer Explorer (CSE) as a file management system. You can use your own file editing software directly from the CLI if you wish.

Specifying the Clusters

The first thing to do is to obtain the IP addresses of all participating cluster members. In my example, I have just two:

Open up the “csf.conf” file found in the “etc/csf/” directory as shown below.

csf conf file

Once it’s in front of you, search for the following two parameters:


Type in the IP address of each server separated with a comma within the double quotes for each parameter as shown here:

comma separated IPs

This configuration enables all members of a cluster to send and receive whitelist and blacklist information to and from each other. You’re creating a sort of network where each server has a direct link to the other. 

The next option that needs to be enabled is called CLUSTER_BLOCK. This is on by default so unless something has changed somewhere, you won’t need to modify it:

enable cluster block

The CLUSTER_PORT value is a port number that needs to be shared amongst all the servers. Just make sure that each csf.conf file has the same CLUSTER_PORT variable.

open port

The CLUSTER_KEY is responsible for ensuring that all communication between servers is encrypted. Choose an alphanumeric string between 8 and 56 characters long – and as the documentation recommends, preferably greater than 20. It essential that this key is the same in all the csf.conf files of the servers and is also kept secret. If not, it’s possible for an attacker to spoof a message from one of the servers and compromise your security.

cluster key

This takes care of all the csf.conf file changes. Make sure you do this for every node in your cluster.

Restarting and Pinging

Once csf.conf has been modified, we need to restart both CSF as well as lfd. To do this, log into each of your servers via SSH and typing the following commands:

csf -r
service lfd restart

Once these two services have been restarted, it’s time to test our cluster. From the SSH terminal, type in:

csf --cping

If all goes well, the server should ping all the IP addresses you added to csf.config without any difficulty.

ping success

You’ll get a failure notification if one of the servers couldn’t be contacted. Creating a CSF cluster allows you to geometrically improve the efficiency of your threat detection and is an important part of security architecture.

2 Comments on “How to Create a CSF Cluster to Sync Whitelists and Blacklists”!

  • This looks good on the surface but if I bring a new server online I still need to go into each server and add the IP to the cluster list. I may as well add the updated whitelist IP list. I suppose this is good if you are not adding a lot of servers but add and remove a lot of IPS’s. If it’s the other way around however, this doesn’t seem like much of a time save or am I reading it wrong?

  • I have configured csf with one master and many slaves. The slaves each get ONLY the master address. The master uses a file with a list of all the slave ip addresses in. I have created a script on the MASTER to monitor the lfd log – when a cluster DENY is detected, the script triggers and re-broadcasts the DENY to all members. The script ignores all ALLOW/ACCEPT requests, thus a compromised slave cannot undo the DENY commands.
    The CSF developers where kind enough to accept my mod and recode it into CSF to allow use of an include file for cluster ip addresses.

Leave a Reply

Your email address will not be published. Required fields are marked *