cPHulkd vs. LFD/BFD: A Comprehensive Comparison

With brute-force attacks being an ongoing headache for system administrators, it’s no wonder that firewalls engineered to deter these attacks are becoming more commonly used.  On the top of the list, as far as cPanel servers are concerned, are LFD, CFD, and cPHulk.  This article will touch on what each of these solutions is intended to do, how they work, and how you can determine which one is best for you.

What’s a Brute Force Attack?

First things first – if you’re going to use a firewall to stop a brute-force attack, it would be helpful to know what this attack actually is.  When someone is brute-forcing your server, they are basically taking a list of usernames or passwords – whether the list is pre-compiled or generated on the fly – and trying those credentials against something on your server, typically in an automated fashion.  The goal of the attacker is to eventually find a combination of login credentials that grants access.

Obviously, your first defense against this sort of attack is having a decently strong password, and changing it regularly.  This, however, isn’t a complete solution, as most of us are dealing with one or both of the following scenarios:

  • A number of end users that don’t quite understand the concepts of secure password selection, storage, and rotation (i.e., the user that has habitually used “p@ssw0rd” for everything since 1999)
  • The brute-force attack becomes resource-expensive for your server, resulting in resource exhaustion and service outages

In response to this problem, LFD, BFD, and cpHulk tend to be the main solutions considered for mitigation.  So let’s look at these more in depth.


CpHulk is a native cPanel application-level firewall that essentially rejects any login attempt from an IP address that has previously failed proper authentication after a certain number of tries within a certain period of time.  When an IP reaches this threshold, it is added to the cPhulk blacklist (which is essentially a table in a MySQL database), and ties into the Linux PAM system to dynamically block that IP from authenticating any further.

Now, there are some advantages to this.  For one, it’s easy to set up and manage.  All you have to do is go into WHM -> cPHulk Brute Force Detection, and turn it on.  All of your management is done from this location, and if you manage to get yourself blocked, you can easily SSH into your server, jump into the database, and clear the block.  You can also whitelist yourself so you don’t manage to get blocked.

With that in mind, being able to SSH into a server that you are essentially supposed to be blocked from is, in all actuality, a problem!  With cPHulk, being an application-level firewall, it does not actually block any IP from accessing your server.  The IP can still connect to any service that responds publicly and continue to try to brute-force it.  Though cPHulk will simply deny the login, the fact of the matter is, the IP is still opening a connection to your server and attempting to create a session.  This, on a large scale, can become an unnecessary waste of resources, especially on very busy servers.


LFD (Login Failure Daemon) is an extension of the popular ConfigServer Firewall (CSF), which BFD (Brute-Force Detection) is an extension of Advanced Policy Firewall (APF), another very popular choice for Linux servers.  Both of these are based off of the natively-provided iptables module, which is basically the main component of most Linux firewalls.  While the method in which they run varies slightly, both LFD and BFD are similar in nature – they scan through log files for failed logins that exceed a set threshold, then block the IP address from the server either temporarily or permanently, depending settings you choose.

The advantage to this is the fact that when an IP is added with a DROP rule via iptables, the IP cannot connect to the server until the rule is removed.  Since no connection can be established, no further login attempts from that IP can be made.   This is the preferred behavior of most system administrators.

As a possible disadvantage, if you manage to block yourself, you could be in trouble since you’d essentially have no way of accessing your server (from that IP of course) until the block clears.  That is, if it clears.  There does exist the possibility of whitelisting your own IP or using the WHM autofixer if you happen to lock yourself out (but again, you may even be unable to access WHM).  In that effect, the installation and configuration of both LFD and BFD is slightly more complex than that of cPHuld, in that you’d typically be doing it via CLI.  CSF, once installed, does have a WHM interface to provide for easier configuration, though some familiarity with Linux firewalls may be needed to understand some of the more complex settings.  CSF also tends to be a little too feature-rich for its own benefit, often making the configuration more frustrating for users that are less-experienced.


While all three of these solutions can be effective at mitigating brute-force attacks against your applications, large-scale attacks involving hundreds of different IP addresses may be too intense for any of these to handle.  This is something to keep in mind when choosing your solution.  cPHulk is good for very small-scale attacks, while BFD and LFD are effective at handling larger ones.  Attacks exceeding the capabilities of either may require more sophisticated measures, such as a network-level firewall or IDS. The ease of configuration (and making sure you’re setting things up properly) is also a factor to consider.  Either way, some protection is better than none.

#cphulk, #security