@bulent,
You will find that Plesk Firewall extension will behave (on the one hand) differently in time, in the sense that previous (proper) firewall rules will not work as expected anymore and (on the other hand) differently across servers, in the sense that identical servers with identical firewall setups can have different issues.
In essence, it is not the Plesk Firewall extension that is the root cause of the problem, it is only
contributing to an already existing problem.
In most cases, a simple reboot (from the command line) is required to get a "clean slate and proper starting point" for further analysis of iptables firewall rules.
However, this is not the best approach to start with.
As
@IgorG tried to explain, it is a process of elimination to find the proper root cause of the problem.
On a VPS, it is quite common that iptables is "overworked" and, as a result, does not add iptables rulesets properly: if this is the case, than it is almost certain that the Plesk Firewall extension is (also) not able to add the intended firewall rules properly.
On a dedicated server, the number of rules in iptables can be huge, so there often is not a problem when adding firewall rules, unless your machine has to work very hard due to a hack attempt (which in most cases is brute forcing and/or mail server related attacks).
On a cloud based VM............well, that is an entire different story.
In almost every case, there is Fail2Ban filling up iptables...........and that is the
first thing to start with, by simply (in chronological order of execution)
1 - blocking bad IPs via Nginx, as opposed to adding them into iptables: create a custom action in /etc/fail2ban/action.d,
2 - adding bad IPs to the /etc/hosts.deny file, as opposed to adding them into iptables: create a custom action in /etc/fail2ban/action.d,
3 - creating whitelists for nginx (to be placed in /etc/nginx/conf.d) and the entire server (to be placed in /etc/hosts.allow),
4 - (optionally) creating blacklists for postfix, as opposed to adding them into iptables,
and the result will be that the iptables chains associated with f2b are reduced, allowing you to (safely) take a
second step: deactivating fail2ban jails.
After these two steps, you will have a fairly clean iptables ruleset, without too much f2b-<name> chains.
You can inspect the iptables before and after the before mentioned steps with the command:
iptables -L -n --line-numbers
A check
before you apply the two steps is desirable, since the before mentioned command gives you an idea which of the Fail2Ban jails and iptables are pretty useless.
After that, you can proceed with the third step: just translate simple Fail2Ban rules and other intended firewall rules to Plesk Firewall extension.
This way, you have more control and a more simple iptables ruleset.
At this moment, I am pretty convinced that all of the above will help you with your issue.
However, there is
one thing to notice:
it can be the case that you have to refresh the rules added with Plesk Firewall extension.
Simply stated, it is my personal experience that Plesk Firewall extension has been behaving a bit odd in the last couple of weeks, but a simple change is often enough to get the whole thing working properly again: adding an IP, saving the changes, removing the IP again, saving the changes.........this seems to work.
Nevertheless, you can be pretty sure that you have to clean up iptables, as commonly filled up improperly by Fail2Ban.
I hope the above helps a (tiny) bit......
Regards........
Facebook
Twitter
A man, like yourself, who frequently helps people here on the forum. 