Installing ConfigServer Firewall (CSF) on Ubuntu 14.04 LTS

CSF.Conf Setting Ideas

Here are a few csf.conf setting ideas that you may want to consider.  Of course, it fully depends upon what your server does.


  • The LF Daemon is the service that will watch certain logs on your server for attempted brute force attacks.  The LF Daemon is basically the same as Fail2Ban.  By setting LF_DAEMON to 1, it enables the feature.  Then you will need to go to the section in the CSF.conf that sets the ban limits (also shown in this post just below)


  • If you run a mail server on your system, I would HIGHLY recommend that you sent the SMTP_BLOCK to 1.  This ensures that only the actual mail service (postfix, exim, etc) has the authority to send out messages to the Internet.  One of our customer’s websites was attacked about a year ago and they were able to upload a script that was able to bypass all of the mail system and send out spam directly to the Internet.  By setting SMTP_BLOCK to 1, it will prevent this from occurring.  Also note to set “SMTP_ALLOWUSER” and “SMTP_ALLOWGROUP” with the user accounts and groups that the mail server actually runs from.


  • Definitely ensure that this is set to “1” to allow your local server to send messages using the loopback connection, especially if you have SMTP_BLOCK set to 1.

SMTP_ALLOWUSER = “<users>”
SMTP_ALLOWGROUP = “<groups>”

  • In our case, we use Exim as our mail system.  On Ubuntu, Exim runs as the “Debian-exim” user /group.  Therefore, the SMTP_ALLOWUSER and SMTP_ALLOWGROUP is set to “Debian-exim” in our case.  If you leave any of the proper users/groups out when you have SMTP_BLOCK set to 1, your mail service itself won’t be able to send outgoing e-mail.


  • Turning on Synflood protection.  If you have a fairly decent server, it won’t take much of any processing usage for this although the csf.conf file says it will slow down IP connections.  I’ve not seen any performance issues when turning this on.  In essence, SYN packets are sent to open a connection to the server – but SYNFLOODs are used to send half-open connections to a server and possibly cause a denial of service (DoS) attack.  Therefore, you can turn on the protection by setting SYNFLOOD to 1.  Then you can set the rate of how many SYN packets you are OK with receiving per second and then a burst rate.  The rate and burst were set to the defaults.

CONNLIMIT = “21;2,25;5,80;20,443;20,587;5”

  • This allows you to set how many connections you want to allow per IP address.  This also helps to prevent attackers that want to try and flood a service on your server.  As an example, I limit only two connections to port 21 (hence the 21;2) from the same IP.  I limit port 25 connections to 5 (25;5) from the same IP and so on.  You will put in the port – a semicolon – then the limit.  Separate each by a comma as noted above.


  • Basically the same as SYNFLOOD as noted above – except this is for UDP floods.


  • I love this.  This is one thing that CSF has over Fail2Ban.  In essence, you can set when you want to “permanantly” ban an IP address after they have attempted several times.  Down further for the settings is the LF blocks setup per service.  Those are temporary bans and you can specify a temporary ban in those spots.  But after someone has been blocked temporarily so many times, it is time to do a more permanent block since they are nothing but trouble.  LF_PERMBLOCK set to 1 enables this feature.  The LF_PERMBLOCK_INTERVAL sets the “permanent” time period.  86400 is 24 hours.
  • LF_PERMBLOCK_COUNT needs a little bit of clarification.  In my case, I have it set to 2.  This means that after someone has been temporarily banned (using the settings for the specific services), the IP address will be banned for the LF_PERMBLOCK_INTERVAL.  However, even though I have it set to 2, it actually is 3.  That is because they will be blocked temporarily two times.  Then on the third time, they will be “permanently” blocked.
  • LF_PERMBLOCK_ALERT is set to 1 – which means I am alerted by e-mail whenever a permanent block goes into effect.


  • This is must like the PERMBLOCK noted above, but this actually will block a network range.  In the event that more than one IP address from the LF_NETBLOCK_CLASS is attempting to infiltrate your system, CSF will actually do a “permanent” block (set to the LF_NETBLOCK_INTERVAL) for the entire range of IP addresses.  I would definitely keep the LF_NETBLOCK_CLASS set to C – which means it will block and monitor only a class C network (254 addresses).  If you set this any higher, you are blocking thousands of IPs.


  • I would recommend keeping the LF_TRIGGER to 0 unless you are OK with setting the same trigger amount for each of your services.  In essence, this trigger can be set to “5” if desired – which means that after five failed attempts against any of the services you want to monitor – that IP address will be blocked temporarily.  By setting this to 0, it gives you more granular control over how many failed attempts you want to set on a per-service basis.  In my case, I wanted to block FTP after three attempts – and everything else after 5.


  • Again, I set this to 0 so I can specifically set the triggers for each service.  If you want to have the same trigger amount for each service, then this value can be set to the time period you want to temporary ban the IP address that is attempting access to your server.  As an example, set it to 300 seconds if you want to temporarily ban for 5 minutes.


  • I am debating about changing this.  If this is set to 0, that means the IP address that has undergone a temporary ban is only banned from that service (such as POP, IMAP, web, SMTP, etc).  If set to 1, then that means the IP address will be blocked temporarily from accessing anything on the server.

LF_SSHD = “5”
LF_SSHD_PERM = “300”

  • Here is where I specifically say that upon five failed attempts (LF_SSHD), the IP address will be temporarily banned for 300 seconds (LF_SSHD_PERM).  The “PERM” in the variable name is misleading – because it is not a permanent block – only temporary.  Of course, that temporary time period is set based on what you want.  With my systems, I set it to 300 seconds (five minutes) and then because I have the LF_PERMBLOCK set to 1 (noted above), they will be fully blocked for a full 24 hours (LF_PERMBLOCK_INTERVAL) after three temporary bans.

LF_FTPD = “3”
LF_FTPD_PERM = “300”
LF_POP3D = “5”
LF_POP3D_PERM = “300”
LF_IMAPD = “5”

  • The settings above are just like the LF_SSHD.  The first one will tell CSF / LFD how many invalid attempts to allow before temporarily blocking the IP address.  Make note of LF_HTACCESS and LF_MODSEC.  I have some custom Regex rules listed below that will help you watch for bots attempting to access password-protected directories.  This is a HUGE benefit to us.

HTACCESS_LOG = “Log_Locations”
MODSEC_LOG = “Log_Locations”

  • One neat thing you can do with CSF is use wildcards (*) in the log file names.  Why?  Well, because if you do web hosting and keep separate log files for each of your customers, you will want to be sure that CSF / LFD scans those logs for any kind of unauthorized access attempts (401 errors).  So, let’s say that you have a setup like this:
    • Customer base path is /var/www/<user-login>
    • Logs are kept in /var/www/<user-login/logs
    • Access log is named access.log
    • Error log is named error.log
  • Well, you can set HTACCESS_LOG = “/var/www/*/logs/error.log” and MODSEC_LOG = “/var/www/*/logs/access.log” to scan every log file in all user directories.  Note the asterisk (*) where the <user-login> is.  Very beneficial.

Speaking of MODSEC logs, that leads me into the next topic of Custom Regex.

Custom Regex Files

This is where things really can help out if you have non-standard services that you also want to monitor connections for.  As an example, I have ensured that some of our other web programs that allow for logins are logged into a file that is already monitored – and then regex items were made to check those for invalid logins.  That way if attempts are made against those systems, they can also be blocked there.

A Regex helper can be found here:

That allows you to put in the log line that you want to try and match – and then a box above that to fill in the regex.  You will see that it was filled out with a log line I used along with the regex noted below in the first example.

Blocking 401 Unauthorized Attempts Against A Web Server

The big thing that I think will help out many people is to sense whenever someone is attempting to access a password-protected directory on your web server (think wp-admin for WordPress or administrator for Joomla).  When an invalid attempt is made, it throws a “401” error in the access log.  So, ensure that you have MODSEC_LOG set to monitor the log.  Then you will want to add this to your /etc/csf/ file:

     if (($config{LF_MODSEC}) and ($globlogs{MODSEC_LOG}{$lgfile}) and ($line =~ /(\S+)(.*) 401 (.*)/)) {
 $ip = $1; $acc = ""; $ip =~ s/^::ffff://;
 if (&checkip($ip)) {return ("mod_security triggered by","$ip|$acc","mod_security")} else {return}

In essence, you can see the “401” in the first line.  That Regex will find any lines in the MODSEC_LOG file(s) that have a 401 in them (spaces on both sides to ensure it isn’t in an actual URL) and will temporary block the IP based on your LF_MODSEC setting (or LF_TRIGGER if you didn’t want to set the services independently with different trigger values).

Additional Regexes For ProFTPD

The Regexes included with CSF don’t fully match all of the items for ProFTPD logins.  Therefore, I made a couple of extra Regexes to ensure they worked right.  The first one will find any line that has “Login failed” in it.  Of course, if the login failed, you want it to be noted.  The Regex built in with CSF is more restrictive than this one:

     if (($config{LF_FTPD}) and ($globlogs{FTPD_LOG}{$lgfile}) and ($line =~ /(\S+\S+\s+\d+\s+\S+) (\S+) proftpd\[\d+\] (\S+) \([^\[]+\[(\S+)\]\): USER (\S+) \(Login failed\)(.*)/)) {
 $ip = $4; $acc = $5; $ip =~ s/^::ffff://; $acc =~ s/:$//g;
 if (&checkip($ip)) {return ("Failed FTP login from","$ip|$acc","ftpd")} else {return}

Here is another Regex that will find and block any that have SECURITY VIOLATION in it. This is done if someone tries to login to FTP using a root account:

     if (($config{LF_FTPD}) and ($globlogs{FTPD_LOG}{$lgfile}) and ($line =~ /(\S+\S+\s+\d+\s+\S+) (\S+) proftpd\[\d+\] (\S+) \([^\[]+\[(\S+)\]\): SECURITY VIOLATION: (.*)/)) {
 $ip = $4; $acc = $5; $ip =~ s/^::ffff://; $acc =~ s/:$//g;
 if (&checkip($ip)) {return ("Failed FTP login from","$ip|$acc","ftpd")} else {return}

Additional Regex for Dovecot IMAP

The built-in IMAP Regex into CSF didn’t work for me – maybe it is because of how I have logging setup, I’m not sure.  So I had to modify the regex to simply look for any line that has “failed” in it:

     if (($config{LF_POP3D}) and ($globlogs{POP3D_LOG}{$lgfile}) and ($line =~ /(.*)imap-login(.*)failed(.*)rip=(\S+)\,(.*)/)) {
 $ip = $4; $acc = ""; $ip =~ s/^::ffff://;
 if (&checkip($ip)) {return ("Failed IMAP login from","$ip|$acc","imapd")} else {return}
Mirror of:

7 thoughts on “Installing ConfigServer Firewall (CSF) on Ubuntu 14.04 LTS

  1. CFS is not listed as supported and tested on Ubuntu 14. Did you had any compatibility or bugs issues with it?

    • No problem so far. I still have to do some penetration testing to see it in action, but it has protected my 14.04 fully until now against several LAN attacks and ssh/http bruteforce logins.

      • Thanks! Had the confirmation on Ubuntuforum too that it work flawlessly on 14.04.

  2. Hi I’m having trouble rate limiting icmp requests with latest CSF on Ubuntu Server 14.04.1 LTS. It does not seem to work at all. Does it work for you?

  3. Hi!
    Thank you for your reply. CSF would suit my needs perfectly if it just worked.

    There is no VPS or router. Can there be issues when getting a public IP-address directly from my ISP (via DHCP)? And UFW should be disabled by default, right? I disabled it anyways :) Are there any other services and or deamons that could interfere?

    It’s a clean install of Ubuntu 14.04.1 LTS with LAMP. Iptables seems correct, but I will look more into that, and ICMP can be disabled but not rate limited (either in or out!).

    The test seems alright:
    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

    • Sorry mate, I’m out of ideas. Try your luck on UbuntuForums []. I personally think that ICMP isn’t that much a threat and can be skipped – unless you have a case history on your hands.

      PS: try playing with Advanced Allow/Deny Filters a little more.


Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s