Whm / Cpanel CSF Firewall CSF vs LFD Allow vs Ignore
Whm / Cpanel CSF Firewall csf.allow csf.deny csf.igno
csf.conf Cpanel CSF Firewall , csf.allow Cpanel CSF Firewall
csf.deny Cpanel CSF Firewall , csf.ignore Cpanel CSF Firewall

These options allow you to easily and quickly control and view csf. All the 
configuration files for csf are in /etc/csf and include:

csf.conf    - the main configuration file, it has helpful comments explaining
          what each option does
csf.allow    - a list of IP's and CIDR addresses that should always be allowed 
          through the firewall
csf.deny    - a list of IP's and CIDR addresses that should never be allowed
          through the firewall
csf.ignore    - a list of IP's and CIDR addresses that lfd should ignore and not
          not block if detected
csf.*ignore    - various ignore files that list files, users, IP's that lfd
          should ignore. See each file for their specific purpose and
csf.conf Cpanel CSF Firewall

nano /etc/csf/csf.conf
csf.allow Cpanel CSF Firewall


nano /etc/csf/csf.allow
csf.deny Cpanel CSF Firewall

nano /etc/csf/csf.deny
csf.ignore Cpanel CSF Firewall


nano /etc/csf/csf.ignore
csf.allow csf.ingnore Cpanel CSF Firewall

whitelist csf lfd
- csf.allow csf ports
- csf.ignore lfd ports
, Static IP

csf.allow csf.ignore

Adding an IP to csf.allow normally opens all ports to that IP address.
Adding an IP to csf.ignore simply allows the IP to be ignored from brute force detection (LFD) without opening up the extra ports.

csf and lfd use different files for whitelisting.
csf.allow is used by csf to construct the iptables rules.
csf.ignore is used by lfd to ignore specified IP addresses if they were to be banned for triggering watched events.
So, you need to list an IP address in both files if you never want it blocked for any reason.
If you always want to whitelist IP's in csf.allow in lfd, then you can enable the option IGNORE_ALLOW in csf.conf and then restart lfd:

CSF LFD Cpanel CSF Firewall

csf Principles

The idea with csf, as with most iptables firewall configurations, is to block
everything and then allow through only those connections that you want. This is
done in iptables by DROPPING all connections in and out of the server on all
protocols. Then allow traffic in and out from existing connections. Then open
ports up in and outgoing for both TCP and UDP individually.

This way we can control exactly what traffic is allowed in and out of the
server and helps protect the server from malicious attack.

In particular it prevents unauthorised access to network daemons that we want
to restrict access by IP address, and also should a service suffer a
compromise, it can help prevent access to compromise networks daemons, a
typical example being a hackers sshd daemon running on a random open port.
Perhaps the greatest of reasons is to help mitigate the effects of suffering a
root compromise where often they only way to take advantage of such a failure
is to open a daemon for the hacker to access the server on. While this won't
prevent root compromises, it can help slow them down enough for you to notice
and react.

Another way that a port filtering firewall can help is when a user level
compromise occurs and a hacker installs DOS tools to effect other servers. A
firewall configured to block outgoing connections except on specific ports can
help prevent DOS attacks from working and make it immediately apparent to you
from the system logs.

csf has been designed to keep this configuration simple, but still flexible
enough to give you options to suit your server environment. Often firewall
scripts can become cumbersome of complex making it impossible to identify where
problems lie and to easily fix them.

To take advantage of kernel logging of iptables dropped connections you should
ensure that kernel logging daemon (klogd) is enabled. Typically, VPS servers
have this disabled and you should check /etc/init.d/syslog and make sure that
any klogd lines are not commented out. If you change the file, remember to

restart syslog.

lfd Principles

One of the best ways to protect the server from inbound attack against network
daemons is to monitor their authentication logs. Invalid login attempts which
happen in a short space of time from the same source can often mean someone is
attempting to brute-force their way into the server, usually by guessing
usernames and passwords and therefore generating authentication and login

lfd can monitor the most commonly abused protocols, SSHD, POP3, IMAP, FTP and
HTTP password protection. Unlike other applications, lfd is a daemon process
that monitors logs continuously and so can react within seconds of detecting
such attempts. It also monitors across protocols, so if attempts are made on
different protocols in a short space of time, all those attempts will be
counted against the threshold.

Once the number of failed login attempts is reached, lfd immediately forks a
sub-process and uses csf to block the offending IP address from both in and
outgoing connections. Stopping the attack in its tracks in a quick and timely
manner. Other applications that use cron job timings to run usually completely
miss brute force attacks as they run usually every 5 minutes or by which time
the attack could be over, or simply biding its time. In the meantime lfd will
have block the offenders IP address.

By running the block and alert email actions in a sub-process, the main daemon
can continue monitoring the logs without delay.

If you want to know when lfd blocks an IP address you can enable the email
alert (which is on by default) and you should watch the log file in