Error with CSF Centos 8.1 installation

Okay. Some progress I disabled those 3 blocklists mentioned in my previous message.
Now, after a reboot (and starting LFD manually) LFD is running.

However "ConfigServer Security & Firewall" is still awefully slow compared to a system running with CentOS 7.x.

Very strange. When I click it, it takes about a minute or more to load completely, though the server load is extremely low. Also memory usage is low.
The hardware for the test setup is fast, as I have used it also for testing DA with CentOS 7.x. I have no clue what is going on here. All other functions are fast, except for "ConfigServer Security & Firewall".

Will try a setup on different hardware just to make this is not the issue. However the blocklist issue was not active on DA servers with CentOS 7.x.

Regards



//edit 1
Even running "csf -v" from the CLI takes ages. While it takes less than second on a DA with CentOS 7.x install.


//edit 2
Okay after running "iptables -F" the command "csf -v" seems a bit quicker. Maybe some worthwhile side information. Our servers are created in OpenVZ 7 containers. And we have a sh*t list of wanna be hackers which we add on the hardware node as "route add -net XXXX.0/24 gw 127.0.0.1 lo".

This never was an issue before (same as with the use of blocklists on the server self), but now it appears to hog the performance of CSF for some reason. I find this very strange as we didn't experience this with DA with CentOS 7.x or even with CentOS 6.x. I must admin it's a big list of IP-ranges, but still and again; we didn't have these issues before. And also you should be able to use the CSF blocklists, right?

I will redo the complete server once again and experiment a bit more.
 
Last edited:
sudo systemctl stop nftables
sudo systemctl disable nftables
sudo systemctl mask --now nftables

sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask --now firewalld
That looks good.

You state that there might be an issue with LFD and that might be the case.
I read from your quote:
Code:
CGroup: /system.slice/lfd.service
          ├─2067 /usr/bin/perl /usr/sbin/lfd
          └─2074 /sbin/iptables --wait -L PREROUTING -t raw

So I checked the same on my servers and it reads:
Code:
Main PID: 296561 (lfd - sleeping)
    Tasks: 2 (limit: 203485)
   Memory: 48.3M
   CGroup: /system.slice/lfd.service
           ├─296561 lfd - sleeping                                                                                                                   >
           └─296570 lfd Cluster Server                                                                                                               >
So yes I use more memory, but I don't have that /usr/bin/perl there and I don't see that PREROUTING output.
Is that PREROUTING output coming from some custom configuration of CSF?

I think those Dshield lines will still work, when you have the correct once. But I would advise to first install CSF like with the install-directadmin.sh from CSF. Then have it running by default and see if it works correctly then.

I'm not sure if the build in bruteforce option from DA is maybe disturbing stuff.
I also presume you used the check line to see if all works:
perl /usr/local/csf/bin/csftest.pl

Edit: Removed something which I discovered was correct.
 
Hi Richard,

Well I have been testing multiple times. No clue where the issues come from to be honest.
I have included a log file, which shows several issues. Mainly with "RULE_APPEND" failed.

Maybe it gives some insight. I also included a screenshot of LFD acting weird (messages in DA).
It's driving me nuts. The only "solution" is to run iptables -F followed by iptables -X. After that I can start LFD as well, however after some time the issues are back.

Currently we cannot use DirectAdmin with CentOS 8.x. Though DA with CentOS 7.x (or even CentOS 6.x) never ever caused these issues... Strange.

I also ran " perl /usr/local/csf/bin/csftest.pl", but no issues:
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

Regards
 

Attachments

  • directadmin_issues.txt
    6.7 KB · Views: 75
  • lfd_crazy.jpg
    lfd_crazy.jpg
    241.6 KB · Views: 69
I will create support ticket with DA. Hopefully they can find the cause for the issues, as I have no idea anymore.

Sidenote; I don't have any issues when setting up a Plesk based server with CentOS 8.x whatsoever. It only happend with DirectAdmin with CentOS 8.x (and also we didn't have any issues with previous CentOS versions along with DA).

Strange...
 
It's good to create support with DA. Because I don't use nftables (neither are you) but these lines for localhost are creating an issue, for the rest it looks as LFD starts fine:
Code:
iptables v1.8.4 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain INPUT
INVALID  tcp opt -- in !lo out *  0.0.0.0/0  -> 0.0.0.0/0 
iptables v1.8.4 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain OUTPUT
INVALID  tcp opt -- in * out !lo  0.0.0.0/0  -> 0.0.0.0/0 
DROP  all opt    in * out *  ::/0  -> ::/0 
ip6tables v1.8.4 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain INPUT
INVALID  tcp opt    in !lo out *  ::/0  -> ::/0 
ip6tables v1.8.4 (nf_tables):  RULE_INSERT failed (Invalid argument): rule in chain OUTPUT

I don't know where these "rule_insert" for localhost are coming from. If you can find this I guess LFD will be working fine.
It looks like iptables and ip6tables is called seperately there some how. If I restart csf, I never see that. I do see several lines for localhost in all policy's when checking with the iptables -L command.

Just to be sure, have a look at /etc/sysconfig if there are iptables and iptables-config files. Maybe something is in there.
This is my /etc/sysconfig/iptables file:
Code:
# Generated by iptables-save v1.8.4 on Sat Sep  5 00:42:53 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Sat Sep  5 00:42:53 2020
# Generated by iptables-save v1.8.4 on Sat Sep  5 00:42:53 2020
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Sat Sep  5 00:42:53 2020
# Generated by iptables-save v1.8.4 on Sat Sep  5 00:42:53 2020
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sat Sep  5 00:42:53 2020
# Generated by iptables-save v1.8.4 on Sat Sep  5 00:42:53 2020
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

If nothing is blocking (or starting) there or in iptables-config, then I hope the ticket can help you.
Please let us know the cause afterwards because this is a very interesting issue.
 
I could be you dont have ipset installed?
  • ipset support for large IP lists
Diff:
dnf install ipset

what does
Code:
perl /usr/local/csf/bin/csftest.pl
give

Perl Modules
============

While most should be installed on a standard perl installation the following
may need to be installed manually:

# On rpm based systems:
yum install perl-libwww-perl.noarch perl-LWP-Protocol-https.noarch perl-GDGraph
 
@Richard G

To be honest I have no clue either. It's very weird.
So far DA support has no idea as well. Seems not to be going well. :(

Apparently the iptables config was wiped by support. So the config was empty.
I am now re-creating the server again. To check /etc/sysconfig/iptables after a fresh setup.
Can you also list, as reference, your /etc/sysconfig/ip6tables?

As soon as the server has been setup, I will check the "default" for the server.

So far support is looking into it (I guess), however there is no solution for the issue so far.
Apparently now the advice is to install the server without CSF. I don't fancy that; running a server without a firewall.

I don't understand why DirectAdmin on CentOS 8.x is causing issues for us as;
  1. Plesk with CentOS 8.x is running perfectly; fast and without any issues at all
  2. DirectAdmin on CentOS 7.x (or even CentOS 6.x) never gave any problemens
  3. Alle necessary modules and recommended packages are installed on CentOS 8.x for DA
Server has enough resources and doesn't show issues at all.

I hope a solution is provided by DirectAdmin support soon, as we advice new customers who want CentOS 8.x to take a Plesk based server instead. Luckily nobody minds so far. Maybe cause we give a discount on the Plesk license for the trouble.

* crossing fingers *


@bdacus01

Thank you for your reply.
We install always ipset and it shows it as installed:
ipset -v
ipset v7.1, protocol version: 7

So that's not it either. Thanks for thinking along though.
 
Update.

I re-installed DirectAdmin on CentOS 8.x. However the "/etc/sysconfig/iptables" is completely empty. Very strange?
I also checked "/etc/sysconfig/ip6tables" and this one did have entries:

# sample configuration for ip6tables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -d fe80::/64 -p udp -m udp --dport 546 -m state --state NEW -j ACCEPT
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
COMMIT

I also checked the CentOS 8.x with Plesk version for reference. But also this "/etc/sysconfig/iptables" is completely empty and the "ip6tables" has the same settings. Hmmmm....

So I decided to check "/etc/sysconfig/iptables" on a DirectAdmin server with CentOS 7.x for reference. This one did have antries:

# Generated by iptables-save v1.4.21 on Thu Nov 19 17:47:46 2020
*security
:INPUT ACCEPT [363:517085]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [214:12898]
COMMIT
# Completed on Thu Nov 19 17:47:46 2020
# Generated by iptables-save v1.4.21 on Thu Nov 19 17:47:46 2020
*raw
:pREROUTING ACCEPT [363:517085]
:OUTPUT ACCEPT [214:12898]
COMMIT
# Completed on Thu Nov 19 17:47:46 2020
# Generated by iptables-save v1.4.21 on Thu Nov 19 17:47:46 2020
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2:188]
-A INPUT -p tcp -m tcp --dport 8060 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2703 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 35000:35999 -j ACCEPT
COMMIT
# Completed on Thu Nov 19 17:47:46 2020
# Generated by iptables-save v1.4.21 on Thu Nov 19 17:47:46 2020
*nat
:pREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:pOSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Thu Nov 19 17:47:46 2020
# Generated by iptables-save v1.4.21 on Thu Nov 19 17:47:46 2020
*mangle
:pREROUTING ACCEPT [4:669]
:INPUT ACCEPT [4:669]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5:1645]
:pOSTROUTING ACCEPT [5:1645]
COMMIT
# Completed on Thu Nov 19 17:47:46 2020

However on these servers (with CentOS 7.x) iptables/ip6tables are running as a service (Active: active (exited)).
I am gonna test it a bit more, by enabling iptables / ip6tables once and disable it again, so those config are created. Maybe stupid thinking, but I am going to try anyways. I will also try a few other things.

Will report back later.
 
So far DA support has no idea as well. Seems not to be going well.:(
How do you know, you had a ticket response?

Can you also list, as reference, your /etc/sysconfig/ip6tables?
Ofcourse I can. That the iptables config file is wiped should be no problem.
Normally all policy's only should read ACCEPT so if that is happening with the server starting up without csf active, then it should be fine.
Maybe it can also differ from how the dataceter puts in the image, not sure about that though.

This is my ip6tables-config file on the Centos 8 servers.

Code:
# Load additional ip6tables modules (nat helpers)
#   Default: -none-
# Space separated list of nat helpers (e.g. 'ip_nat_ftp ip_nat_irc'), which
# are loaded after the firewall rules are applied. Options for the helpers are
# stored in /etc/modprobe.conf.
IP6TABLES_MODULES=""

# Save current firewall rules on stop.
#   Value: yes|no,  default: no
# Saves all firewall rules to /etc/sysconfig/ip6tables if firewall gets stopped
# (e.g. on system shutdown).
IP6TABLES_SAVE_ON_STOP="no"

# Save current firewall rules on restart.
#   Value: yes|no,  default: no
# Saves all firewall rules to /etc/sysconfig/ip6tables if firewall gets
# restarted.
IP6TABLES_SAVE_ON_RESTART="no"

# Save (and restore) rule and chain counter.
#   Value: yes|no,  default: no
# Save counters for rules and chains to /etc/sysconfig/ip6tables if
# 'service ip6tables save' is called or on stop or restart if SAVE_ON_STOP or
# SAVE_ON_RESTART is enabled.
IP6TABLES_SAVE_COUNTER="no"

# Numeric status output
#   Value: yes|no,  default: yes
# Print IP addresses and port numbers in numeric format in the status output.
IP6TABLES_STATUS_NUMERIC="yes"

# Verbose status output
#   Value: yes|no,  default: yes
# Print info about the number of packets and bytes plus the "input-" and
# "outputdevice" in the status output.
IP6TABLES_STATUS_VERBOSE="no"

# Status output with numbered lines
#   Value: yes|no,  default: yes
# Print a counter/number for every rule in the status output.
IP6TABLES_STATUS_LINENUMBERS="yes"

# Reload sysctl settings on start and restart
#   Default: -none-
# Space separated list of sysctl items which are to be reloaded on start.
# List items will be matched by fgrep.
#IP6TABLES_SYSCTL_LOAD_LIST=".nf_conntrack .bridge-nf"

# Set wait option for ip6tables-restore calls in seconds
#   Default: 600
# Set to 0 to deactivate the wait.
#IP6TABLES_RESTORE_WAIT=600

# Set wait interval option for ip6tables-restore calls in microseconds
#   Default: 1000000
# Set to 100000 to try to get the lock every 100000 microseconds, 10 times a
# second.
# Only usable with IP6TABLES_RESTORE_WAIT > 0
#IP6TABLES_RESTORE_WAIT_INTERVAL=1000000

I don't use ipv6 yet, but I did not touch this file so this is the original I have.

Now the odd thing. On anoter Centos 8 server, I have this iptables-config file, but also a ip6tables file in that directory.
The ip6tables-config is the same. The ip6tables file reads this:
Code:
# sample configuration for ip6tables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -d fe80::/64 -p udp -m udp --dport 546 -m state --state NEW -j ACCEPT
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
COMMIT
# Generated by webmin
*mangle
COMMIT
# Completed
# Generated by webmin
*nat
COMMIT
# Completed
So that also looks the same as yours.
 
yum install ip6tables
Hmm on an fresh installed Centos 8 box it is not possible to install this:

Last metadata expiration check: 0:02:45 ago on Sat Jan 23 12:56:59 2021.
No match for argument: ip6tables
Error: Unable to find a match: ip6tables
 
I can confirm this:
CSF don't work with OpenVZ 7 and Centos 8 / Oracle Centos 8 / Centos 8 Stream (tested them all)

But it does work with Centos 7 :)

NOTICE: We are deprecating support for Virtuozzo/OpenVZ servers. Future releases will not take into consideration those platforms which have become onerous to support. The software application may continue to work but support and functionality is no longer guaranteed
 

NOTICE: We are deprecating support for Virtuozzo/OpenVZ servers. Future releases will not take into consideration those platforms which have become onerous to support. The software application may continue to work but support and functionality is no longer guaranteed
Its good to have special advice and test support from DirectAdmin directly for OpenVZ/Virtouzoo user, to enabled or disabled CSF/LFD regarding the error and slow open the CSF page.
Because this feature is really important for security and not supported by the CSF dev soon, i think
 
Last edited:
Back
Top