How to Install CSF (Config Server Firewall) on Debian 12

Unlock robust network security for your Debian 12 self-hosting environment with Config Server Firewall (CSF). This comprehensive tutorial guides tech-savvy users through every step of installing, configuring, and managing CSF, a powerful stateful packet inspection firewall based on IPTables. From essential dependency setup to advanced IP blocking and Web UI management, you’ll gain the knowledge to harden your server against common threats. Dive in to secure your Debian 12 server and ensure your self-hosted applications run safely and efficiently.

CSF or Config Server Firewall is a Stateful Packet Inspection (SPI) firewall based on IPtables and Perl. It provides a daemon process that monitors your services for failure and authentication, and also offers Web UI integration for web-based server management, such as Webmin, cPanel, and DirectAdmin.

In this tutorial, we’ll walk you through the installation process of CSF (Config Server Firewall) on the Debian 12 server. You will also learn the basic configuration of CSF, blocking IP addresses using two different methods, and setting up CSF Web UI for ease of management and monitoring.

Note: CSF Firewall was officially shut down in August 2025. You may consider using its fork, Sentinel Firewall, or other robust Debian 12 firewall solutions as alternatives for long-term security. This guide, however, focuses on CSF for current implementations.

Prerequisites for CSF Installation

To begin with this tutorial, ensure you have the following:

• A Debian 12 server.
• A non-root user with administrator privileges.

Preparing Your Debian 12 System for CSF

Before installing CSF, it’s crucial to prepare your system by installing necessary dependencies and ensuring no conflicting firewalls are active. CSF relies on packages like Perl and iptables. If another firewall like UFW (Uncomplicated Firewall) is running, it must be disabled.

To get started, update your Debian repository to ensure you’re working with the latest package information:

sudo apt update

Once the repository is updated, install the essential dependencies for CSF using the command below:

sudo apt install libio-socket-inet6-perl libsocket6-perl sendmail dnsutils unzip libio-socket-ssl-perl libcrypt-ssleay-perl git perl iptables libnet-libidn-perl libwww-perl liblwp-protocol-https-perl libgd-graph-perl

Type Y and press ENTER to proceed with the installation.

Finally, you must disable UFW if it’s active on your Debian server. CSF, by default, uses IPTables as its primary firewall and packet filter, making UFW redundant and potentially conflicting:

sudo ufw disable

Downloading and Installing CSF Manually

In this section, you will download and install CSF (Config Server Firewall) directly from the source. This ensures you have the latest version ready for deployment.

Download the CSF source code using the wget command. This will fetch the csf.tgz archive:

wget http://download.configserver.com/csf.tgz

Now, extract the csf.tgz file using the tar command. The CSF source code will be available in the newly created csf directory:

sudo tar -xvzf csf.tgz

Next, navigate into the csf directory and execute the install.sh script to commence the installation process:

cd csf; sh install.sh

During the installation, you should see output indicating the progress. Once finished, you’ll receive an ‘Installation Completed’ message.

With CSF installed, verify its functionality using the test script:

perl /usr/local/csf/bin/csftest.pl

Ensure the output shows “OK” for each feature test, confirming your system meets all CSF requirements.

Lastly, confirm the CSF binary location and version:

which csf
csf -v

The output will show CSF v14.20 (or similar) installed in /usr/sbin/csf.

Configuring CSF for Optimal Server Security

After successfully installing CSF, it’s time to customize its settings to match your server security needs. The main CSF configuration file, csf.conf, is located in the /etc/csf directory.

Use the nano editor to open the CSF configuration file:

sudo nano /etc/csf/csf.conf

Allowing Essential Traffic via CSF

Within the csf.conf file, locate the TCP_IN, TCP_OUT, UDP_IN, and UDP_OUT options. Here, you’ll define which ports are allowed for incoming and outgoing traffic. Tailor these to your specific self-hosting services (e.g., SSH, HTTP/S, Mail):

# Allow incoming TCP ports
TCP_IN = "20,21,22,25,53,853,80,110,143,443,465,587,993,995"
# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,53,853,80,110,113,443,587,993,995"
# Allow incoming UDP ports
UDP_IN = "20,21,53,853,80,443"
# Allow outgoing UDP ports
# To allow outgoing traceroute add 33434:33523 to this list
UDP_OUT = "20,21,53,853,113,123"

• TCP_IN: Specifies allowed incoming TCP ports (e.g., 22 for SSH, 80 for HTTP, 443 for HTTPS).
• TCP_OUT: Defines allowed outgoing TCP ports.
• UDP_IN: For incoming UDP traffic (e.g., 53 for DNS).
• UDP_OUT: For outgoing UDP traffic.

Managing Ping (ICMP) Requests

Control whether your server responds to or sends Ping (ICMP) requests. While disabling incoming Ping can obscure your server, it might interfere with external monitoring services. ICMP_IN = "1" allows incoming pings, and ICMP_OUT = "1" allows outgoing pings.

# Allow incoming PING. Disabling PING will likely break external uptime
# monitoring
ICMP_IN = "1"
...
# Allow outgoing PING
# Unless there is a specific reason, this option should NOT be disabled as it
# could break OS functionality
ICMP_OUT = "1"

Enabling SYN Flood Protection

Activate SYN flood protection only when needed, particularly against Denial of Service (DoS) attacks. This feature configures IPTables to mitigate TCP SYN packet floods.

################################################################################ SECTION:Port Flood Settings################################################################################ Enable SYN Flood Protection. This option configures iptables to offer some# protection from tcp SYN packet DOS attempts. ...
SYNFLOOD = "0"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Change SYNFLOOD = "0" to SYNFLOOD = "1" to enable. Adjust SYNFLOOD_RATE and SYNFLOOD_BURST based on your server’s capacity and traffic patterns.

Limiting Concurrent Connections

The CONNLIMIT option allows you to restrict the number of concurrent connections for specific ports, offering further protection against DoS and resource abuse. The format is PORT;LIMIT. For example, 22;5 limits SSH to 5 concurrent connections.

# Connection Limit Protection. This option configures iptables to offer more# protection from DOS attacks against specific ports. It can also be used as a# way to simply limit resource usage by IP address to specific server services.# Note: Run /etc/csf/csftest.pl to check whether this option will function on# this server
CONNLIMIT = "22;5,21;10"

Finalizing Configuration: Disabling Testing Mode and Restricting Syslog

Once your configurations are complete and tested, disable CSF’s testing mode and restrict access to rsyslog sockets for enhanced security.

# lfd will not start while this is enabled
TESTING = "0"
...
# 0 = Allow those options listed above to be used and configured
# 1 = Disable all the options listed above and prevent them from being used
# 2 = Disable only alerts about this feature and do nothing else
# 3 = Restrict syslog/rsyslog access to RESTRICT_SYSLOG_GROUP ** RECOMMENDED **
RESTRICT_SYSLOG = "3"

Change TESTING = "1" to TESTING = "0". Set RESTRICT_SYSLOG = "3" as recommended. Save the file and exit the editor.

Testing and Starting CSF Services

Before fully deploying CSF, verify your configuration to catch any errors that could lead to connectivity issues.

Run the csf -v command to check your configuration. A proper configuration will display the CSF version, while incorrect settings will show detailed error messages:

csf -v

Next, start both the csf and lfd (Login Failure Daemon) services:

sudo systemctl start csf lfd

Important: If CSF service is running, you will be disconnected automatically from the server. This is a normal security measure. Re-log in to your server.

Verify that both csf and lfd services are active and running:

sudo systemctl status csf lfd

You should see both services indicated as ‘active (running)’.

Blocking IP Addresses with CSF for Enhanced Security

CSF provides powerful features for blocking unwanted traffic, crucial for maintaining server security in a self-hosting environment. You can block IPs using predefined lists or by geographical location.

Blocking IP Addresses via IP Block Lists

Leverage community-sourced threat intelligence by enabling IP block lists in CSF. These lists automatically block known malicious IPs.

Open the default IP block list configuration /etc/csf/csf.blocklists:

sudo nano /etc/csf/csf.blocklists

Uncomment lines for block lists like Spamhaus to enable them. For example:

# Spamhaus Don't Route Or Peer List (DROP)
# Details: http://www.spamhaus.org/drop/
SPAMDROP|86400|0|http://www.spamhaus.org/drop/drop.txt
# Spamhaus IPv6 Don't Route Or Peer List (DROPv6)
# Details: http://www.spamhaus.org/drop/
SPAMDROPV6|86400|0|https://www.spamhaus.org/drop/dropv6.txt
# Spamhaus Extended DROP List (EDROP)
# Details: http://www.spamhaus.org/drop/
SPAMEDROP|86400|0|http://www.spamhaus.org/drop/edrop.txt

Save and exit the editor. Here’s what the options mean:

• SPAMDROP: The name of the block list, used as an IPTables chain name (max 25 uppercase characters).
• 86400: Refresh interval (in seconds) for downloading and renewing IP addresses.
• 0: Maximum IP addresses to use from the list (0 means all IPs).
• URL: The download URL for the block list.

Unique Tip: Regularly review and update your chosen block lists. While automated, some lists can occasionally block legitimate IPs. Combining blocklists with other CSF features like connection limiting creates a robust defense.

Blocking IP Addresses via GeoIP

GeoIP blocking allows you to restrict incoming traffic from specific countries, a useful feature for targeted attacks or regional access policies.

Open the main CSF configuration /etc/csf/csf.conf again:

sudo nano /etc/csf/csf.conf

Find the CC_DENY and CC_ALLOW parameters to configure country-based blocking:

# Each option is a comma-separated list of CC's, e.g. "US,GB,DE"
CC_DENY = "RU,CN"
CC_ALLOW = "US,GB,DE,NL,SG"

By default, CSF uses databases from db-ip, ipdeny, and iptoasn. You can switch to the MaxMind GeoIP database by changing CC_SRC to "1" and providing your MaxMind license key in MM_LICENSE_KEY:

# MaxMind License Key:
MM_LICENSE_KEY = ""
...
# Set the following to your preferred source:
# "1" - MaxMind
# "2" - db-ip, ipdeny, iptoasn
# The default is "2" on new installations of csf, or set to "1" to use the
# MaxMind databases after obtaining a license key
CC_SRC = "1"

Save and exit the editor. Verify your CSF configuration:

sudo csf -v

Then, restart both csf and lfd services to apply the GeoIP changes:

sudo csf -ra

You should see output indicating the restart. Finally, confirm both services are running:

sudo systemctl status csf lfd

Enabling CSF Web UI for Easy Management

For convenient monitoring and management of your CSF firewall via a web browser, you can enable the CSF Web UI.

Open the CSF configuration file once more:

sudo nano /etc/csf/csf.conf

Change the UI option to "1" to enable the Web UI. Critically, adjust UI_PORT, UI_IP, UI_USER, and UI_PASS with your desired secure details. Remember to choose a strong, unique username and password.

## 1 to enable, 0 to disable
UI = "1"
...
# Do NOT enable access to this port in TCP_IN, instead only allow trusted IPs
# to the port using Advanced Allow Filters (see readme.txt)
UI_PORT = "1048"
...
# If the server is configured for IPv6 but the IP to bind to is IPv4, then the
# IP address MUST use the IPv6 representation. For example, 1.2.3.4 must use
# ::ffff:1.2.3.4
## Leave blank to bind to all IP addresses on the server
UI_IP = "127.0.0.1"
...
# This should be a secure, hard to guess username
## This must be changed from the default
UI_USER = "alice"
...
# numbers and non-alphanumeric characters
## This must be changed from the default
UI_PASS = "passw0rd"

Security Tip: It is highly recommended to bind UI_IP to 127.0.0.1 and access it via an SSH tunnel, or, if directly exposed, only whitelist specific trusted IPs to UI_PORT using CSF’s advanced allow filters, rather than adding UI_PORT to TCP_IN.

Save the file and exit the editor.

Now, find your public IP address (the IP you’ll be connecting from):

curl https://ipinfo.io/

Add your public IP address to the /etc/csf/csf.allow and /etc/csf/ui/ui.allow configurations. This step is crucial for whitelisting your IP and granting you access to the CSF Web UI and the server:

Example entry in /etc/csf/csf.allow and /etc/csf/ui/ui.allow:

# single ip
192.168.5.1
# subnet
192.168.5.0/24

After that, run the command below to verify the CSF configuration and restart both the csf and lfd services:

sudo csf -v
sudo csf -ra

Next, verify the list of whitelisted IP addresses on CSF. Look for the IPTables chains ALLOWIN and ALLOWOUT; you should see your whitelisted IP addresses there:

sudo csf -l

Finally, open your web browser and visit your server’s IP address followed by the CSF Web UI port (e.g., https://your_server_ip:1048). If your configuration is successful, you should see the CSF login page.

Input your configured admin username and password, then click ENTER. You should then see the CSF dashboard, offering a centralized view for managing your self-hosting firewall.

Conclusion

Congratulations! You’ve successfully installed and configured CSF (Config Server Firewall) on your Debian 12 server. This journey has equipped you with essential skills for bolstering your server security, including allowing specific traffic, managing ICMP requests, implementing SYN flood protection, and limiting concurrent connections.

Beyond basic setup, you’ve mastered advanced blocking techniques using IP block lists and GeoIP, alongside enabling the CSF Web UI for intuitive management. Your Debian 12 server is now significantly more resilient, ensuring your self-hosted applications are well-protected against a wide array of network threats.

FAQ

Question 1: What is CSF, and why is it important for self-hosting on Debian 12?

Answer 1: CSF (Config Server Firewall) is a powerful, configurable firewall that uses IPTables and Perl to provide Stateful Packet Inspection (SPI) for Linux servers. For self-hosting on Debian 12, CSF is crucial because it acts as your server’s first line of defense against cyber threats. It monitors services for failures and authentication issues, blocks malicious IP addresses, limits connections to prevent DDoS attacks, and allows granular control over incoming and outgoing network traffic. This robust protection ensures the stability, security, and availability of your self-hosted applications and data.

Question 2: Given that CSF Firewall is being shut down in August 2025, what are the recommended alternatives for Debian 12?

Answer 2: With CSF’s official shutdown, users should transition to alternative firewall solutions. The article mentions Sentinel Firewall as a direct fork of CSF, which aims to continue its legacy. Other robust alternatives for Debian 12 include:

1. UFW (Uncomplicated Firewall): While simpler, it’s an excellent choice for basic firewall needs and integrates well with Debian’s systemd. It’s often used as a frontend for IPTables.
2. Firewalld: A dynamic firewall manager that supports network zones and offers both a command-line utility and a graphical interface. It’s common in Red Hat-based systems but can be installed on Debian.
3. Direct IPTables Configuration: For advanced users, directly managing IPTables rules offers the highest level of control, though it requires a deeper understanding of network filtering.

When choosing, consider your technical comfort, the complexity of your self-hosting setup, and the specific security features you require.

Question 3: How can I ensure my CSF configuration is secure and optimal for my self-hosted applications?

Answer 3: To ensure your CSF configuration is secure and optimized for your self-hosted applications:

1. Principle of Least Privilege: Only open ports (TCP_IN, UDP_IN) that are absolutely necessary for your applications to function. Close all other ports.
2. Regularly Review Logs: Monitor CSF’s logs (/var/log/lfd.log and /var/log/messages or syslog) for blocked attempts, login failures, and other security events. This helps identify ongoing threats and fine-tune your rules.
3. Whitelisting for Access: For sensitive services like SSH or the CSF Web UI, avoid opening them globally. Instead, use csf.allow to whitelist only your specific IP addresses or trusted networks.
4. Strong Passwords for Web UI: If you enable the CSF Web UI, ensure it’s protected with a very strong, unique password and ideally accessed only via an SSH tunnel or from whitelisted IPs.
5. Stay Updated: Keep your Debian 12 system and CSF itself (or its alternatives) updated to benefit from the latest security patches and features.

Read the original article