What Is CSF Firewall and How Do You Install It on cPanel?

What is CSF Firewall?

CSF Firewall is short for ConfigServer Security & Firewall. It is a Linux firewall that manages iptables rules from one configuration file and watches for failed login attempts. You will most often see it on VPS and dedicated servers that run cPanel and WHM.

In plain terms, CSF decides which ports on your server accept connections. It also ships with a helper service called LFD, which spots brute-force style behavior and blocks the offending IP address.

We are a digital marketing and web team, not a hosting company. Therefore, we wrote this guide from the official cPanel documentation and from how CSF itself is configured. Our goal is to help you make a sound firewall decision for the server that runs your site or store.

If you manage your own VPS, then you can follow the steps one by one. However, if you use managed hosting, use this article to ask your provider better questions.

In practice, people usually search for CSF in three situations. They inherited a cPanel VPS, they host several client sites on one server, or they run their own store. The common problem is the same in each case: they install a firewall without knowing what it does, or they never install one at all.

This guide starts with an honest look at the tool's status, then moves to installation and settings. Why? Because a project's maintenance status directly affects whether you should choose it.

How does CSF Firewall work with iptables and LFD?

The Linux kernel filters network packets with rules. iptables is the tool that writes those rules, but writing them by hand invites mistakes. CSF builds the rules from the settings in /etc/csf/csf.conf and loads them into iptables for you.

The system has two main parts:

• csf: It manages port lists, allow and deny lists, and loads the rules.
• lfd (Login Failure Daemon): It reads log files, finds suspicious behavior such as repeated failed logins, and blocks the IP.
• List files: csf.allow holds trusted addresses, csf.deny holds blocked ones, and csf.ignore holds addresses that lfd will skip.

As a result, one tool gives you both static port rules and a dynamic reaction to attacks. That combination is why CSF stayed popular on shared and dedicated servers for years.

For example, picture a simple setup. Your server keeps ports 80 and 443 open for the website and one port for SSH. Then CSF closes every other incoming port. If someone guesses SSH passwords again and again, LFD blocks that address after a while.

For instance, think of a doorman in an apartment building. The port list decides which doors are open, and LFD decides how to stop the person who keeps rattling the handle. However, a doorman cannot see a leak inside an apartment, so we cover that limit later.

Is CSF Firewall still safe to use, or has development stopped?

This is the most important question to ask before you install anything. According to community and hosting sources, the original developer, Way to the Web Ltd., ceased operations on August 31, 2025. The code went out under the GPLv3 license before the closure, and the final release is commonly cited as version 15.00.

Then cPanel stepped in. Since February 2026, cPanel has provided its own fork of CSF as the cpanel-csf package. According to the official documentation, this fork receives security and stability updates only.

There is one clear limit. cPanel does not help with CSF configuration or troubleshooting. Therefore, do not expect new features, and use the software on purpose, with care.

Source: cPanel documentation, how to install CSF.

What should you check before installing CSF Firewall?

If you write firewall rules wrongly, you can lock yourself out of your own server. So prepare the ground first:

1. Make sure you have root SSH access.
2. Check whether your provider's panel offers a VNC or console. If you lock yourself out, that console is your only way back in.
3. Remove firewalld if it runs on the server, because CSF does not work with firewalld.
4. Confirm that your distribution is on the cPanel documentation list: AlmaLinux, CloudLinux, Rocky Linux, or Ubuntu.
5. Take a full backup and know how to restore it.

For backups, read our website backup strategy guide. Also, never start changing security settings on a server without a backup.

Think about timing as well, because bad timing amplifies every mistake. Also, make firewall changes when traffic is low. If you run a store, avoid campaign days and the rush before holidays. A planned maintenance window gives you time to roll back if something breaks.

Finally, write down who needs access to what. Which IP addresses will be trusted, and which services stay open to the internet? This short list speeds up every later decision and makes handover to a colleague easier.

How do you install CSF Firewall on a cPanel and WHM server?

The cPanel documentation tells you to install from the package manager as the root user. On AlmaLinux, CloudLinux, or Rocky Linux, you run this command:

sudo yum install cpanel-csf

On Ubuntu, the command looks like this:

sudo apt install cpanel-csf

After the install, you find the interface in WHM under Home, Plugins, ConfigServer Security & Firewall. You can change settings on that screen or edit the files over SSH.

First, run the commands as root. Because CSF does not work with firewalld, remove firewalld first if it exists. Using the official package manager is safer than downloading a random archive from the internet, since you follow updates through cPanel's repositories.

If you already run legacy version 14.x or 15.00 with automatic updates, the documentation says you move to the cPanel fork on your own. Otherwise, the commands above are enough. To remove it, use yum remove cpanel-csf or apt remove cpanel-csf.

How do you check that CSF Firewall is actually working?

Do not assume everything works just because the install finished. A few quick checks show the real state:

1. csf -v prints the installed version. Compare it with the current version in the cPanel documentation.
2. csf -l lists the loaded iptables rules. An empty list means the firewall is not active.
3. systemctl status lfd tells you whether the lfd service runs.
4. If the plugin screen opens in WHM and reads your settings, the panel integration works.

Then test the application side too. First, open your website, your admin panel, and your email sending from a different network. Because a firewall exists to protect your site, a broken site means the settings are wrong.

Also check that a port you meant to close is really closed. For example, a database port you do not use should not be reachable from outside. Also, test this from a different connection, not from your own network.

Can you install CSF Firewall on a VPS without cPanel?

Technically, community forks and old release archives exist. However, we will not walk through them here, because the only path with an officially verifiable source and maintenance is the package that cPanel publishes.

Outside cPanel, you have these options:

• Use the distribution's own firewall: ufw on Ubuntu, firewalld on the RHEL family.
• Configure nftables directly and keep your rules in version control.
• Use your provider's cloud security group or network firewall.
• Add log-based blocking with Fail2ban.

CSF Firewall is built on iptables. The Linux world, meanwhile, is moving slowly toward nftables. So if you start a fresh setup, treat CSF as one option rather than a must.

For nftables details, see the nftables wiki.

How does TESTING mode keep you from locking yourself out?

The most valuable CSF Firewall feature is its test mode. When TESTING is set to 1 in csf.conf, CSF clears its rules on a timer every few minutes. If a wrong rule shuts you out, your access comes back shortly.

A sample starting point looks like this:

TESTING = "1"
TESTING_INTERVAL = "5"

TESTING_INTERVAL sets how often the clearing job runs, in minutes. After you change settings, reload the rules with csf -r.

First, open a new SSH session and test the connection. If everything works, set TESTING to 0 and restart. If you forget, CSF wipes its rules at intervals, so your firewall does not really run.

So do not skip this step. On a live store, test mode is the only safety net that lets you undo a mistake.

Here is the logic in short: try the rule first, then make it permanent. You put on a seat belt before you drive, and test mode is the seat belt you want on before any change. If several people log in to the server, also record who turned the mode off.

How do you add your own IP address to the allowlist?

Your first job is to add your own address to the allow list. First, find your current address with our IP lookup tool. Then run the following command; the address is a documentation example:

csf -a 203.0.113.25 "office"

This command adds the address to csf.allow and applies the rules. The comment in quotes helps you remember months later what that line was for.

This method is weak if your IP changes, for example on a home or mobile connection. The old address can then pass to someone else. Instead, a safer solution is a VPN or bastion host with a fixed IP, and allowing only that address.

The same tool also shows which network an address belongs to, which helps when you review blocked entries.

What do csf.allow, csf.deny, and csf.ignore do?

Commands like csf -a add lines to these files. You can also edit the files by hand. Write one IP address or network range per line, and leave a comment after the hash sign. A sample layout looks like this:

203.0.113.25 # office
198.51.100.0/24 # shared network

The three files have different jobs:

• csf.allow: Addresses that you always want to pass the firewall.
• csf.deny: Addresses that you block permanently.
• csf.ignore: Addresses that lfd should not watch or block.

If you edited a file by hand, reload the rules with csf -r. Otherwise the change does not apply. Also avoid allowing a wide network range, because everyone in that range then skips the firewall.

Which basic settings in csf.conf matter first?

The file is long, and every setting carries its own explanation. Still, on day one you only need to understand a few lines. So do not try to change everything.

Adapt the values in the table to your own environment. Every server is different, and a number from one tutorial may not suit your traffic.

The default value of each setting can change between versions. Therefore, read the comment in the file before you change a value, and note the old value somewhere. Also keep a copy of the file, so you can restore it with one command.

Many settings can feel overwhelming. However, most of them exist for special cases. In the first week, focus on the port lists, test mode, and your allowed IP list.

How do you edit the TCP_IN and TCP_OUT port lists?

TCP_IN is the list of ports that accept incoming connections from the outside. Also, it is a comma-separated list of numbers. For a small web server, an example list could look like this:

TCP_IN = "22,25,53,80,443,465,587,993,995,2083,2087"

This is only an example, and your services may differ. The rule is simple: close every port you do not use. For example, if the server does not run email, remove the mail ports from the list.

If you changed the SSH port, remember to keep the new port open in the list. That is also the most common reason for a lockout. If you use FTP, you also need to define the passive port range.

Open a port when you need it, not because you might need it someday. Also, every open port enlarges the attack surface. For example, instead of exposing the database port to the internet, let the application connect to the database locally.

After a change, run csf -r and test with a new session. The same logic applies to TCP_OUT, but tightening outgoing traffic can break software updates and payment provider connections. So watch the logs first.

How does LFD block failed login attempts?

First, LFD reads log files. If it sees repeated wrong passwords from the same IP, it adds that address to the firewall. The block can be temporary or permanent. Also, the LF settings in csf.conf set the thresholds.

This is a first defense against password guessing. However, it should never be the only defense. You also need strong passwords, key-based SSH, and two-step verification.

One distinction matters: LFD does not stop the attack, it blocks the attacker's IP address. If the attacker changes address, you need a new block. In short, LFD reduces noise, but it will not stop a determined attacker on its own.

LFD has a side effect too: it can block legitimate users. For example, if someone on your team mistypes a password a few times, their IP can get blocked. So adding your team's fixed addresses to the allowlist is good practice.

After changing settings, restart the lfd service:

systemctl restart lfd

You find the block history in /var/log/lfd.log. If something looks suspicious, look there first.

How do you monitor LFD alerts and logs?

Installing a firewall is only half the job, because the real value comes from watching what happens. LFD can send email notifications about events, and you find the notification settings in csf.conf.

A short weekly routine is enough:

• Look for repeated blocks from the same address.
• Check whether a legitimate user or service got blocked.
• Note any spike in failed SSH and panel logins.
• Write down your own setting changes with the date.

Country-based blocking is possible in CSF; however, use it carefully. In addition, Google states that its crawlers mostly come from IP addresses in the United States. Therefore, blocking the US can end your visibility in search. Customers who travel can also lock themselves out.

How do CONNLIMIT and PORTFLOOD connection limits work?

These two settings limit how many connections one IP address can make at once or in a short time. They help against simple bot floods and brute force.

CONNLIMIT takes port and limit pairs. For example, the value 22;5,80;20 allows at most five concurrent new connections to port 22 and twenty to port 80 from the same IP. PORTFLOOD defines the port, protocol, hit count, and interval in seconds together.

However, be careful here. A modern web page opens several parallel connections from the browser. If many users sit behind one IP, such as an office, a tight limit also cuts off legitimate visitors.

So start with a high limit, check the logs to see what gets blocked, and tighten step by step. Store traffic also rises on campaign days, so set the limit with those days in mind.

What is the difference between CSF, Fail2ban, and ModSecurity?

The three are not rivals, because they work at different layers. The confusion usually comes from the fact that every one of them is described as "blocking attacks".

In other words, CSF guards the door, while ModSecurity inspects what comes through it. Fail2ban and the LFD part of CSF do similar work, so think about overlap before you install both on one server.

We cover Fail2ban and ModSecurity separately in sibling articles, so we do not repeat them here.

Which firewall approach fits which scenario?

First, the right tool depends on how you run your server. The table below is a starting frame based on field experience, not a guarantee.

This table is not a strict recipe, but it points you to the right question. For example, on a single-app Ubuntu server, ufw may be enough instead of CSF. On a busy cPanel server, on the other hand, LFD and the WHM integration offer practical value.

What are the most common CSF mistakes?

In practice, these mistakes show up most:

• Turning off TESTING mode without adding your own IP to the allowlist.
• Changing the SSH port and forgetting to add the new port to TCP_IN.
• Trying to install CSF without removing firewalld.
• Copying every setting from a tutorial without comparing it to your own traffic.
• Blocking search engine bots or payment provider servers by accident.
• Writing IP-based rules behind a CDN that hides the real visitor IP.
• Closing the current session before testing the change in a new one.

A calm test routine and test mode prevent most of these. So use the list as a checklist.

However, two mistakes cost the most. The first is a site behind a CDN or reverse proxy where all visitors appear to come from the same IP. In that case, one block can then cut all traffic. The fix is to confirm that the real visitor address reaches the server.

The second is leaving the firewall silently off. If TESTING stays at 1, the rules get wiped at intervals, and you may not notice for months. So after the install, run csf -l now and then to confirm the rules are loaded.

How can a CSF block affect SEO and sales?

A firewall such as CSF Firewall protects visitors, yet a wrong rule can also shut out visitors and search engines. If you block Googlebot, your pages cannot get crawled. If you block a payment provider's callback address, orders end up incomplete.

Therefore, after you change a rule, check the Search Console crawl stats and your order flow. To confirm that a crawler is genuine, follow Google's guidance: the verifying Googlebot page explains how to check that an IP really belongs to Google.

Consider an example calculation: a store's payment provider sends the order result to your server as a notification. If CSF treats that address as suspicious and blocks it, the customer pays, but the order never shows up in your system. To avoid this, consider allowing the IP ranges that the provider publishes.

Speed and security also connect. A slow site sometimes comes from attack traffic. You can read about the ranking effect in how site speed affects SEO and about the sales effect in ecommerce page speed and sales.

How do you find out why an IP address got blocked?

If a user or service cannot connect, first check whether the IP shows up in CSF. This command searches for rules that match the address:

csf -g 203.0.113.25

The output shows whether the address sits on a block list, why, and whether the block is temporary or permanent. For more detail, read /var/log/lfd.log.

If you decide that the block is wrong, remove it:

csf -dr 203.0.113.25

To block an address on purpose, use csf -d. To lift a temporary block, there is csf -tr. Before every change, check who really owns the address with the whois lookup tool.

In an emergency, csf -x turns the firewall off for a moment, and csf -e turns it back on. So use them only briefly.

Is a firewall such as CSF Firewall enough on its own?

No. A firewall controls the network door, but it does not close holes inside the application. An outdated plugin can still get exploited through port 443, which the firewall leaves open.

Therefore, think in layers:

• Update software, plugins, and themes on a schedule.
• Use a valid SSL certificate; see our SSL certificate and HTTPS security guide.
• Review application weaknesses against the OWASP Top 10 list.
• Keep regular, tested backups.
• Check DNS and SSL status with the DNS lookup and SSL checker tools.

In short, each layer covers a gap in the others. The firewall is only the first link.

When should you not do this yourself and leave it to your hosting provider?

Let us be honest: not every site owner has to manage a firewall. In these cases, leave the job to your provider:

• You use shared hosting, where you have no root access and the firewall belongs to the provider.
• You buy a managed VPS or a managed cPanel service, because changes can affect your support agreement.
• Console access is missing, so a wrong rule makes the server unreachable.
• Your live store cannot afford a planned maintenance window.
• The commands remain unclear to you.

This choice is not a weakness; instead, it is a healthy division of work. We add value for our clients on the web, SEO, and advertising side rather than in server administration. Learning about firewalls is useful. However, you do not have to learn on a live store.

In that case, ask your provider these questions: which firewall do you use, how do you react to attacks, and how fast do you answer a request to lift an IP block? Our guide on how to choose web hosting helps with that decision.

If infrastructure is part of a web project, our web design service can help you clarify the technical requirements together.

What checklist should you follow to set up CSF Firewall?

In short, move calmly and in order:

1. Take a backup and confirm your console access.
2. Remove firewalld if it exists.
3. Install the cpanel-csf package with the official cPanel command.
4. Leave TESTING at 1 and add your own IP to csf.allow.
5. Cut the TCP_IN list down to the ports you actually use.
6. Test the connection in a new session, then set TESTING to 0.
7. Watch the lfd log for a week and fix wrong blocks.
8. Check the site, the payment flow, and Search Console crawling.

CSF Firewall is a tool with a narrow official support scope. Still, if you install it correctly and watch it, it adds a reasonable first defense layer to your server. If you feel unsure, make infrastructure and security decisions together with your provider or a system administrator.