systemd[1]: lfd.service: Failed with result 'signal'.

[BenedICT]

Ever since I try CSF on a new Debian 9.4 server, LFD fails to start.
I first migrated csf.conf and allow and ignore lists etc. from a debian 7 server,
Then also tried a clean install, To no avail. Searches don't bring help either.
Some hits on sendmail requirement? Who still uses sendmail? Seriously. I'm running postfix. Done so for 20 years. Up until now CSF LFD always worked fine.

Code: Select all

root@server:/etc/csf# ./csf.pl --lfd start
root@server:/etc/csf# systemctl status lfd.service
● lfd.service - ConfigServer Firewall & Security - lfd
   Loaded: loaded (/usr/lib/systemd/system/lfd.service; enabled; vendor preset: enabled)
   Active: failed (Result: signal) since Thu 2018-03-22 20:10:09 CET; 2s ago
  Process: 27332 ExecStart=/usr/sbin/lfd (code=exited, status=0/SUCCESS)
 Main PID: 27344 (code=killed, signal=KILL)

Mar 22 20:10:09 server.org systemd[1]: Starting ConfigServer Firewall & Security - lfd...
Mar 22 20:10:09 server.org systemd[1]: Started ConfigServer Firewall & Security - lfd.
Mar 22 20:10:09 server.org systemd[1]: lfd.service: Main process exited, code=killed, status=9/KILL
Mar 22 20:10:09 server.org systemd[1]: lfd.service: Unit entered failed state.
Mar 22 20:10:09 server.org systemd[1]: lfd.service: Failed with result 'signal'.

And I even get this after a clean slate install. Something's up, and it ain't debian or me.
Note that CSF works perfectly fine.

Code: Select all

# ./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

Been trying to fix this for the last 16 hours. Installed fail2ban to mitigate the waste of bandwidth cost generated by bots.

[BenedICT]

Code: Select all

● lfd.service - ConfigServer Firewall & Security - lfd
   Loaded: loaded (/usr/lib/systemd/system/lfd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-03-23 09:47:17 CET; 31s ago
  Process: 4571 ExecStart=/usr/sbin/lfd (code=exited, status=0/SUCCESS)
 Main PID: 4585 (lfd - sleeping)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/lfd.service
           └─4585 lfd - sleeping

Mar 23 09:47:15 servereenbeetje.org systemd[1]: lfd.service: Main process exited, code=killed, status=9/KILL
Mar 23 09:47:15 servereenbeetje.org systemd[1]: Stopped ConfigServer Firewall & Security - lfd.
Mar 23 09:47:15 servereenbeetje.org systemd[1]: lfd.service: Unit entered failed state.
Mar 23 09:47:15 servereenbeetje.org systemd[1]: lfd.service: Failed with result 'signal'.
Mar 23 09:47:15 servereenbeetje.org systemd[1]: Starting ConfigServer Firewall & Security - lfd...
Mar 23 09:47:17 servereenbeetje.org systemd[1]: Started ConfigServer Firewall & Security - lfd.

Still doesn't look entirely the way it should, does it?
In my experience (I'm a CISSP) this is a sign of flaky systemd config.

LFD does send out the ridiculous amount of useless Excessive resource usage emails though. Wonder why you're not putting in a bunch of stuff in csf.pignore and let users comment them out if they really like to waste time on these nonsense emails.
Excessive resource usage: www-data
Seriously? Has any of the CSF LFD devs ever tried scripting based on what a server already has on it? Put your code on github and I'll gladly add such a script. Check for postfix, dovecot, nginx, apache processes etc and then uncomment all their related csf.pignore entries.

[iodisciple]

Did you also try a fresh CSF/LFD installation on a fresh Debian 9.4 installation and build from there? I have several Debian 9.4 servers running (with postfix) and they are all working fine.

[Meeven]

LFD does send out the ridiculous amount of useless Excessive resource usage emails though. Wonder why you're not putting in a bunch of stuff in csf.pignore and let users comment them out if they really like to waste time on these nonsense emails.

I have to concur that this aspect of resource usage emails is probably the most poorly designed part of CSF/LFD. I say that as someone who's been gratefully using CSF on all my cPanel and Ubuntu servers for the past 10 years.

Right at the moment, I am dealing with trying to reclaim space on a 30 GB GSuite mailbox that got filled up with all these CSF messages (about 1.5 million of them).

Despite adding the process executables (shown in the emails from CSF) to csf.pginore and restarting the firewall, these messages continued to be generated, so I just went in and set PT_USERPROC, PT_USERMEM, PT_USERRSS and PT_USERTIME all to "0", removed the lines I had added to csf.pignore and restarted CSF.

Guess what? Those messages still continue to be generated and flood my inbox.

At this stage, I am so frustrated that I am thinking of replacing CSF/LFD with UFW and Fail2Ban, at least on all the Ubuntu servers.

[westial]

Probably late to get listened by this post author but probably my answer will help people with similar doubts and complaints.

Some hits on sendmail requirement? Who still uses sendmail? Seriously. I'm running postfix. Done so for 20 years. Up until now CSF LFD always worked fine.

Postfix always provided "Sendmail" interface for compatibility. See http://www.postfix.org/sendmail.1.html.

Code: Select all

Mar 22 20:10:09 server.org systemd[1]: lfd.service: Failed with result 'signal'.

ConfigServer Firewall fresh install goes with `TESTING = "1"`, so LFD returns exactly this error until TESTING is not set to "1".

[westial]

Seriously? Has any of the CSF LFD devs ever tried scripting based on what a server already has on it? Put your code on github and I'll gladly add such a script. Check for postfix, dovecot, nginx, apache processes etc and then uncomment all their related csf.pignore entries.

You don't need the CSF source code to write a script checking the local processes and automatically configure the csf.pignore file. Please, make me know when you have this script ready, it would be very useful.

Dear CSF developers, thank you very much for this great Firewall (for free) that kept my server safe from more than 10 years right now.

[westial]

LFD does send out the ridiculous amount of useless Excessive resource usage emails though. Wonder why you're not putting in a bunch of stuff in csf.pignore and let users comment them out if they really like to waste time on these nonsense emails.

I have to concur that this aspect of resource usage emails is probably the most poorly designed part of CSF/LFD. I say that as someone who's been gratefully using CSF on all my cPanel and Ubuntu servers for the past 10 years.

Right at the moment, I am dealing with trying to reclaim space on a 30 GB GSuite mailbox that got filled up with all these CSF messages (about 1.5 million of them).

Despite adding the process executables (shown in the emails from CSF) to csf.pginore and restarting the firewall, these messages continued to be generated, so I just went in and set PT_USERPROC, PT_USERMEM, PT_USERRSS and PT_USERTIME all to "0", removed the lines I had added to csf.pignore and restarted CSF.

Guess what? Those messages still continue to be generated and flood my inbox.

At this stage, I am so frustrated that I am thinking of replacing CSF/LFD with UFW and Fail2Ban, at least on all the Ubuntu servers.

Hi there,
probably this persistent alert submission even when the process is in csf.pignore is caused by "deleted" processes. Information about from csf.conf file:

Code: Select all

# lfd will report processes, even if they're listed in csf.pignore, if they're
# tagged as (deleted) by Linux. This information is provided in Linux under
# /proc/PID/exe. A (deleted) process is one that is running a binary that has
# the inode for the file removed from the file system directory. This usually
# happens when the binary has been replaced due to an upgrade for it by the OS
# vendor or another third party (e.g. cPanel). You need to investigate whether
# this is indeed the case to be sure that the original binary has not been
# replaced by a rootkit or is running an exploit.
#
# Note: If a deleted executable process is detected and reported then lfd will
# not report children of the parent (or the parent itself if a child triggered
# the report) if the parent is also a deleted executable process
#
# To stop lfd reporting such process you need to restart the daemon to which it
# belongs and therefore run the process using the replacement binary (presuming
# one exists). This will normally mean running the associated startup script in
# /etc/init.d/
#
# If you do want lfd to report deleted binary processes, set to 1
PT_DELETED = "0"