ConfigServer Community Forum

Hello Guys !

I got a situation here: I installed a brand new server (CentOs 6.4 x64 - converted to CloudLinux) and after I installed csf firewall and it takes at least 3-5 minutes to restart. I saw that bandmin stops csf to restart very fast. In other servers this never happens and I don't know why. Also another thing is when the server reboots, it tooks a lot (~5 minutes) for bandmin to restart when csf is active. If I uninstall csf, everything works instantly. Bear in mind that server have 40 cores, 128 gb ram and raid 10 enterprise hdd's, so there is not a problem with the specs.

I am looking forward to hearing from you.

Can't help with bandmin as it is a cPanel script, but you can disable csf from running it by setting LF_CPANEL_BANDMIN to 0.

It works !

Thank you for your help.

Sorry to bring up an old thread, but I am having the same problem. I understand bandmin is not part of csf, but I was wondering if others have had this issue and found a solution that didn't involve simply setting LF_CPANEL_BANDMIN to 0?

In my case bandmin is hanging for a little over 30 seconds during the "Restarting bandmin acctboth chains for cPanel" phase and this is enough to trigger warnings and sometimes fail completely when csf is restarted.

If the ForumAdmin could take a few moments to explain what is going wrong with bandmin that caused such a csf setting to even need to be available, I would really appreciate it. I am trying to get it resolved so that I do not have to disable bandmin.

My environment is Virtuozzo but it passes all of csf's tests:

Testing iptables...

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
...Done.

I have also noticed that rules in the csf.deny have a greater impact on bandmin restart times than those in csf.blocklists. This doesn't seem to make sense but I have run tests that show it to be true, at least on the surface.

I restarted csf with everything removed from csf.deny and csf.blocklists. numiptent was around 500. numiptent is a beancounter in VZ that mean "Number of firewall rules". As expected, bandmin restart it was quite fast.

# time /usr/local/bandmin/bandminstart

real 0m1.089s
user 0m0.111s
sys 0m0.830s

Next I added in only the csf.blocklists and restarted csf. numiptent was about 3700. Took about 7 seconds for bandmin to restart:

# time /usr/local/bandmin/bandminstart

real 0m7.084s
user 0m0.348s
sys 0m6.553s

Next I emptied csf.blocklists are restored csf.deny, which holds 2000 IPs and restarted csf. Here is where it gets strange and where I think the core of the issue lies. numiptent is around 4500. And look at how long it takes to restart bandmin:

time /usr/local/bandmin/bandminstart

real 0m34.830s
user 0m0.413s
sys 0m33.877s

numiptent = 3700, 7 seconds to restart bandmin (mainly csf.blocklists rules)
numiptent = 4500, 34 seconds to restart bandmin (mainly csf.deny rules)

Sure, I could lower the number of IPs in csf.deny, but I keep it that high for a reason. If not they rotate out too fast.

I know that the IPs in csf.deny all have a lengthy comment after each one with the reason for the deny. I don't know why that would matter, but you just never know. Could it be something like that?

Anyway, maybe somebody there could think about why this might be.

Thank you.