Learn how to configure cPanel firewalls in most cloud platforms or use other security tools to harden and protect your cPanel server from malicious attacks.
Imagine that after the initial erection of the walls for this new house has been completed, the house is left with no roof to shield its occupants from the elements nor doors to keep them safe from wild animals that will want to gobble them up for dinner.
The above analogy is often what happens when a server administrator deploys a server and then forgets the most fundamental aspect of the process: security.
The cloud has given server administrators the ability to rustle up any kind of server in less than 55 seconds.
The problem with that is that often, server administrators tend the forget the most fundamental aspect of the process: security.
While most of the biggest cloud system we have come to embrace have in-built measures designed to keep us from becoming victims of our human nature, it hasn’t changed that fact that when you deploy a system and didn’t from its conception design it to be secure, you will face a hard road down the line.
The fact is that 98% of most of the attacks that a system connected online will face are opportunistic in nature rather than targeted.
When a malicious user tries his or her luck with a system and finds it robustly protected, he or she will move on to easier targets.
With an unprotected server, the story will be different as anyone with malicious intent will immediately see the box as a low-hanging ripe for the picking.
An unprotected server also shouldn’t be online, not only because it goes against everything a good admin should be, but because it makes the internet more insecure.
What are Firewalls In Computing?
What are Firewalls In Computing?
In computing infrastructure designing, the internet is always treated as an untrusted external network.
A firewall monitors and controls incoming and outgoing network traffic based on predetermined security rules.
Just as any well-designed building should have a wall intended to contain fire within a building, designated entry & exit points and rules about who should be allowed access and who should be turned back, a well-implemented firewall enables a system administrator to define what inbound and outbound communication is allowed from a server and also the ability to mitigate threats within a set parameter.
As a system administrator, the standard place to start when it comes to security is to:
- be aware that any software can be exploited including cPanel.
- understand & treat every user input is potentially hostile& malicious
- apply good security practices to defend an infrastructure
- avoid rolling out any security solution that you do not understand as in understanding.
- log all suspicious behavior if and when it is needed to forensic
- design a system in such a way that it will enable you to restore the infrastructure to its pre-compromise state.
- go beyond port firewalling to hide insecure protocols but relying on the security of the protocols that you use to defend your infrastructure.
- provide the minimal privilege needed to complete an operation successfully but nothing more than what is needed.
How To Set Up A cPanel Firewall For Mitigation
So how does one go about securing, for example, a public-facing cPanel web server in order to and lower the chances of it being compromised?
Let’s start with the basics when installing a new cPanel server.
Remove all existing rules
Just as you wouldn’t start building a building on top of what someone has already created, it is always better to rip out any existing firewall rules before implementing a new one.
Doing so gives you a clear, coherent idea of what you are allowing and blocking on your system, a piece of information you would want to have in your head when dealing with an ongoing threat.
When installing cPanel on a new machine, you should deactivate the firewall before running the installation script with:
iptables-save > ~/firewall.rules
systemctl stop firewalld.service
systemctl disable firewalld.service
where ~/firewall.rules represents the firewall rules file.
The same command will work on CentOS, Red Hat® Enterprise Linux, CloudLinux™, and Amazon® too.
When the installation process finishes, you can then select and configure a firewall from any of the options below.
SELinux (Security-Enhanced Linux) in enforcing mode is purposely built to make your web server a fortress but frankly, it takes a lot of work to configure SELinux even a basic Linux machine.
And while cPanel & WHM may be able to function with SELinux in permissive mode, it generates a large number of log entries that you wouldn’t want.
It is highly recommended that you disable SELinux and reboot the system before installing cPanel on any system.
To disable SELinux security features, use one of the following methods:
Pull up your Terminal and run:
$ sudo cp /etc/selinux/config /etc/selinux/config.backup
$ sudo vi /etc/selinux/config
The /etc/selinux/config file allows you to set the SELINUX parameters that you want the server to run.
When it opens, you will see something like this:
This file controls the state of SELinux on the system.
SELINUX= can take one of these three values:
enforcing - SELinux security policy is enforced.
permissive - SELinux prints warnings instead of enforcing.
disabled - No SELinux policy is loaded.
SELINUXTYPE= can take one of these two values:
targeted - Only targeted network daemons are protected.
strict - Full SELinux protection.
The parameter you are looking for is “SELINUX=enable”
All you have to do is to replace the word “enabled” with “disabled“.
Save the file by running “:wq” and exit.
Reboot the server:
sudo systemctl reboot
You can now start your cPanel installation and once that is done, it will be time to start the security configuration.
What Kind Of Firewall Can You Use With cPanel?
The kind of firewall you will use with cPanel will largely depend on two things:
- the deployment environment (on-premise or cloud-based)
- your level of familiarity with the tools you want to use
Implementing cPanel Firewall On The Cloud
If you are using a public cloud such as AWS, Google Cloud Platform, Microsoft Azure, Alibabacloud and host of others, you can do everything you want to from the datacenter level.
But this requires being able to create a VPC (the datacenter in cloud-speak) and while the topographical interfaces and naming convention on each of these platforms are different, it all boils down to one thing: being able to determine what ingress and egress traffic you want to give access to.
This often requires figuring out what ports that the server will be to perform optimally and then allowing inbound access to these.
There are other optional layers of security such Network ACLs (which by default, it allows all inbound and outbound IPv4 traffic and, if applicable, IPv6 traffic.) that acts as a firewall for controlling traffic in and out of one or more subnets.
But we will stick with the basics at this time.
In the cloud, a security group acts as a virtual firewall that controls the traffic for one or more instances and provides security at the protocol and port access level.
When you launch an instance, you can specify one or more security groups; otherwise, we use the default security group.
You can add rules to each security group that allows traffic to or from its associated instances.
Each security group – working much the same way as a firewall – contains a set of rules that filter traffic coming into and out of an instance.
There are no ‘Deny’ rules.
Rather, if there is no rule that explicitly permits a particular data packet, it will be dropped.
You can modify the rules for a security group at any time; the new rules are automatically applied to all instances that are associated with the security group.
When we decide whether to allow traffic to reach an instance, we evaluate all the rules from all the security groups that are associated with the instance.
On Microsoft Azure, this is called Network Security Groups (NSG).
Google Cloud Platform calls its own just Firewall Rules (Networking >>> VPC network).
GCP firewalls apply to a single VPC network but are considered a global resource because packets can reach them from other networks.
AWS & Alibabacloud calls their’s Security Groups.
Things To Keep In Mind:
Security should be part of your initial architecture design, not an after-thought.
While you can always go back and assign a newly created security group to an instance, always create your VPC with its subnet, route, firewalls, and everything ahead even before you launch your first virtual machine.
That way when you are deploying the instance, you can simply select an existing security group, re-check all the ports before hitting deploying.
Be aware that on each of these platforms, you are limited to a certain number of security groups per VPC.
You can always request that any increases to the limit, but you may notice a network performance impact.
Also, ensure that your firewall rules match the way in which you use cPanel & WHM’s services.
Creating Security Groups
To create a security group using the AWS console
Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Security Groups.
Choose Create Security Group.
Enter the name of the security group (for example, cpanel_security_group) and provide a description.
Select the ID of your VPC from the VPC menu and choose Yes, Create.
You can also use:
aws ec2 create-security-group --group-name MySecurityGroup --description "My security group" --vpc-id vpc-1a2b3c4d
On the Inbound Rules tab, choose Edit.
Select an option for a rule for inbound traffic for Type, and then fill in the required information.
Specify a value for Source as 0.0.0.0/0.
Optionally provide a description for each rule, and then choose Save.
From Azure Security Center you will be able to see a list of the network security group (NSG) and Access Control List (ACL) rules that allow or deny network traffic to your VM instances in a Virtual Network.
When an NSG is associated with a subnet, the ACL rules apply to all the VM instances in that subnet.
Microsoft Azure has a longer form with more fields to fill.
But it is relatively simple and does the exact same thing you will see on the other cloud platforms.
To create a network security group on Microsoft Azure,
In the top-left corner of the portal, select + Create a resource.
Select Networking, then select the network security group.
Enter a Name for the network security group, select your Subscription, create a new Resource Group, or select an existing resource group, select a Location, and then select Create.
In the search box at the top of the portal, enter network security groups in the search box.
When network security groups appear in the search results, select it.
Select the network security group you want to change.
Select Inbound security rules under SETTINGS.
Several existing rules are listed.
When a network security group is created, several default security rules are created in it.
You can’t delete default security rules, but you can override them with rules that have a higher priority.
To learn more about default security rules, visit https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#default-security-rules.
Select + Add.
Select or add values for the following settings:
- Source (Any, Application security group, IP Addresses, or Service Tag)
- Source port ranges (0.0.0.0/0)
- Destination (Any, Application security group, IP addresses, or Virtual Network)
- Destination port ranges
- Protocol (Any, TCP, or UDP)
- Action (Allow or Deny)
- Priority (100-4096 – the lower the number, the higher the priority. Leave a gap between priority numbers when creating rules, such as 100, 200, 300. Leaving gaps makes it easier to add rules in the future that you may need to make higher or lower than existing rules.)
- Optional Description
Log on to the ECS console.
In the left-side navigation pane, select Networks and Security > Security Groups.
Select the target region.
Find the security group to add authorization rules and then, in the Actions column, click Add Rules.
On the Security Group Rules page, click Add Security Group Rule.
In the dialog box, set the following parameters:
- Outbound: ECS instances access other ECS instances over intranet networks, or through Internet resources.
- Inbound: Other ECS instances in the intranet and Internet resources access the ECS instance.
- Select Allow or Forbid.
- Protocol Type and Port Range
- Authorization Type and Authorization Object
- Priority: The value range is 1-100. Remember, the smaller the value, the higher the priority.
Google Cloud Platform
On Google Cloud Platform, every VPC network functions as a distributed firewall.
While firewall rules are defined at the network level, connections are allowed or denied on a per-instance basis.
You can think of the GCP firewall rules as existing not only between your instances and other networks but between individual instances within the same network.
When you create a GCP firewall rule, you specify a VPC network and a set of components that define what the rule will do.
The components enable you to target certain types of traffic, based on the traffic’s protocol, ports, sources, and destinations
Unlike AWS, GCP firewall rules only support IPv4 traffic.
When specifying a source for an ingress rule or a destination for an egress rule by address, you can only use an IPv4 address or IPv4 block in CIDR notation.
Remember that you have to create a custom network before you can make this happen.
Products & services > VPC network > VPC networks
Click + CREATE VPC NETWORK.
Do the following, leaving all other fields with their default values:
Specify the subnets
Visit Products & services > VPC network > Firewall rules
Click on the network you created.
You will notice that no default firewall rules were created for the custom network.
You will have to manually add default rules in the next step.
Click + CREATE FIREWALL RULE.
Enter the following, leaving all other fields with their default values:
Direction of traffic: Ingress
Action on match: Allow
Target tags: cpanel, cloudlinux
Source filter: IP ranges
Source IP ranges: 0.0.0.0/0
Protocols and ports: Specified protocols and ports
type: icmp; tcp:22; tcp:25; tcp:53; tcp:80; tcp:110; tcp:143; tcp:443; tcp:465; tcp:587; tcp:993; tcp:995; tcp:2078; tcp:2080; tcp:2083; tcp:2087; tcp:2096; udp:53; udp:123; udp:465; udp:783; udp:873; udp:6277; udp:24441
Make sure that the source filter address includes the final ‘/0’.
If you specify 0.0.0.0 instead of 0.0.0.0/0, the filter will default to 0.0.0.0/32 — an exact host address that doesn’t exist.
cPanel Services Firewall Ports
Here are the ports that cPanel & WHM uses, and the services that use each of these ports.
We have removed all non-SSL services since using these allows attackers to intercept sensitive information, such as login credentials.
We reckon you already know what a port is.
But if you don’t know, let’s take a quick look at what a port is in networking.
In the OSI networking model, ports are mostly part of the transport layer (but can also be part of the network layer and even session layer, depending on the initiating machine (source port) and the service being called upon (destination port + IP) and who you asked) and deals with end-to-end communication between different services and applications.
A port number is a 16-bit unsigned integer, thus ranging from 0 to 65535.
For TCP, port number 0 is reserved and cannot be used, while for UDP, the source port is optional and a value of zero means no port.
For example, HTTP has port 80 assigned to it.
So, when a client wants to contact an HTTP server, it uses the destination port of 80 and a source port unique to the process making the request.
This allows the receiving host to send any received packets with a destination of port 80 to the processes “listening” for those packets, which if there is one, would normally be an HTTP server process.
When the HTTP server responds, it uses the client’s source port as the reply destination port and it might use port 80 for the reply packet’s source port.
This allows the original client to forward the port quickly to the process that made the request.
At the moment, cPanel ports range from “1” (CPAN) to “24441” (Pyzor).
|2080||CalDAV and CardDAV (SSL)||✓||✓||✓|
The most important of this process is the inbound ports.
Other considerations you might bring to bear are:
- allow free access to the loopback interface. Unlike external interfaces, binding your process to localhost is usually good for security, and therefore restricting access to the loopback interface causes more harm than benefit. This does leave you open to an attack from a local user, but that’s a risk you have to balance for yourself.
- don’t restrict all Internet Control Message Protocol (ICMP) traffic. Allowing ICMP is critical for the Internet to work; routers and hosts use it to communicate critical information like service availability, packet sizes, and host existence. Types 3 and 4, Destination Unreachable and Source Quench, are critical, and restricting them may cause more harm than gain in the future.
Other Available Firewall Options
Firewall For cPanel Script
New versions of cPanel & WHM includes the cpanel service, which manages all of the rules in the /etc/firewalld/services/cpanel.xml file.
This allows TCP access for the server’s ports.
To replace your existing iptables rules with the rules in the /etc/firewalld/services/cpanel.xml file, perform the following steps:
- run the yum install firewalld command to ensure that your system has firewalld installed.
- run the systemctl start firewalld.service command to start the firewalld service.
- run the systemctl enable firewalld command to start the firewalld service when the server starts.
- run the iptables-save > backupfile command to save your existing firewall rules.
- run the /usr/local/cpanel/scripts/configure_firewall_for_cpanel script. This also clears all existing entries from the iptables application. I
- run the iptables-restore < backupfile command to incorporate your old firewall rules into the new firewall rules file.
By default, firewall-cmd commands apply to runtime configuration but using the –permanent flag will establish a persistent configuration.
So if you need to add additional ports, add the rule (port or service) to both the permanent and runtime sets:
You can use these examples below:
sudo firewall-cmd --zone=public --add-port=45000/tcp --permanent
sudo firewall-cmd --zone=public --permanent --add-service=ssh --permanent
sudo firewall-cmd --zone=public --permanent --add-service=ssh
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --zone=public --permanent --add-service=https --permanent
sudo firewall-cmd --zone=public --permanent --add-service=https
sudo firewall-cmd --reload
Every server that runs CentOS 7, CloudLinux 7, and RHEL 7 operating systems will have the firewalld daemon pre-installed but often inactive.
FirewallD is a firewall service daemon.
It replaces the iptables interface and connects to the netfilter kernel code.
Being dynamic, it enables creating, changing, and deleting the rules without the necessity to restart the firewall daemon each time the rules are changed.
Firewalld uses the concepts of zones and services, that simplify traffic management.
Zones are predefined sets of rules.
Network interfaces and sources can be assigned to a zone.
The traffic allowed depends on the network your computer is connected to and the security level this network is assigned.
Firewall services are predefined rules that cover all necessary settings to allow incoming traffic for a specific service and they apply within a zone.
To check Firewalld status, type:
systemctl status firewalld
To start the service and enable FirewallD on boot:
sudo systemctl start firewalld
sudo systemctl enable firewalld
To stop and disable it:
sudo systemctl stop firewalld
sudo systemctl disable firewalld
To view the default available services:
sudo firewall-cmd --get-services
Configuration files are located in two directories:
- /usr/lib/FirewallD holds default configurations like default zones and common services. Avoid updating them because those files will be overwritten by each firewalld package update.
- /etc/firewalld holds system configuration files. These files will overwrite a default configuration.
You can read at:
ConfigServer is a free, well-trusted Stateful Packet Inspection (SPI) firewall, Login/Intrusion Detection for Linux servers and probably one of the easiest tools that you can use to protect your cPanel server.
It has native integration with cPanel/WHM, DirectAdmin and Webmin with a front-end to both CSF and LFD (Login Failure Daemon) that is accessible by the root account.
From this interface, you can modify the configuration files and stop, start and restart the applications and check their status.
This makes configuring and managing the firewall very simple indeed.
CSF installation for cPanel and DirectAdmin is preconfigured to work on those
servers with all the standard ports open.
It auto-configures your SSH port on the installation where it’s running on a non-
CSF auto-whitelists your connected IP address where possible on installation.
To install CSF, run the following commands as the root user:
rm -fv csf.tgz
tar -xzf csf.tgz
cd csf && ./install.sh
To configure CSF, visit WHM’s ConfigServer & Firewall interface at (Home >> Plugins >> ConfigServer & Firewall).
Please note that it is not really advisable to run multiple firewalls on one system.
This rule though is not applicable to Imunify360 since it is possible to run and enable CSF when Imunify360 is already running.
All IP addresses from Imunify360 White List will be exported to CSF ignore list.
If you have Imunify360 installed, then install CSF, Imunify360 switches to CSF Integration mode.
To check if CSF integration is enabled go to Imunify360 → Firewall tab → White List section and check if there is a warning message “CSF is enabled. Please manage IPs whitelisted in CSF using CSF user interface or config file“.
It means that CSF and Imunify360 integration processed successfully.
If you are using CSF alone, it is often better to use it along with ConfigServer ModSecurity Control (CMC) which provides you with an interface to the cPanel mod_security implementation from within WHM.
With ConfigServer ModSecurity Control you can:
- disable mod_security rules that have unique ID numbers on a global, per cPanel user or per hosted domain level
- disable mod_security entirely, also on a global, per cPanel user or per hosted domain level
- edit files containing mod_security configuration settings in /usr/local/apache/conf
- view the latest mod_security log entries
To read about how Imunify360 works with ConfigServer Security & Firewall (CSF), visit https://docs.imunify360.com/ids_integration/#csf-integration.
To read how to configure CSF with all its available options, visit https://download.configserver.com/csf/readme.txt.
To see how to install ConfigServer ModSecurity Control, visit https://download.configserver.com/cmc/INSTALL.txt
To see how to install ConfigServer ModSecurity Control, visit https://download.configserver.com/cmc/INSTALL.txt
APF acts as a front-end interface for the iptables application and allows you to open or close ports without the use of the iptables syntax.
The following example includes two rules that you can add to the /etc/apf/conf.apf file in order to allow HTTP and HTTPS access to your system:
Common ingress (inbound) TCP ports
IG_TCP_CPORTS="80,443″# Common egress (outbound) TCP ports
Fail2ban is an intrusion prevention software and log-parsing application that monitors system logs for symptoms of an automated attack on your cPanel server.
When an attempted compromise is located, using the defined parameters, Fail2ban will add a new rule to iptables to block the IP address of the attacker, either for a set amount of time or permanently.
Fail2ban can also alert you through email that an attack is occurring.
It isn’t the most choice for a cPanel server since its function is primarily focused on SSH attacks and what it does is almost the same as cPHulk Brute Force Protection.
cPHulk is included as part of all cPanel & WHM installations and can be used to monitor and block all login attempts made to cPanel, WHM, FTP, email, and SSH.
It provides administrators with a variety of ways to combat brute force attacks both automatically and manually, and cPHulk can even be used to block malicious IP addresses in your firewall.
Blocks of malicious logins can be issued in different durations from a temporary ban to a one-day or even permanent ban.
The highly configurable cPHulk system allows for a great deal of control.
You can specify the number of failed login attempts before an IP address is blocked, define additional actions to execute upon triggering of an automatic block, and even enable notifications to server administrators as specific events occur.
But you can further also use failban and configure it to work for any service that uses log files and can be subject to a compromise.
Ensure your system is up to date and install the EPEL repository:
yum update && yum install epel-release
yum install fail2ban
Start and enable Fail2ban:
systemctl start fail2ban
systemctl enable fail2ban
If you see the error “no directory /var/run/fail2ban to contain the socket file /var/run/fail2ban/fail2ban.sock”, create the directory manually:
Fail2ban reads .conf configuration files first, then .local files override any settings.
Because of this, all changes to the configuration are generally done in .local files, leaving the .conf files untouched.
fail2ban.conf contains the default configuration profile.
The default settings will give you a reasonable working setup.
If you want to make any changes, it’s best to do it in a separate file, fail2ban.local, which overrides fail2ban.conf.
Rename a copy fail2ban.conf to fail2ban.local.
cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local
Configure jail.local Settings
The jail.conf file will enable Fail2ban for SSH by default for Debian and Ubuntu, but not CentOS.
All other protocols and configurations (HTTP, FTP, etc.) are commented out. If you want to change this, create a jail.local for editing:
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Since we are using CentOS, you will need to change the backend option in jail.local from auto to systemd.
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
sudo systemctl status -l fail2ban
To learn more about failban, here are the documentation and manual:
Official Fail2ban Documentation: https://www.fail2ban.org/wiki/index.php/Manual
Failban Configuration: https://www.fail2ban.org/wiki/index.php/Category:Configuration
Checking Your cPanel Ports
For a Linux instance, follow these steps to verify the security group rule:
Connect to a Linux instance by using a password.
Then, run the following command:
sudo netstat -plunt
To check whether TCP 80 (replace “80” with any port) is being listened to.
sudo netstat -an | grep 80
You can also use nmap which probably is the most commonly used network mapper in the infosec world.
Nmap can be used to:
- create a complete computer network map.
- find remote IP addresses of any hosts.
- get the OS system and software details.
- detect open ports on local and remote systems.
- audit server security standards.
- find vulnerabilities on remote and local hosts.
You should run nmap ONLY on servers that you own or in situations where you’ve notified the owners.
The reason is that why you as a network administrator might be using nmap to look for possible vulnerabilities to help prevent such attacks, your action can be interpreted as “malicious cracking attempts” and most security tools and cloud providers frowns on this.
sudo yum install nmap
To install nmap on Red Hat Enterprise Linux 8 execute the following dnf command:
sudo dnf install nmap
To install nmap on an Ubuntu or Debian machine by entering:
sudo apt-get update
sudo apt-get install nmap
Use the –version option to check the installed nmap version and correctness of the actual nmap installation. For example:
Basic Nmap Scan against IP or host
Now, if you want to scan a hostname, simply replace the IP for the host, as you see below:
These kinds of basic scans are perfect for your first steps when starting with Nmap.
Scan specific ports or scan entire port ranges on a local or remote server
nmap -p 1-65535 localhost
In this example, we scanned all 65535 ports for the localhost.