• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Plesk FW interface and iptables

Franco

Regular Pleskian
Hello,
the saga on this continues, but I have some new information. To summarize, after system reboot, the iptables rules are not kept and some default version is loaded (causing websites to be unavailable, 504 nginx timeout). I am obliged to go to the Plesk FW runles, disable them and re-enable them to have my sites running again.

What I know is that /etc/sysconfig/iptables and /etc/sysconfig/iptables.save are correct. Why then the system restores something else at reboot?

What about ip6tables? At the moment it's a very short list of rules and there's no corresponding ip6tables.save. Should it be aligned and how? I am quite ignorant about that, so any help is greatly appreciated.

Franco

Config: Plesk 12.5, CentOs 6.8, fail2ban, mod-security
 
Hi Igor, that problem and associated patch seem to apply to centos 7, not 6. But perhaps I should try and prevent fail2ban from loading at system start. How would I do that, by the way?
 
How would I do that, by the way?
With chkconfig utility, for example:

Code:
# chkconfig --list fail2ban
fail2ban        0:off   1:off   2:off   3:on    4:on    5:on    6:off

# chkconfig --level 345 fail2ban off

# chkconfig --list fail2ban
fail2ban        0:off   1:off   2:off   3:off   4:off   5:off   6:off
 
Not starting fail2ban at startup did not solve it (iptables reset still happening), but I found out that fail2ban, by the look of it, tries to reset the iptables at shutdown. If there's a reboot now fail2ban logs a bunch of errors indicating it tries to intervene in the iptables. Could that be a trace to follow? How to prevent that?
Here's an initial list of errors:

The system is going down for halt NOW!
2016-07-13 00:09:33,111 fail2ban.server [4504]: INFO Stopping all jails
2016-07-13 00:09:33,961 fail2ban.action [4504]: ERROR iptables -D INPUT -p tcp -j f2b-default
iptables -F f2b-default
iptables -X f2b-default -- stdout: ''
2016-07-13 00:09:33,962 fail2ban.action [4504]: ERROR iptables -D INPUT -p tcp -j f2b-default
iptables -F f2b-default
iptables -X f2b-default -- stderr: 'iptables: Too many links.\n'
2016-07-13 00:09:33,963 fail2ban.action [4504]: ERROR iptables -D INPUT -p tcp -j f2b-default
iptables -F f2b-default
iptables -X f2b-default -- returned 1
2016-07-13 00:09:33,963 fail2ban.actions [4504]: ERROR Failed to stop jail 'sshd' action 'iptables-allports': Error stopping action
2016-07-13 00:09:33,971 fail2ban.jail [4504]: INFO Jail 'sshd' stopped
2016-07-13 00:09:34,976 fail2ban.action [4504]: ERROR iptables -D INPUT -p tcp -j f2b-default
iptables -F f2b-default
iptables -X f2b-default -- stdout: ''
2016-07-13 00:09:34,987 fail2ban.action [4504]: ERROR iptables -D INPUT -p tcp -j f2b-default
iptables -F f2b-default
iptables -X f2b-default -- stderr: 'iptables: Too many links.\n'
2016-07-13 00:09:34,992 fail2ban.action [4504]: ERROR iptables -D INPUT -p tcp -j f2b-default
iptables -F f2b-default
iptables -X f2b-default -- returned 1
2016-07-13 00:09:34,994 fail2ban.actions [4504]: ERROR Failed to stop jail 'apache-auth' action 'iptables-allports': Error stopping action

etc...
 
Hi Franco,

tries to reset the iptables at shutdown.
Pls. be informed, that Fail2Ban does that on EVERY stop/start/restart procedure for its very own iptables settings and chains. If you experience issues for Fail2Ban here, consider to restart it again, so that Fail2Ban is able to rebuild its chains.
Fail2Ban does not modify/delete other existent FW - rules.
 
Fail2ban has been restarted several times. If those errors are normal, then what is causing my iptables to be reset at an initial state that misses important elements and which causes my 504 nginx? It's systematic, not random, it has been going on from the beginning of this VPS, more than 2 years ago. Ever couple of months I resume investigations and open a new ticket with some new information (this time targeting fail2ban), but so far no progress. At every reboot or system crash my iptables go bad. What else could I be looking at? Is there a workaround like running a Plesk FW rule set automatically at or after startup?
 
Fail2ban is not the culprit, it was disabled and the issue still occured meanwhile. Last night there was a kernel crash and the system rebooted (it could have been at VMWare level, not sure). Anyway, I suspect my iptables were set to initial state during reboot by:

- kernel: ip_tables: (C) 2000-2006 Netfilter Core Team

If that's the case, how can I avoid it or have it superseeded automatically by my Plesk FW rules?
 
Further to this, I found out I have at least 2 files run at startup in /etc/init-d, one called firewall (with bad rules) and another one called psa-firewall, which executes a script (I guess using the Plesk interface rules). Shall I disable firewall? Why Plesk does not disable it when its rules are ON?
I also suspect that psa-fiewall does not run at all at reboot 'cause I saw a couple of messages of the kind "plesk is not running" or so... Maybe it tries to run, but too early on?
 
Back
Top