How To Implement cPanel Firewalls On AWS & Google 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 as Network ACLs (which by default, 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.

Security Groups

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 an 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

AWS

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.

Microsoft Azure

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.)
  Name
• Optional Description

Select OK.

Alibabacloud

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:

Rule Direction:

• 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.

Action:

• 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.

Click OK.

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

Click Create.

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:

Property                         Value
 Name:                            allow-ssh-icmp-rdp-learncustom
 Network:                         learncustom
 Direction of traffic:            Ingress
 Action on match:                 Allow
 Targets:                         cpanel
 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.

Click Create.

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).

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 the 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

Firewalld

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

or

firewall-cmd --state

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:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_firewalls#sec-Introduction_to_firewalld
https://firewalld.org/
https://fedoraproject.org/wiki/FirewallD
https://www.unix.com/man-page/centos/1/firewall-cmd/

CSF

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-standard port.

CSF auto-whitelists your connected IP address where possible on installation.

To install CSF, run the following commands as the root user:

cd /usr/src
rm -fv csf.tgz
wget https://download.configserver.com/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

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
EG_TCP_CPORTS="80″

Fail2ban

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

Install Fail2Ban:

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:

mkdir /var/run/fail2ban

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.

Configure fail2ban.local

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:

FAQ: https://www.fail2ban.org/wiki/index.php/FAQ
HOWTO: https://www.fail2ban.org/wiki/index.php/HOWTOs)
Official Fail2ban Documentation: https://www.fail2ban.org/wiki/index.php/Manual
Failban Configuration: https://www.fail2ban.org/wiki/index.php/Category:Configuration