How to Limit the Number of Kernels Installed

Many Linux distributions do not clean up old kernels when new ones are installed.  This can become problematic in situations where /boot is on its own partition with a limited amount of space.  While you can easily clean up the boot partition of old kernels, this is a task that you may prefer to automate, especially if you’re dealing with multiple servers.

First, install the yum-utils package, if it isn’t already there:

yum install yum-utils

Once this is installed, you can run the following command to remove old kernels:

package-cleanup --oldkernels --count=3

The count parameter defines how many kernels you want to keep.  So in the above example, the last three kernels will be retained.  You do not have to run this command every time you update the kernel version though, because there’s a parameter you can add to /etc/yum.conf to do this automatically:


installonly_limit=3


How to Change a Parked Domain to an Addon Domain

Cpanel supports both parked domains and addon domains, with the ability to easily remove a domain as one and re-add as the other.  However, you may find this problematic if you have set up email addresses, filters, or mailing lists under a parked domain and want to make it into an addon domain.

While performing this action is not directly supported by cPanel at this time, there is a way to do this if you have root access to your server.

1) Create a subdomain

cPanel maps addon domains to subdomains of the main domain on the account.  So go into cPanel and create a subdomain for the parked domain.  For example, if your parked domain is mydomain.com, create:

mydomain.maindomain.com

 

2) Edit main userdata file

Go into /var/cpanel/userdata/$user/ and open up the main file in an editor.  You should see something like this:

addon_domains: {}

If you have existing addon domains, you’ll see them listed and can just add your domain to the list.  Otherwise, alter the entry to look like this:

addon_domains:
  mydomain.com: mydomain.mymaindomain.com

The “mydomain.mymaindomain.com” is the subdomain you created in step 1.

Remove the domain from the parked_domains section of this file, then save and close.

 

3) Edit the Virtualhost

In the same folder, open the config file for your main domain and remove the parked domain from the serveralias: line – including the www for the parked domain.

Open the file for the subdomain you created in step one, and add the parked domain to the serveralias: directive.

Make sure the mydomain.mymaindomain.com part is the same as the subdomain you created in step 1.

 

4)  Update cPanel config

Run the following commands:

/scripts/updateuserdomains

/scripts/rebuildhttpdconf

service httpd restart

 

If you go into cPanel now, the domain will be listed and treated as an addon domain, and you and upload the website’s files to the location you specified when you created its subdomain.

How to Block an Entire .TLD with Exim

cPanel comes stock with a number of ACLs and tuneables to help reduce the amount of unwanted email into your server.  At present, there are not a lot of controls on the Exim side that allow for blocking specific email addresses or servers.  While you can easily use the integrated SpamAssassin controls on a per-cPanel account basis,  it’s generally less resource-intensive to handle these blocks at SMTP time.

cPanel’s implementation of Exim is set to automatically load filters from an include directory.  This directory is located here:

/usr/local/cpanel/etc/exim/sysfilter/options/

Any files you drop in here will be included into the Exim filter.  First, create a file in this folder.  You can name it anything you want, but we’ll call ours inbound_tld_block:

vim /usr/local/cpanel/etc/exim/sysfilter/options/inbound_tld_block

In this file, add the following filter, replacing .tld with the actual TLD you want to block:
if first_delivery
and ("$h_to:, $h_cc:" contains ".tld")
or ("$h_from:" contains ".tld")
then
seen finish
endif
Now go into WHM -> Exim Configuration Manager -> Basic Editor -> Filters, and you should see the new filter listed:

** Custom Filter: inbound_tld_block

If it’s not already enabled, enable it here and then save.

To disable the filter, you can set it to “Off” in the same location in WHM and hit Save again.

#exim, #spam

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.

cPHulkd

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 & BFD

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.

Conclusion

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