Stop exposing servers to hackers and change [csf.error] -----> csf -x ; csf -e ; instead!

[AdminWonder]

Hello,

Suddenly csf stopped working because one table in iptables was missing. Then, it created a file "csf.error" and poured in some smart detection text to tell the admin, why and how he could be smarter. My server remained exposed for more than six hours. I could only notice when I tried to block an offending IP in the cluster and the affected csf installation refused to connect.

Then, csf was itself not smart enough to inform the admin by an email that all the hackers are now (due to a sudden problem) invited to identify entire structure of the server on ports, which they did not know earlier.

If a table is missing and the restart cannot be made properly, then it should - BY DEFAULT - flush what it in iptables, do csf -x and then do csf e. That's it. There is no point to create a smart error file named "csf.error". What could be logical is to have an email generated and send it to the admin, while it should restart with the csf -x ; csf -e ; anyway.

We know that there are hundreds of port scans going on. If csf stops working like now, then all servers are put to a risk. The advantage with this system is that the server shall be more secured and shall not be exposed to hackers, who wants to know details on ports.

[AdminWonder]

The reported error was reproduced again and the file has following contents:

Error: FASTSTART: (SMTP Block IPv4) [ -I SMTPOUTPUT -p tcp -m multiport --dports 25,465,587 -m owner --uid-owner 0 -j ACCEPT] [iptables-restore v1.8.4 (nf_tables): Chain 'LOGDROPOUT' does not exist]. Try restarting csf with FASTSTART disabled, at line 5781 in /usr/sbin/csf

Now if the chain LOGDROPOUT does not exists, then it is very much wrong to stop the firewall from starting.

This logically means that if one chan is missing, it should - BY DEFAULT - disable the FASTSTART option temporarily, create the chain and then once again enable it for later use.