How to Create a RAM Disk

In some cases, setting up a memory-based file system may be preferable, as it allows memory on a server to be used like a disk partition. This is an excellent option for caching files and other temporary data, since RAM is faster than using physical disk space. There are two types of RAM disks that can be used:

• ramfs
• tmpfs

Ramfs creates uses the same method of storing files as the Linux file system cache, with the downfall that it will continue using memory storage until the system runs out of RAM, which can cause the system to crash or become unresponsive. Tmpfs, however, behaves like a physical partition on the disk and is capable of running out of space. With that said, it’s also possible for it to occupy swap space if the server runs out of RAM, possibly defeating the purpose of using a ramdisk altogether.

Before creating a RAM disk, check how much RAM you generally have available on your machine. You can use ‘free’ to see the current usage, or ‘sar -r’ to see historical usage. You’ll want to make sure you have enough free RAM on your system to accommodate a RAM disk.

Check the amount of free RAM you have left on your machine before creating a RAM disk. Use the Linux command free to see the unused RAM. The below is an example of a 31GB of ram in a production server.

Next, create a folder to use a a mount point, for example:

mkdir /mnt/ramdisk

Then mount it:

mount -t [tmpfs|ramfs] -o size=1024m [tmpfs|ramfs] /mnt/ramdisk

Using ‘ramfs’ as a type will denote ‘size’ as a starting size only, since it does not have a physical limit. The above example creates a 1GB ramdisk.
To retain the mountpoint over reboots, you should add this to /etc/fstab as well. Keep in mind that since this is data stored in RAM though, anything stored here will be erased every time the server is rebooted.

tmpfs /mnt/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=1024M 0 0

How to Correct Email SSL Hostname in cPanel Interface

Users in cPanel have the convenient option of automatically setting up their mail clients using a downloaded setup file, or the printed list of configurable values that displays in the cPanel interface under Mail -> Email Accounts -> Configure Email Client.  If you’re offering secure email services under a specific SSL hostname for the user to connect to, there are times where the Configure Email Client hostname may be incorrect.  This is especially true if you are using a wildcard SSL certificate for service SSL access, which will cause this feature to default to the server’s hostname.

To correct this, all you need to do is edit the following files in /var/cpanel/ssl:

• courier-imapd-DOMAINS
• courier-pop3d-DOMAINS
• exim-DOMAINS
• dovecot-DOMAINS

 

The files should contain the secure hostname that you want your customers to use when accessing email over SSL.  To make this simpler, you can use the following script:


SSL_HOST=secure.hostname # Replace this with the desired hostname
SERVICES=(courier-imapd courier-pop3d exim dovecot)
for file in ${SERVICES[@]}
do
echo $SSL_HOST >  /var/cpanel/ssl/$file-DOMAINS
done

Save the above script into a file, set the permissions to 755, and run it normally.

How to Change the Apache Default Document Root on a cPanel Server

By default, cPanel configures Apache to load its default website from /usr/local/apache/htdocs.  This page will redirect to the template of the default page that is set up by cPanel, which is configurable via WHM -> Web Template Editor.

If you want to change the location of the default site altogether, you’re going to need to modify one of the EasyApache templates.   This particular modification is easy to do:

cd /var/cpanel/templates/apache2/

cp main.default main.local

 

The main.default is used to build the structure of the entire httpd.conf, which in turn also pulls in other templates from various locations.  When you copy this to main.local, you’re telling EasyApache to use the .local file instead.  If the main.local already exists, you can probably just edit the existing version.

In this file, you’re looking for a defined VirtualHost entry that starts with this:


<VirtualHost [% vh %]>
ServerName [% servername %]
DocumentRoot [% serverroot %]/htdocs


 

You’ll want to change the DocumentRoot setting to the location of the files you want to serve.  You may also need to set SuPHP_UserGroup to the user/group of the cPanel account that owns the files.  Here’s a DocumentRoot example:

 

DocumentRoot /home/user/public_html/


 

Once you’ve changed this, run the following to apply your settings:

/scripts/rebuildhttpdconf

service httpd reload

 

Perfect Forward Secrecy with Apache 2.2 on a cPanel Server

Perfect Forward Secrecy (PFS) is a security measure that helps to ensure that a session key cannot be compromised if one of the long-term keys in its set is compromised at a later date.  With PFS, if a single key is compromised, only data protected by that key has the potential to be compromised as well.  This is a feature specific to SSL connections that is now a somewhat standard requirement for passing PCI scans.

Apache 2.4 has this ability built-in, but Apache 2.2 supports the PFS-required ciphers as of 2.2.26.  To enable this, you’ll need to make a few adjustments to the main Apache template.  First, you need to change the SSLCipherSuite value. You can adjust this in WHM -> Apache Configuration -> Global Configuration, in the SSL Cipher Suite box.  Change this value to:

SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5

Then save the file.  You can also adjust this in /var/cpanel/conf/apache/local.

From here, you will need to add an additional setting to tell Apache to honor the cipher order you just defined.  To do this:

cp /var/cpanel/templates/apache2/main.default /var/cpanel/templates/apache2/main.local

If main.local already exists, just use the existing file.

look for “SSLCipherSuite” in the template, it will look something like this:

[% IF main.sslciphersuite.item.sslciphersuite.length %]SSLCipherSuite [% main.sslciphersuite.item.sslciphersuite %][% END %]

Above this, add the following line:

SSLHonorCipherOrder on

Save the file, then apply the settings:

/scripts/rebuildhttpdconf

service httpd restart

 

To confirm PFS is working, you can run an SSL test here:

https://www.ssllabs.com/ssltest/

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

How to Disable a Domain From Sending Email

You can easily disable inbound email for a single domain simply by switching off the MX records and/or removing the domain from /etc/localdomains.  However, disabling a domain from sending email off of your server is slightly more complicated.  Even if you manage to disable the domain of an account from sending out, you still have to deal with the fact that the cPanel user itself can send email.  This user has the address of user@serverhostname, and is the default sender for scripts that utilize sendmail.  In other words, any PHP or Perl script that sends email off of your server without using proper SMTP authentication will send mail as the cPanel user.

Disable Email from Specific Domains

First, create a file called /etc/blockedsenderdomains, and add the list of domains to block email from to this file, one line at a time.
Then go into WHM > Exim Configuration Manager > Advanced Editor, and add the following to “Section: CONFIG” part:

domainlist blocked_domains = lsearch;/etc/blockedsenderdomains

In the ROUTERSTART section, add:

reject_domains:
 driver = redirect
 domains = +blocked_domains
 allow_fail
 data = :fail: Connection rejected: SPAM source $domain is manually blacklisted.

Then save the file.

New cPanel Installer Requirements

As of this writing, the newest version of the cPanel installer poses some additional requirements for new installations:

• cPanel must be installed on target version 11.40
• For any Redhat-based OS (RHEL, CentOS, CloudLinux), you must be on version 6

If your server does not meet these requirements, you have two options:

A.  Install version 11.38 as a target version

To do this, you’ll need to create a file called /etc/cpupdate.conf before cPanel is installed on your server.  In this file, add:

CPANEL=11.38

Then run the installer normally:

wget http://layer2.cpanel.net/latest
sh latest


From here, you can upgrade to the latest version by replacing “CPANEL=11.38” with:

CPANEL=stable

or the version you want to upgrade to, ie:

CPANEL=11.42

Then run /scripts/upcp to update.

B. Force the installation

Download the installer and run with the –force flag:

sh latest --force

Note that these instructions will become invalid once cPanel 11.38 becomes EOL.  The restrictions are intended to encourage system administrators to run the latest software.

How to Clean up the /boot Partition

As updates run on your server over time, you’re likely going to accumulate a number of different kernel versions.  When upgrading within the same OS version, old kernels don’t typically get cleaned up automatically.  This is to enable you to “roll back” to an older kernel if you experience problems with a newer one.

A common consequence of this is the /boot partition filling up with old kernel images.  You can safely uninstall any kernel version that you are not currently running.  To get your current running kernel, use uname:

uname -r

This will output something like:

2.6.32-431.3.1.el6.x86_64

Now find a list of all installed kernels:

rpm -qa |grep kernel

You can remove the kernel and kernel-devel packages for any kernel that you are not currently running.  In this example, you’ll not want to remove kernel-2.6.32-431.3.1.el6.x86_64.  You will usually not find more than one instance of kernel-headers or kernel-firmware, but if you do, you can remove the unused version of those too.

Note: If you’re running Ksplice for kernel updates, there are actually two kernels you should not remove: that’s the one listed above, as well as the one shown in the output of “uptrack-uname -r”.  While Ksplice patches the kernel in memory, removing an existing RPM for the acting kernel can cause unpredictable behavior.

Remove the old kernels as so:

rpm -e kernel-2.6.32-358.0.1.el6.x86_64

rpm -e kernel-devel-2.6.32-358.18.1.el6.x86_64

And so on.  Doing this will free up the unneeded files from /boot.

 

 

How to Upgrade to MySQL 5.6 on cPanel

cPanel 11.42 and higher supports MySQL 5.6.  Upgrading is simple, and if you’re coming from MySQL 5.5 you will not need to recompile PHP after the upgrade.

If you’re coming from a version prior to 5.5, it’s recommended that you upgrade to 5.5 first, then to 5.6.  The following upgrade process can be used for essentially any supported MySQL upgrade in cPanel versions 11.36 and higher.

First, set the cpanel.config file to the intended version:

/var/cpanel/cpanel.config

Look for mysql-version=, and set this to 5.6.

Then run the following script:

/usr/local/cpanel/scripts/check_cpanel_rpms –fix

This will remove the old MySQL version, install the new one, and update all tables.

If you are coming from a version earlier than 5.5, you will likely need to reinstall PHP by running EasyApache.  This is due to the fact that PHP is compiled against the MySQL client libraries, which will be different after the MySQL is upgraded.

#cpanel, #mysql-version, #php