Configserver firewall csf csfpost.sh not executed after (cpanel or csf) update

nickgr

• March 20, 2025 14:57

Hello,

I'm experiencing an issue where the custom firewall script csfpost.sh is no longer executed automatically, likely after the recent cPanel or CSF update on March 19, 2025.

Environment:

cPanel servers running CloudLinux 8 & 9
Imunify360 installed
ConfigServer Firewall (CSF) / LFD enabled
The script (/etc/csf/csfpost.sh) contains custom iptables rules, for example, to allow outgoing connections from port 2525 for user ID 1004:

vi /etc/csf/csfpost.sh

#!/bin/bash
/usr/sbin/iptables -I OUTPUT -p tcp -m owner --uid-owner 1004 --dport 2525 -j ACCEPT

After running csf -ra

csf -ra
.
.
Running /usr/local/csf/bin/csfpost.sh
Checking ipsets consistent  <--- noticeable delay of about 3 seconds white running csfpost.sh
Completed
Script finished
.
.

 

However, checking the firewall rules afterward (csf -l | grep 2525) returns nothing:

[root@ns325 csf]# csf -l | grep 2525
[root@ns325 csf]# (empty result)

Yet, if I manually run the script, the rule applies successfully:

[root@ns325 csf]# sh csfpost.sh
[root@ns325 csf]# csf -l | grep 2525
1   0   0 ACCEPT  tcp  --  *   *   0.0.0.0/0   0.0.0.0/0   owner UID match 1004 tcp dpt:2525

Has anyone experienced this or have any idea what might be causing the issue?

Thanks in advance for any assistance!

• 

  quietFinn

  • March 20, 2025 16:12

  Do you have the script in 2 locations, /usr/local/csf/bin/csfpost.sh and /etc/csf/csfpost.sh ?
  If Yes are the scripts the same?

  In /etc/csf/readme.txt it says:

  
  Note: The scripts can alternatively be placed in /etc/csf/. If a script is found in
  both locations (/etc/csf/ and /usr/local/csf/bin/) then only the script in
  /usr/local/csf/bin/ will be executed.
  
  

   

   

  0
• 

  nickgr

  • March 20, 2025 18:47

  
  Hello @quietFinn,

  Thank you for bringing this to my attention.

  I had never previously used or examined the file /usr/local/csf/bin/csfpost.sh, as I assumed it was simply a symlink or wrapper for /etc/csf/csfpost.sh.

  However, after your suggestion, I checked and discovered that the file /usr/local/csf/bin/csfpost.sh was created today, likely by the latest Imunify360 update.

  
   stat csfpost.sh
    File: csfpost.sh
    Size: 124             Blocks: 8          IO Block: 4096   regular file
  Device: 903h/2307d      Inode: 114427982   Links: 1
  Access: (0700/-rwx------)  Uid: (    0/    root)   Gid: (    0/    root)
  Access: 2025-03-20 00:21:47.872050919 +0200
  Modify: 2025-03-20 00:21:36.856045413 +0200
  Change: 2025-03-20 00:21:47.870050918 +0200
   Birth: 2025-03-20 00:21:36.856045413 +0200

  
  Here's the current content of this file:

  
  cat /usr/local/csf/bin/csfpost.sh
  #!/bin/sh
  /opt/imunify360/venv/bin/python3 /opt/imunify360/venv/share/imunify360/scripts/rules_checker.py ipsets-consistent

  
  As a workaround, I've appended the following line at the end of /usr/local/csf/bin/csfpost.sh to ensure both scripts are executed:

  /bin/sh /etc/csf/csfpost.sh

  This seems to resolve the issue for now, although I'm concerned the next Imunify360 update might overwrite my changes.

  Thanks again for your help!

  0

Please sign in to leave a comment.