CSF

An Introduction to the CSF/LFD Firewall

This guide is not meant to be a comprehensive guide for CSF/LFD usage. It is well documented via csf.conf and readme.txt that accompanies the installation if you need that depth of information. The intent of this guide is to quickly introduce the most important commands & features as it pertains to DirectAdmin firewall management.

The first thing you should do after installation of CSF is ensure that you will be able to receive the notifications. By default, lfd will send emails from the root forwarder if it is configured: /root/.forward If not, edit /etc/csf/csf.conf and set LF_ALERT_TO to your preferred email address and restart csf/lfd.

Common CSF/LFD CLI Commands

Command	Example	Purpose
csf -g IP	`csf -g 1.2.3.4`	Search for an IP in iptables.
csf -d IP	`csf -d 1.2.3.4`	Deny an IP permanently.
csf -dr IP	`csf -dr 1.2.3.4`	Remove a permanent block against the specified IP.
csf -tr IP	`csf -tr 1.2.3.4`	Remove an IP from the temporary IP ban or allow lists.
csf -trd IP	`csf -trd 1.2.3.4`	Remove an IP from the temporary IP ban list only.
csf -tra IP	`csf -tra 1.2.3.4`	Remove an IP from the temporary IP allow list only.
csf -t	`csf -t`	Display the most recent temporary rules.
csf -a IP	`csf -a 1.2.3.4`	Whitelist an IP.
csf -ta IP	`csf -ta 1.2.3.4`	Temporarily whitelist an IP for 3600 seconds (default)
csf -ta IP 1d	`csf -ta 1.2.3.4 1d`	Temporarily whitelist an IP for 1 day.
csf -ar IP	`csf -ar 1.2.3.4`	Remove the temporarily allowed IP.
csf -r	`csf -r`	Restart CSF.
csf -lfd action	`csf -lfd status`	Actions for the LFD daemon (includes stop, start, restart, & status).
csf -ra	`csf -ra`	Restart all (restart both csf & lfd). Use this option after editing csf.conf.
csf -e	`csf -e`	Enable the firewall.
csf -x	`csf -x`	Disable the firewall.
csf -f	`csf -f`	Stop/Flush iptables.
csf -s	`csf -s`	Start the firewall rules.
csf -tf	`csf -tf`	Flush all temporary rules.
csf -df	`csf -df`	Flush all deny rules.
csf -l	`csf -l`	Show the IPv4 configuration.
csf -l6	`csf -l6`	Show the IPv6 configuration.
csf -v	`csf -v`	Show csf version.
csf -h	`csf -h`	Help.
csf -c	`csf -c`	Check for updates to csf but do not upgrade.
csf -u	`csf -u`	Update.
csf -uf	`csf -uf`	Force update.
csf -i IP	`csf -i 1.2.3.4`	Get an IP's information (country of origin & hostname/ptr

There are many, many more commands, but those above are most commonly used on a daily basis. You can see what other possible commands exist via csf -h.

Allowing an IP vs Ignoring an IP

There is a difference between ignoring and allowing an IP in csf.conf. Allowing, or whitelisting an IP has the result of that IP being able to bypass any closed ports on the server. An allowed IP can still be blocked by LFD, the Login Failure Daemon. If you wish for LFD to completely ignore an IP, you may have it ignored by adding it to the ignore file like so (be sure to replace 1.2.3.4 with the IP you actually intend to ignore): echo "1.2.3.4" >> /etc/csf/csf.ignore ; csf -ra If you wish for all allowed IPs to be ignored automatically, you may enable IGNORE_ALLOW, where lfd will ignore IP addresses listed in the csf.allow file and not block them. If you choose to ignore IPs, you should be aware of the security implications of this. Consider all devices in addition to yours that is attached to the network that is being ignored. Are they secure? Updated often? Running a firewall? Utilizing strong passwords and 2FA?

Commonly Used Files

File	Purpose
/etc/csf/csf.conf	The main configuration file.
/etc/csf/csf.pignore	The process/user/command ignore file for ignoring legitimate processes. Eg., user:_rspamd. Regex is supported. A custom CustomBuild pignore file also exists, but CB won't overwrite /etc/csf/csf.pignore.
/etc/csf/csf.ignore	The CIDR/IP ignore file.
/etc/csf/csf.allow	List of allowed (whitelisted) IPs.
/etc/csf/csf.deny	List of denied (blocked) IPs.
/var/lib/csf/csf.tempallow	List of temporarily allowed IPs.
/var/lib/csf/csf.tempban	List of temporarily blocked IPs.
/var/lib/csf/csf.tempip	List of temporary blocks

Logs & Log entries

Log	Purpose
/etc/csf/readme.txt	Read this file and the /etc/csf/csf.conf file for comprehensive documentation of the firewall's features.
/var/log/lfd.log	Check this log for firewall activity.
/var/log/messages or /var/lib/csf/stats/iptables_log	Check here for information such as port blocking activity and synflood attacks.
/var/lib/csf/backup/	Pre- upgrade backups of the csf.conf file will be stored here.

SMTP Blocking

Block outgoing SMTP for all users except for root, exim, and mailman by forcing scripts to use the sendmail binary instead of socket access. If you need to allow local connections to port 25 for webmail or for scripts, for example, you may enable SMTP_ALLOWLOCAL by setting it to '1'. If you need to allow certain users SMTP access only, you can use a comma-delimited list of allowed usernames in the SMTP_ALLOWUSER option.

It is recommended to use ALLOWUSER over SMTP_BLOCK = "0" to limit SMTP abuse as much as possible while still allowing users' sites to send emails via script (password resets, contact emails, etc).

Integrations with other Security Features

BFM

Please also be sure to reference our BruteForce Monitor documentation as well for information on how to use this together with DirectAdmin's BruteForce Monitor, BFM.

ModSecurity

You can also enable failure detection of repeated Apache mod_security rule triggers via the LF_MODSEC* settings in /etc/csf/csf.conf, though you must configure the modsecurity log location correctly via MODSEC_LOG. The log location changes depending on your webserver and php handler: https://docs.directadmin.com/webservices/apache/modsecurity.html#modsecurity-log-locationsopen in new window Note: There have been reports, though, of this feature not working as intended on DirectAdmin serversopen in new window. If you experience this, you can rely on BFM to scan ModSecurity logs for you: https://www.directadmin.com/features.php?id=2861open in new window

Country Code Blocking (BE CAREFUL)!

CC_DENY & CC_ALLOW options allow for the denial or allowance of entire countries' IP addresses. These settings aren't recommended except for very rare cases as having too many blocks can overload the firewall and cause the server to become unresponsive. There is a reason for the default limit of 200 IPs for the csf.deny list, and it is present so that the firewall can continue to respond quickly and function with optimal performance.

RBL checking

Check whether the server's IPs are on blacklists like so: csf --rbl Use the following for nicer output: csf --rbl|lynx -stdin -dump

Public IP Block Lists

You can configure csf to block IPs that exist on public blacklists, such as those maintained by Stop Forum Spam, Spamhaus, Project Honey Pot, TOR's list of Exit Nodes, plus more.

/etc/csf/csf.blocklists - contains additional blocklists you may want to use ; eg Stop Forum Spam

Simply uncomment the line in front of the list you wish to use and restart the firewall. That’s it! Do be careful, though, as some of these lists contain thousands of IPs and can bog down the firewall if you’re not careful and/or lack sufficient resources to use them.

FTP passive ports ip_conntrack

You can enable passive ftp ports by appending the range to TCP_IN/TCP_OUT and restarting csf/lfd: csf -ra.

Per readme.txt:

On servers running Monolithic kernels (e.g. VPS Virtuozzo/OpenVZ and custom
built kernels) ip_conntrack and ip_conntrack_ftp iptables kernel modules may
not be available or fully functional. If this happens, FTP passive mode (PASV)
won't work. In such circumstances you will have to open a hole in your firewall
and configure the FTP server to use that same hole.
 
For example, with pure-ftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/pure-ftpd.conf and then restart pure-ftpd:
PassivePortRange        30000 35000
 
For example, with proftpd you could add the port range 30000:35000 to TCP_IN
and add the following line to /etc/proftpd.conf and then restart proftpd:
PassivePorts    30000 35000

Common Alerts that should not be ignored

You will undoubtedly receive a lot of 'blocked ip' notifications from the firewall if you leave it defaultly configured after installation. It is recommended to disable these alerts (LF_PERMBLOCK_ALERT & LF_EMAIL_ALERT). Bruteforce attacks are expected, and these alerts signify that the firewall is doing its job by blocking such attempts. After the firewall blocks the offending IP, there is really no further action necessary. So, overwhelming your inbox with blocked IP notifications could actually cause one to overlook the more important alerts that do require your attention. Some of these alerts include:

Relay Alerts *spam
- [check] Alert for [ip] *spam
lfd on [hostname]: Script Alert for [path] *spam
Suspicious File Alert *spam possibly, or malware
Suspicious process running under user [user] *possible spam or malware
lfd on [hostname]: Email queue size alert *spam
Account modification alert
System Integrity checking detected a modified system file *possible rootkit, or updated system binaries- check yum log or your OSs equivalent
Port Knocking port opened by [ip]
Excessive resource usage: [user] ([pid])
Login Alerts
- SSH login alert for user [account] from [ip]
- SU login alert - [status] from [from] to [to]
- SUDO login alert - [status] from [from] to [to]
lfd on [hostname]: Excessive processes running under user [user]
lfd on [hostname]: SYSLOG Check Failed

The alerts listed above often indicate the following conditions:

spam
malware
compromised password
broken logging

So it is imperative that they be received to an inbox that is monitored frequently.

The exception is the System Integrity checking alert, as it is often the result of OS updates. However, it is still important to check and confirm just in case.

Ignoring processes & users

CSF/LFD includes a process ignore file for DirectAdmin upon installation. However, if you install other services, you may need to edit the /etc/csf/csf.pignore file to instruct the firewall to treat those processes as legitimate processes and 'ignore' them. This stops the firewall from sending alerts regarding these processes. You can ignore commands (cmd:), executables(exe:), and users(user:). You can also utilize regex with these ignore rules (pcmd:, pexe:, and puser:, respectively).

An example:
You've installed memcached. It runs as the memcached user. You've ensured that it is a current version of memcached configured by default to disable UDP, so it is not vulnerable to the "memcrashed" vulnerability. You can disable the firewall alerts regarding this process like so:
echo 'user:memcached' >> /etc/csf/csf.pignore; csf -ra;

Advanced Allow/Deny Filters

The documentation for this feature from csf is concise and contains several useful examples.

Per /etc/csf/readme.txt:

In /etc/csf/csf.allow and /etc/csf/csf.deny you can add more complex port and
ip filters using the following format (you must specify a port AND an IP
address):

tcp/udp|in/out|s/d=port|s/d=ip|u=uid

Broken down:

tcp/udp  : EITHER tcp OR udp OR icmp protocol
in/out   : EITHER incoming OR outgoing connections
s/d=port : EITHER source OR destination port number (or ICMP type)
           (use a _ for a port range, e.g. 2000_3000)
           (use a , for a multiport list of up to 15 ports, e.g. 22,80,443)
s/d=ip   : EITHER source OR destination IP address
u/g=UID  : EITHER UID or GID of source packet, implies outgoing connections,
           s/d=IP value is ignored

Note: ICMP filtering uses the "port" for s/d=port to set the ICMP type.
Whether you use s or d is not relevant as either simply uses the iptables
--icmp-type option. Use "iptables -p icmp -h" for a list of valid ICMP types.
Only one type per filter is supported

The following examples are taken directly from their /etc/csf/readme.txt as well:

# TCP connections inbound to port 3306 from IP 11.22.33.44
tcp|in|d=3306|s=11.22.33.44

# TCP connections outbound to port 22 on IP 11.22.33.44
tcp|out|d=22|d=11.22.33.44

Note| If omitted, the default protocol is set to "tcp", the default connection
direction is set to "in", so|

# TCP connections inbound to port 22 from IP 44.33.22.11
d=22|s=44.33.22.11

# TCP connections outbound to port 80 from UID 99
tcp|out|d=80||u=99

# ICMP connections inbound for type ping from 44.33.22.11
icmp|in|d=ping|s=44.33.22.11

# TCP connections inbound to port 22 from Dynamic DNS address
# www.configserver.com (for use in csf.dyndns only)
tcp|in|d=22|s=www.configserver.com

# TCP connections inbound to port 22,80,443 from IP 44.33.22.11
d=22,80,443|s=44.33.22.11

One of the most useful use cases for this feature is when opening remote mysql access to port 3306 from a particular IP. Another, when limiting SSH access to your IP only to pass PCI scans or when allowing ICMP only from your monitoring servers.

Cloudflare, CDNs, Remote Firewall Services, and Uptime Monitors.

CSF has a setting CT_LIMIT which defines the simultaneous connections limit for each IP (recommended default is 300 per the csf.conf). If you have a high traffic website whose traffic is proxied from a 3rd party service provider, you'll want to whitelist & ignore their IPs to prevent CT_LIMIT blocks against these services. This becomes even more true the more sites you have on the server using those same services (Cloudflare, for example).

eg:

touch /etc/csf/csf.cloudflare.ips.ignore; for ip in `curl https://www.cloudflare.com/ips-v4 https://www.cloudflare.com/ips-v6`; do csf -a $ip ; echo "$ip" >> /etc/csf/csf.cloudflare.ips.ignore; done; printf "\nInclude /etc/csf/csf.cloudflare.ips.ignore\n" >> /etc/csf/csf.pignore; csf -ra

Do note that mod_remoteip will record the actual visitors' IPs in your webserver logs. However, any abuses that occur, eg., bruteforcing, may need to be blocked at your remote service provider's end due to their IPs being whitelisted in the server. One solution to this would be to configure the Cloudflare firewall integration in CSF.

Cloudflare Firewall Integration

This feature was developed in response to the firewall not being able to block attacking IPs despite the webserver knowing the attacker's actual, proxied IP, thanks to modules like mod_remoteIP. This is because the traffic is coming directly from whitelisted Cloudflare IPs, as far as iptables can tell.

Using the CloudFlare API, this feature can manage these attacking IPs by adding and removing them from the Cloudflare user firewall.

Reference the /etc/csf/readme.txt file for more information on using this feature as there are several limitations and conditions.

Dynamic DNS

CSF/LFD allows one to allow dynamic IPs via the use of hostnames. As the dynamic IP changes, the hostname A record must change to reflect the new IP. The firewall checks for these changes periodically and allows whatever IP the hostname resolves to through the firewall.

This is configured via the /etc/csf/csf.dyndns and DYNDNS* settings in /etc/csf/csf.conf.

There are a few ways one may utilize this feature. For one, you could use this to whitelist 3rd-party service providers that ask you to whitelist them in the firewall but only provide hostnames rather than a list of IPs. Another use would be to whitelist your own computer in the firewall. You would have to have a hostname that resolves to whatever dynamic IP you're using at the time, and it would need to check the IP against the record and update periodically. You can either sign up for a dynamic dns hostname provider service, or you can use DirectAdmin's DNS API for this.

There are several options and scripts that have been provided in the forums and via github (please read the code! We take no responsibility for public code you choose to use that is not provided by us!):

https://forum.directadmin.com/threads/dynamic-dns-option.28226/ https://gist.github.com/DvdGiessen/b4203c69bf0c92f153ea05ed54d804c4 https://github.com/jarkkorantala/daddns https://github.com/WeeJeWel/dyndns https://github.com/eyjohn/DynDnsDA

For a simple example, using https://gist.github.com/DvdGiessen/b4203c69bf0c92f153ea05ed54d804c4open in new window, set this to use a Login Key only allowing DNS actions. Then, use this on your local computer to check your IP and update it in DirectAdmin accordingly. The hostname set there will then resolve to your computer's current IP address and you will then be whitelisted in the firewall via CSF's Dynamic DNS feature.

Messenger Service with DirectAdmin

This feature is very useful for shared hosting environments where you may have several hundred or more users that occasionally get blocked in the firewall for login failures and such. Instead of them opening tickets to have you check why they are unable to access their sites and the server, the server's firewall explicitly informs them of the block when they attempt to connect to their site.

Even better, when coupled with Google Recaptcha, the users can unblock themselves, further saving you another support ticket.

Supported Webservers include Apache, Litespeed, and OpenLitespeed.

The following example uses Apache:

With Captcha:

Create a valid Google ReCAPTCHA (v2) key: https://www.google.com/recaptcha/admin/create

Per csf.conf:
ensure that the option for "Domain Name Validation" is unticked so that the same reCAPTCHA can be used for all domains hosted on the server.

Per https://developers.google.com/recaptcha/docs/domain_validationopen in new window:

However, if your domain or package name list is extremely long, fluid, or unknown, we give you the option to turn off the domain or package name checking on reCAPTCHA's end, and instead check on your server. 
To do so, in the admin console, go to "Advanced Settings" for your key, and untick the "Domain/Package Name Validation" box.

Per admin settings:

Verify the origin of reCAPTCHA solutions
If disabled, you are required to check the hostname on your server when verifying a solution.

In /etc/csf/csf.conf:

change: MESSENGER = "0" to: MESSENGER = "1"
change MESSENGER_HTTPS_CONF = "/etc/httpd/conf/extra/httpd-vhosts.conf" to: MESSENGER_HTTPS_CONF = "/usr/local/directadmin/data/users/*/httpd.conf"
change: MESSENGER_HTTPS_IN = "" to: MESSENGER_HTTPS_IN = "443,2222"
change: MESSENGER_HTML_IN = "80,2082,2095" to: MESSENGER_HTML_IN = "80"
change: MESSENGERV3 = "0" to: MESSENGERV3 = "1"
set up the following by adding your key details: RECAPTCHA_SITEKEY RECAPTCHA_SECRET

create the csf account:
useradd csf -s /bin/false And ensure the proper permissions are set:

chmod 711 /home/csf
chown csf.csf /home/csf

Restart csf/lfd:
csf -ra Do note that firewall restarts may result in a webserver restart with this feature enabled.
Test Ensure all ports (8887, 8888, & 8889) are listening:

netstat -tupln | grep 888

Ensure you are logged in actively via SSH still, block an IP that you can test with, then test what is returned with these commands after blocking the testing IP in the firewall: lynx --dump https://yourhostname.tld:8887 and lynx --dump http://yourhostname.tld:8888

Example output if using recaptcha:

$ lynx --dump http://domain.tld:8888
   [15nBpv m1hngnebTLMxlxQ8W6k4u5zzZHp7+H9AvfLOjcU5DwAAAABJRU5ErkJggg==]

The firewall on this server is blocking your connection.

   You need to contact the server owner or hosting provider for further
   information.

   Your blocked IP address is: XX.XXX.XX.XX

   The hostname of this server is: hostname.tld

   You can try to unblock yourself using ReCAPTCHA:
   (BUTTON) Unblock
   Please note: Not all unblock requests will be successful as it is
   dependent on how your IP address is being blocked. If the unblock fails
   you will need to contact the server owner or hosting provider for
   further information.

Example if not using recaptcha:

[root@host ~]# lynx --dump  http://testing123.tld:8888
   [15nBpv m1hngnebTLMxlxQ8W6k4u5zzZHp7+H9AvfLOjcU5DwAAAABJRU5ErkJggg==]

The firewall on this server is blocking your connection.

   You need to contact the server owner or hosting provider for further
   information.

   Your blocked IP address is: X.X.X.X

   The hostname of this server is: host.domain.tld

Example output if not using recaptcha and using TEXT (v1) output:

[root@host ~]# lynx --dump http://127.0.0.1:8889
   The firewall on this server is blocking your connection. You need to
   contact the server owner or hosting provider for further information.
   Your blocked IP address is: 127.0.0.1 This server's hostname is:
   host.domain.tld
[root@host ~]#

Testing port 8887 will require a domain with a valid SSL, since this is the SSL connections.

Troubleshooting

error: Main Process: Can't locate IO/Socket/INET6.pm in @INC (@INC contains: /usr/local/csf/lib /etc/cxs /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at (eval 40) line 1.
Are the necessary perl modules installed for your chose URLGET setting?
rpm -qa | grep -i "perl-IO-Socket-INET6\|perl-LWP-UserAgent"
For yum-based systems:
yum install perl-IO-Socket-INET6 perl-LWP-UserAgent -y
For apt-based systems:
apt-get install -y libio-socket-inet6-perl perl-LWP-UserAgent
error: (13)Permission denied: [client X.X.X.X:49764] AH00529: /home/csf/public_html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/csf/public_html/' is executable
Fix the permissions accordingly to your PHP handler. For example, check that /home/csf/public_html/.htaccess is set to 644 rather than 600 for php-fpm.
error: If loadApacheConf is set to 1 in /usr/local/lsws/conf/httpd_config.xml when running Litespeed Enterprise, if you aren't getting any SSL listener via netstat, try adding this:
include /var/lib/csf/csf.conf
To this file:
/etc/httpd/conf/extra/httpd-includes.conf
And restart the webserver and CSF/LFD.
error:
CSF cannot restart Litespeed Enterprise.
Edit 'MESSENGERV3RESTART' from "service httpd restart" to "service litespeed restart" in /etc/csf/csf.conf

If you get any other errors while attempting to enable this feature, set DEBUG = "1" in /etc/csf/csf.conf and then restart csf and then lfd to have a log created (/var/log/lfd_messenger.log).

Enabling the CSF/LFD plugin UI for Resellers

Since version 13.01, CSF has supported the limited CSF functionality via UI for resellers (see /etc/csf/changelog.txt).

To use this feature, you need to read and edit /etc/csf/csf.resellers file accordingly.

An example entry is as follows:

reseller:0:USE,UNBLOCK,GREP,ALLOW,DENY

Where 'reseller' would be the reseller name, 0 would indicate that you do not want any email notifications sent to you concerning what actions they've taken in the UI (use 1 if you do want notifications), and then a list of allowable actions.

The possible actions are described as follows:

Action	Description
USE	The reseller can use this facility through DirectAdmin (required)
UNBLOCK	The reseller can use the Quick Unblock feature
GREP	The reseller can use the Search IP feature
ALLOW	The reseller can use the Quick Allow feature
DENY	The reseller can use the Quick Deny feature

As an example, to allow the reseller 'testreseller' access to the UI to search for IPs and to unblock IPs (USE, UNBLOCK, & GREP),but send you a notification of the actions they take (1), you would add the following to the bottom of the file:

testreseller:1:USE,UNBLOCK,GREP

And restart CSF/LFD:

csf -ra

Logging in as the 'testreseller', you should now be able to access the plugin "ConfigServer Security & Firewall" UI, and it will show two options:

Quick Unblock
Search for IP

NOTE: Per csf.resellers:
For security reasons, we recommend only allowing resellers USE, UNBLOCK and GREP.

BLOCK_REPORT

A nice feature for running a custom script following a block. For example, you may want to disable login failure alerts, but still get alerts for blocks that occur in within your target audience, let's say, Singapore. Use this feature to tailor blocking functionality as you see fit.

Per csf readme:

15.Block Reporting
###################
lfd can run an external script when it performs and IP address block following
for example a login failure. This is done by setting the configuration variable
BLOCK_REPORT to a script that must be executable. The following parameters are
passed the the script as arguments:

ARG 1 = IP Address # The IP address or CIDR being blocked
ARG 2 = ports           # Port, comma separated list or * for all ports
ARG 3 = permanent       # 0=temporary block, 1=permanent block
ARG 4 = inout           # Direction of block: in, out or inout
ARG 5 = timeout         # If a temporary block, TTL in seconds, otherwise 0
ARG 6 = message         # Message containing reason for block
ARG 7 = logs            # The logs lines that triggered the block (will contain
                        # line feeds between each log line)
ARG 8 = trigger   # The configuration settings triggered

lfd launches the BLOCK_REPORT in a forked process which terminates after 10
seconds if not completed by then. It runs under the root account, so great care
should be exercised with regard to security of the BLOCK_REPORT script.

So, let's say you want to receive email notifications for all IP blocks for the country Singapore. You'd create a custom script like so:

#!/bin/sh

args=("$@")
if [[ "${args[@]}" =~ "Singapore" ]]; then
  printf "Singapore IP ${args[0]} blocked:\n${args[5]}  \n\nTake appropriate action as necessary.\n\n${args[6]}\n" | mail -v -s "Singapore IP blocked by CSF" root
fi

exit 0;

Save it as /etc/csf/custom.sh and chmod +x /etc/csf/custom.sh. Now, edit the csf.conf to change this:
BLOCK_REPORT = To this:
BLOCK_REPORT = "/etc/csf/custom.sh"

Then restart the firewall:
csf -ra

Now, you will receive a special report when a Singapore IP is blocked. You can take this even further to detect the type of block using the args above, then automatically remove the block using the appropriate command. There are potentially many uses for a feature like this.

Port Knocking

Port knocking is a feature that requires you to hit a certain sequence of ports in a certain time frame before opening a port for you to access.

It can be enabled by setting the time frame limits and the ports to hit in the CSF configuration via the PORTKNOCKING setting in /etc/csf/csf.conf and restarting CSF.

You can then use an alias to knock the sequence of ports you've specified in order to connect to the specified host, "host.name.tld":

So, for example, setting this:

PORTKNOCKING = "22;TCP;30;2;22;222;2222;22222"

Requires that ports 2, 22, 222, 2222, & 22222 are accessed via TCP by you in that sequence before allowing you to access port 22, of which access will be available for 30s before requiring you to repeat the knock.

Setting the following alias in your ~/.bashrc will allow you to just type 'knock' to initiate the port knocking and then subsequently connect to SSH over port 22:

alias knock='nmap -Pn -p T:2,22,222,2222,22222 host.name.tld; ssh root@host.name.tld -p22'

This feature, too, is very useful for maintaining PCI compliance for services that you need to maintain access to but need to keep closed for others.

IP & Port Forwarding/Redirects

You can forward any incoming traffic meant for one IP and one port to another IP and/or port using /etc/csf/csf.redirect.

Per readme.txt:

Port/IP address Redirection
###############################

This feature uses the file /etc/csf/csf.redirect which is a list of port and/or
IP address assignments to direct traffic to alternative ports/IP addresses.

Requirements:
  nat tables
  ipt_DNAT iptables module
  ipt_SNAT iptables module
  ipt_REDIRECT iptables module

The following are the allowed redirection formats

DNAT (redirect from one IP address to a different one):
IPx|*|IPy|*|tcp/udp          - To IPx redirects to IPy
IPx|portA|IPy|portB|tcp/udp  - To IPx to portA redirects to IPy portB

DNAT examples:
192.168.254.62|*|10.0.0.1|*|tcp
192.168.254.62|666|10.0.0.1|25|tcp

REDIRECT (redirect from port to a different one):
IPx|portA|*|portB|tcp/udp    - To IPx to portA redirects to portB
*|portA|*|portB|tcp/udp      - To portA redirects to portB

REDIRECT examples:
*|666|*|25|tcp
192.168.254.60|666|*|25|tcp
192.168.254.4|666|*|25|tcp

Where a port is specified it cannot be a range, only a single port.

All redirections to another IP address will always appear on the destination
server with the source of this server, not the originating IP address.
 
This feature is not intended to be used for routing, NAT, VPN, etc tasks

Note: /proc/sys/net/ipv4/ip_forward must be set to 1 for DNAT connections to
work. csf will set this where it can, but if the kernel value cannot be set
then the DNAT redirection many not work.

So, let's say you've migrated from cPanel to DirectAdmin and would like to forward all attempted connections on ports 2087 and 2083 via your main IP to your main IP port 2222. You could configure this via this rule, where X.X.X.X is your IP:

X.X.X.X|2087|X.X.X.X|2222|tcp

The documentation also suggests that wildcards will work like so:

*|2087|*|2222|tcp

To confirm that the feature will work on your server:

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

You should see output like this:

[root@host1 ~]# /usr/local/csf/bin/csftest.pl 
Testing ip_tables/iptable_filter...OK
Testing ipt_LOG...OK
Testing ipt_multiport/xt_multiport...OK
Testing ipt_REJECT...OK
Testing ipt_state/xt_state...OK
Testing ipt_limit/xt_limit...OK
Testing ipt_recent...OK
Testing xt_connlimit...OK
Testing ipt_owner/xt_owner...OK
Testing iptable_nat/ipt_REDIRECT...OK
Testing iptable_nat/ipt_DNAT...OK

RESULT: csf should function on this server
[root@host1 ~]#

Restart the firewall:

csf -ra

And that should be it! 😃

Directory or File Monitoring

Enabling Directory Watching in DirectAdmin will result in alerts being sent if any non-root owned suspicious files are uploaded to /tmp, /dev/shm, etc.,

Another cool way to use this feature is to configure it to 'watch' a file or directory you've specified by performing MD5 checks against them and notifying you if differences are observed. Use the LF_DIRWATCH_FILE option for this.

Adding your own iptables rules to CSF

Let's say you need to add your own rules to iptables via CSF/LFD. You can accomplish this via their pre/post scripts:

/usr/local/csf/bin/csfpre.sh
and
/usr/local/csf/bin/csfpost.sh

The following paths are also referenced but the above take precedence:

/etc/csf/csfpre.sh
and
/etc/csf/csfpost.sh

Just add your rules there and viola! They will be loaded into iptables upon restart of the firewall.

Conclusion

CSF adds new must-use features often, and we are proud to be able to directly integrate it into the DirectAdmin panel. Of course, the definitive resource for use with the firewall is its own /etc/csf/csf.conf and /etc/csf/readme.txt, so always check these for the latest documentation on CSF/LFD features.

Other features you may be interested in:

IPv6 support
lfd Clustering
Port Flood Protection
UI Skinning and Mobile View (customizing the look of CSF's UI)
Multiple Ethernet Devices Customization (editing the list of ETH devices that rules will be applied to so that some may be skipped, for example)
Global Lists for Allow/Deny (Grab a list of IPs from a URL that you maintain for blocking/allowing those IPs)
URLPROXY (Configure CSF/LFD to use a proxy for HTTP and HTTPS connections)
Connection Tracking (CT_LIMIT: Blocking IPs that exceed the number of simultaneous connections set here)
Port Scan Tracking (If more than PS_DIVERSITY number of different ports are hit (default value of 1) in more than PS_LIMIT times within PS_INTERVAL sections, the IP will be blocked)
User ID Tracking (If a UID generates ma port block logged more than UID_LIMIT times within UID_INTERVAL, an alert is sent.)
Account Creation/Deletion/Modification Alerts
Log Scanner & Summary (Generates an email summary of the log lines of each log listed in /etc/csf/csf.logfiles)
Statistics (Basic system statistics, eg disk, cpu, memory, network, etc usage collected over different time intervals)
Docker Container Communication Settings (to allow Docker containers to communicate through the host)
Custom Log checking (Supports regex. If applying to very busy logs, can bog down csf, so be careful...) See the following for examples:
- https://forum.configserver.com/viewtopic.php?t=7517
- https://forum.directadmin.com/threads/defeating-brute-force-attacks-by-custom-regex-in-csf.53911/

As stated before, this is not an all-inclusive list of all features. You should really reference /etc/csf/csf.conf and /etc/csf/readme.txt for more information! 😃

# CSF

# An Introduction to the CSF/LFD Firewall

# Common CSF/LFD CLI Commands

# Allowing an IP vs Ignoring an IP

# Commonly Used Files

# Logs & Log entries

# SMTP Blocking

# Integrations with other Security Features

# BFM

# ModSecurity

# Country Code Blocking (BE CAREFUL)!

# RBL checking

# Public IP Block Lists

# FTP passive ports ip_conntrack

# Common Alerts that should not be ignored

# Ignoring processes & users

# Advanced Allow/Deny Filters

# Cloudflare, CDNs, Remote Firewall Services, and Uptime Monitors.

# Cloudflare Firewall Integration

# Dynamic DNS

# Messenger Service with DirectAdmin

# Troubleshooting

# Enabling the CSF/LFD plugin UI for Resellers

# BLOCK_REPORT

# Port Knocking

# IP & Port Forwarding/Redirects

# Directory or File Monitoring

# Adding your own iptables rules to CSF

# Conclusion

CSF