Whitelisting in ModSecurity

Broken down into two parts our article’s first section hits on “how to whitelist IPs or URIs,” for people who are somewhat familiar with ModSecurity but want to know further about the process. Our second section examines why we configure ModSecurity and how to prevent the security of the server from getting in the way of our work. If you have a Fully Managed Liquid Web server reach out to our Heroic Support team for assistance with whitelisting!

How to Whitelist IPs or URIs

“ModSecurity is a toolkit for real-time web application monitoring, logging, and access control.” (modsecurity.org).  In simple terms, this means that ModSec, also called mod_security or ModSecurity, is a web application firewall that can actively look for attacks to the system and stop malicious activity. However, sometimes these rules trigger when legitimate work is taking place, blocking your IP and stopping you or your developer’s until you can remove the IP block. The way around for being blocked is known as whitelisting, which essentially allows for a specific IP to access the server.   There are a few ways to whitelist a request in ModSec, either by IP or by URI (URIs are specific pages on the website). 

Getting Started

  1. Find your IP or ask your developer for theirs. (You can find this by going to ip.liquidweb.com)If you or your developer have a static IP (one that will not change), one way you can whitelist the ModSec rules is by IP.
  2. Find the ModSec error in the Apache error logs with the following command (Be sure to modify the command with your IP in place of “IP here.”):
    grep ModSec /usr/local/apache/logs/error_log | grep “IP here”.
  3. The output of this command will give you a list of hits for ModSecurity from you or your developer’s IP, which you can see below. While this looks intimidating, you will only want to pay attention to 3 bits of information highlighted.  Please note, the output will not show these colors when you are viewing the files.
Note
Blue = client, the IP which tripped the rule
Red
= ID number of tripped rule within ModSec
Green = URI, the location where the error started from

[Fri May 25 23:07:04.178701 2018] [:error] [pid 78007:tid 139708457686784] [client 61.14.210.4:30095] [client 61.14.210.4] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "20000221"] [hostname "67.227.209.163"] [uri "/db/index.php"] [unique_id "WwjPWChxvG1CO4kz-D55eQAAACU"]

 

Whitelist By IP:

1. Once you have the correct ModSec error, you will need to edit the ModSec configuration. If you are using Easy Apache 4 you will find the configuration file with this path:
/etc/apache2/conf.d/modsec2/whitelist.conf

2. Open the file with your favorite text editor, such as vim, nano, or file manager like so:

vim /etc/apache2/conf.d/whitelist.conf

3.  The blue text above will be the IP address that you are whitelisting from the original error. You must keep the backslashes (\) and up-carrot (^) in order for the IP to be read correctly. Thus it will always look something like:

“^192\.168\.896\.321”

For for the id, noted in red, you will change the number after the colon, which will be the Apache error log like we saw above. This will look similar to:

Id:2000221

Add the following code with the colored sections edited to match your intended IP.

SecRule REMOTE_ADDR "^64\.14\.210\.4"
"phase:1,nolog,allow,ctl:ruleEngine=off,id:20000221"

 

Whitelist By URI:

If your IP is dynamic (changing) and you keep getting blocked in the firewall, it is best to whitelist it via URI, the yellow item in the ModSec error.

1. Begin by opening the Easy Apache 4 configuration file:

vim /etc/apache2/conf.d/whitelist.conf

2. Add the following text to the configuration. Remember to pay attention to the highlighted parts.  Change the yellow “/db/index.php” to match your URI and the red id to match the id of your error (Do not use the colon in this one).

<LocationMatch "/db/index.php">
SecRuleRemoveById 20000221
</LocationMatch>

3. The final step for whitelisting, before you finalize the process, is to ensure you have correctly set up the whitelist. For Easy Apache 4 you will run the command:
apachectl -t

As long as the command returns “Syntax Ok” you are safe to make the whitelist active by restarting Apache. Otherwise, review the whitelists to make sure the syntax matches up correctly with the above directions.

4. Lastly, restart Apache with the following command.

/scripts/restartsrv_httpd

You have successfully whitelisted yourself in ModSec!

 

Using ModSec

Cyber Security is a hydra; once one threat is cut off, two more grow back. While this is not a new analogy, it’s important to understand as we battle threats to our network, computers, and servers. With all the complexities that come with security, I want to talk about adequately configuring ModSec to deter threats while still allowing you to work on your websites. Often, when it comes to server security, too much protection can hinder effectiveness.

For example, say you have the following set up on your server:

  • You do not allow root SSH login to the server
  • utilize dual-factor authentication for any SSH logins
  • use an SSH key for the sudo user and require other security safeguards

While this type of configuration is secure, it takes longer to log into your system to make a quick edit to your settings, a double-edged sword; how can you keep the server safe while not tying your own hands?  A great example of how this plays out is using ModSec.

ModSec can block your IP if it falsely flags your work. While this module improves system security, you’ll need to be aware of properly implementing and “scoping” the technology. Scoping in this sense means to manage risks, the focus of what is important for security while still allowing work on the server with minimal interference. To tune out legitimate requests to your server, such as when you are editing your website’s code via a plugin, ModSec has the options to whitelist rules or IPs and keep your work on track.

Whitelisting an IP from the rules that ModSec follows is a great option so long as the IP never changes (i.e. a static IP, see article here to learn more https://support.google.com/fiber/answer/3547208?hl=en) and is limited to only people you trust. This method prevents ModSec from viewing your requests as malicious and blocking your IP. This practice has the drawback that if someone (say an unhappy employee) has access to your network, they now have a way around ModSec to attack your server.

With non-static (dynamic) IPs the problems of whitelisting an IP are readily apparent. With the continual change of a dynamic IP, it creates the potential of exploiting your server, as someone could use an old IP to access the server. Whitelisting specific rules comes to save the day! When you whitelist by rules, you can edit with granularity and limit the rules to particular domains and URIs, protecting the rest of the server from attacks related to that same rule!

Example of ModSecurity

ModSec reads a series of rules and applies them to incoming requests being made to the web server. An example of what a block looks like is:

[Sat Jun 30 02:21:56.013837 2018] [:error] [pid 79577:tid 139862413879040] [client 120.27.217.223:24397] [client 120.27.217.223] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "2000064"] [hostname "67.227.192.139"] [uri "/mysql/index.php"] [unique_id "WzchhAjuZ6wPAzo9AwW1WwAAAE8"]

This error shows Apache stopped a potential attack on a file at /mysql/index.php. This is an error similar to what appears when the code is being written or edited within programs like Drupal or WordPress.

Evaluating ModSecurity

If you are persistently being blocked in your firewall while working on your code, ModSec is the likely culprit. The ModSec errors can be found in the Apache error log (in cPanel the path is /usr/local/apache/logs/error_log). The phrase “ModSec” can be quickly isolated from the log (via the command ‘grep “ModSec” /usr/local/apache/logs/error_log’). By comparing you or your developer(s) IP to the log, you’ll be able to identify stopped requests that are legitimate. Verify these are valid requests by double-checking that someone in your organization made them. Once you have done so, you can move forward in setting up a whitelist for the error, per the steps above.

Again, we want to scope to allow the least amount of wiggle room for an attack and ensure we can keep working. If you are unable to have a trusted static IP, you’ll need to use the whitelist URI  method, providing the specific page as an exemption. Once completed, remove both whitelisted items from the configuration file, in case of a genuine attack.

On a parting note, I encourage you to explore ModSec and learn more of the ins and outs of the software. Exploring different methods of whitelisting can be a lot of for to learn and most importantly helps to tighten server security. As always, our Fully Supported Customers can contact our Helpful Human Support team for assistance. Check out articles on security in our Knowledge Base, like this one on Maldet! It’s another excellent way to learn about your server and develop an understanding of server security.

Best Practices for Firewall Rules

Basic Firewall Rules

In a firewall rule, the action component decides if it will permit or block traffic. It has an action on match feature. For example, if the traffic matches the components of a rule, then it will be permitted to connect to the network. It is essential to consider the potential security risks when modifying a firewall rule to avoid future issues. Following best practices for configuring firewalls can help you maximize the effectiveness of your solution.

Continue reading “Best Practices for Firewall Rules”

An Introduction to Firewalls

In network security, the first line of defense that should be used is a firewall. What is a firewall? It is a protective layer for your server that monitors and limits the incoming and outgoing network traffic. It uses a set of rules to determine to allow or block specific network traffic. Firewalls can prevent unauthorized use before reaching your servers. Firewalls can be hardware or software based.

Continue reading “An Introduction to Firewalls”

Installing and using UFW on Ubuntu 16.04 LTS

On an Ubuntu server the default firewall management command is iptables. While iptables provides powerful functionality it’s syntax is often seen as complex. For most users a friendlier syntax can make managing your firewall much easier.

The uncomplicated firewall (UFW) is an alternative program to iptables for managing firewall rules. Most typical Ubuntu installations will include UFW by default. In cases where UFW isn’t included it’s just a quick command away! Continue reading “Installing and using UFW on Ubuntu 16.04 LTS”

How To Use the IP Blocker in cPanel

  1. This tutorial assumes you’ve already logged in to cPanel, and are starting on the home screen.

    cpanel-paperlantern-19-ipblocker--01

  2. Now let’s learn how to use the IP Blocker.

    cpanel-paperlantern-19-ipblocker--02

  3. Click the "IP Blocker" icon.

    cpanel-paperlantern-19-ipblocker--03

  4. Enter an IP address or range you would like to block, then click "Add".

    cpanel-paperlantern-19-ipblocker--04

  5. That’s it! We’ve now blocked anyone using the IP address 123.45.67.89 from accessing our website.

    cpanel-paperlantern-19-ipblocker--05

  6. You can see which IP addresses are currently being blocked.

    cpanel-paperlantern-19-ipblocker--06

  7. … and you can remove IP blocks by clicking here.

    cpanel-paperlantern-19-ipblocker--07

 

How To Start and Enable Firewalld on Fedora 23

As a matter of following security best practices, you should protect your server with a firewall. Fedora 23 and CentOS 7 come with firewalld, an alternative to iptables.

Pre-Flight Check

  • These instructions are intended specifically for enabling and starting firewalld on Fedora 23. The instructions are the same for CentOS 7.
  • We’ll be logging in as root on a Liquid Web Self Managed Fedora 23 server.

Enable Firewalld

To enable firewalld and have it start at boot, run the following command:

systemctl enable firewalld

Start Firewalld

To start firewalld, run the following command:

systemctl start firewalld

Check the Status of Firewalld

To check the status of firewalld, run the following command as root:

systemctl status firewalld

To stop and disable firewalld, visit How to Stop and Disable Firewalld on Fedora 23
 

How To Stop and Disable Firewalld on Fedora 23

For security best practices, do not disable firewalld without enabling another firewall solution. Disabling firewalld without enabling an alternative will leave every port on your server open and completely unprotected.

Pre-Flight Check

  • These instructions are intended specifically for stopping and disabling firewalld on Fedora 23. The process is the same on CentOS 7.
  • We’ll be logging in as root to a Liquid Web Self Managed Fedora 23 server.

Your server never should be without the protection of a firewall. However, there are a few cases where disabling a firewall can be helpful, such as quickly troubleshooting a connection issue or prior to the installation of a different firewall. If you must temporarily stop and disable firewalld, then follow the instructions below.

Disable Firewalld

To disable firewalld and prevent it from starting at boot, run the following command:

systemctl disable firewalld

Stop Firewalld

To temporarily stop firewalld, run the following command:

systemctl stop firewalld

Check the Status of Firewalld

To check the status of firewalld, run the following command

systemctl status firewalld

To start and enable firewalld, visit How to Start and Enable Firewalld on Fedora 23.
 

How To Unblock Your IP Address in Manage

Liquid Web has introduced a new feature designed to simplify the removal of errant IP address blocks in the firewall, and allow customers to quickly remove their own address from within their Manage dashboard. In this manner, customers can remove blocks on their IP addresses even when they are unable to access WebHost Manager itself due to the block.

Pre-Flight Check

  • The cPanel Quick IP Address Unblock feature is designed for servers using the ConfigServer Firewall (CSF).
  • The feature does not apply to any server utilizing a different firewall.
  • You must have access to your Manage dashboard to use the IP delist feature.
    Note: Customers with Dedicated, Storm, or VPS servers which are not currently using the CSF firewall can request an upgrade from support to take advantage of this Manage feature. There is no charge, it typically takes only a few minutes and the only service that needs to be restarted as a result is the firewall itself. Our support technicians also can port your existing APF rules to CSF. If requesting an upgrade, please be sure to indicate whether your server uses the Guardian backup service so that its rules also can be configured.

Step #1: Log into Your Manage Interface

  1. In Manage, click on the [+] next to your server’s hostname to expand its details.
  2. Now click on the Dashboard button to open the Server Dashboard.Dashboard

Step #2: Unblock the IP Address

  1. Click on the Network tab to bring up the Networking pane.
  2. You will see your current IP address, as reported by your web browser, pre-populated in the cPanel Quick IP Address Unblock field. If you wish to unblock a different IP address, simply replace the address shown in the field with the IP address you wish to unblock.
    If you’re attempting to unblock the IP address of a client, developer, or other party who does not know their public IPV4 address, you can direct them to http://ip.liquidweb.com to obtain their address for you.
  3. Click the Unblock IP button to attempt to automatically remove the IP address in the CSF firewall.Unblock
  4. The Unblock IP button will change to Working… while it attempts to delist the IP address. Once the process completes, you should see a banner indicating whether the delisting was successful.Success

Step #3: I Got Blocked Again. Why?

There are many reasons why an IP address can be blocked in the firewall, but the two most common are:

  • The use of an incorrect username or password combination when connecting to the server or a service such as email, ftp, ssh, or cPanel/WHM
  • A mod_security rule violation

If you are unable to determine the cause for the block, feel free to contact Heroic Support®. You also may wish to consult the following Knowledge Base articles: Unblocking an IP Address or Opening a Port in the Firewall and How to Manage the CSF Firewall in WHM/cPanel.

Basic DoS/DDoS Mitigation with the CSF Firewall

Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks are common threats that every publicly accessible web server faces. The purpose of such attacks, in simplest terms, is to flood a server with connections, overloading it and preventing from accepting legitimate traffic.

Attacks increasingly have become automated instead of directly targeted and botnets (networks of infected computers that can be remotely controlled) continue to grow at a rapid pace, making DoS and DDoS attacks much more common.

Fortunately, CSF can be used to help mitigate small attacks. Continue reading “Basic DoS/DDoS Mitigation with the CSF Firewall”

How to Block or Allow Specific Ports by Country in the CSF Firewall

In addition to being able to manage traffic from a specific country or a list of countries, CSF allows you to manage access by country to specific ports. This can be useful if you need to ensure that a particular service is available globally (such as your web server on port 80) but want to restrict international access to services such as WHM/cPanel, SSH, or FTP. Continue reading “How to Block or Allow Specific Ports by Country in the CSF Firewall”