Issue plesk firewall 2.1.5-412 still has problems

[PeterKi]

Server operating system version

Ubuntu 22.04.3 on strato vServer

Plesk version and microupdate number

Plesk Obsidian Web Admin Edition Version 18.0.54 Update #4

I still have problems with the new plesk firewall.
After I set the timeouts in panel.ini to 120s I was able to activate the firewall and iptables -L did show all the rules.
Then I tried to block two IP ranges by adding a block-all rule to deny all incoming ports for 218.92.0.0/24 and 61.177.172.0/24.
With the old firewall, it was very easy to do this.
When I tried to activate my new rule, the firewall came back with the following error:

Failed to apply the firewall configuration.

• I did not receive connectivity confirmation after applying new firewall configuration, then same happened after I reverted to previous configuration. This means that both new and previous configurations were bad. Emergency rollback to configuration without rules was performed. Firewall is now disabled. Fix your rules and try again.

After I had removed the block-all rule, I was able to activate the firewall again.
The new firewall is much worse than the old one.
It is slower, the rule management is worse, and it does not work as properly as before.

 

[Peter Debik]

But you do realize that the issue is caused by a faulty rule, don't you?

 

[PeterKi]

If the rule was faulty, then the rule applet is faulty.
I entered the rule as shown on the attached screenshot, and I do not see anything wrong with it as it follows the given examples.
Also, the original error message said, that it could not revert to the previous configuration, claiming it was bad too.
This obviously was a false message, because the previous configuration did work.
I tried to enter the blocking rule a second time, but this time the "applying firewall configuration" did not come back even after 10 minuters and I was totally locked out of my server.
The only solution was to revert to a server backup to get it accessible again.

 

[Peter Debik]

Please address this to the support team by a ticket. They will be able to help you solve it directly on your server.

 

[Dave W]

Still something funky going on with the firewall extension.

We use ansible to deploy Plesk servers and the firewall application fails on some installs. The same ansible playbook applied in each case, and whilst on most servers it installs everything fine, on some it times out with
Failed to apply the firewall configuration.

• I did not receive connectivity confirmation after applying new firewall configuration, then same happened after I reverted to previous configuration. This means that both new and previous configurations were bad. Emergency rollback to configuration without rules was performed. Firewall is now disabled. Fix your rules and try again

The same playbook and OS in all cases is the same image of AlmaLinux8.
This extension needs to be investigated further as it is not stable.

Dave_W

 

[PeterKi]

Please address this to the support team by a ticket. They will be able to help you solve it directly on your server.

I am on a reseller license from Strato and there is no support from Plesk for this.
Is there a way, how I can still address a ticket to the support team?

The previous plesk firewall extension had worked flawlessly for me for many years, but the new extension is a major fail.

 

[Peter Debik]

If you bought your license from a reseller, your reseller should provide support for you. If the reseller does not provide support, here is an alternative:

https://support.plesk.com/hc/en-us/articles/12388090147095-How-to-get-support-directly-from-Plesk-

 

[Kaspar]

@PeterKi before applying the new Firewall rule changes Plesk shows a dialog which allows you to preview the script which gets used to apply all firewall changed. Could you post the script here for a quick analyses?

 

[Kaspar]

Still something funky going on with the firewall extension.

We use ansible to deploy Plesk servers and the firewall application fails on some installs. The same ansible playbook applied in each case, and whilst on most servers it installs everything fine, on some it times out with
Failed to apply the firewall configuration.

• I did not receive connectivity confirmation after applying new firewall configuration, then same happened after I reverted to previous configuration. This means that both new and previous configurations were bad. Emergency rollback to configuration without rules was performed. Firewall is now disabled. Fix your rules and try again

The same playbook and OS in all cases is the same image of AlmaLinux8.
This extension needs to be investigated further as it is not stable.

Dave_W

Out of curiosity, does the error persist when tried again on the same server? Or is it a one time error?

 

[PeterKi]

I currently have an open support call with Plesk support.
So far they have confirmed that for some reason it appears that adding any rule clears the firewall chains, and the server becomes unreachable.
It happened to them too, when I gave access to my server and I had to restore it again to yesterday's backup, which for me is the fastest way to
They are still investigating the issue.

 

[Dave W]

Out of curiosity, does the error persist when tried again on the same server? Or is it a one time error?

Hey Kasper,

Ive stopped paying attention to it to be honest because Ive had numerous tickets open on it, and once support see that they can apply rules they call it resolved and with the increase in Plesk pricing I don't see why we should beta test for them.

From memory its intermittent, on a run of say 5 new containers running the same ansible playbook, 1 might fail. Then in a run of changing the firewall a different one in five would fail.

This is with the timeouts changed in panel.ini before changes to the firewall are made which if these are a requirement for the firewall to work then should be the default timeouts set by Plesk but I dont think its a timeout issue.

I just manually fix and move on, Ive pretty much given up on opening tickets on the issue.

Dave_W

 

[kassi]

I have the exact same issue as @PeterKi mentions and I'm also on a Strato server (yet!).
I set both timeouts already to 240 because running the firewall-new.sh script manually already took 2:40. Nevertheless firewall i disabled, can't be enabled, breaks with the "emergency.sh timeout after 5s" and knocks me out of my server, so only a reboot works.

Anyone having a working and persistent firewall solution running that works with fail2ban and docker, but without this extension?

BTW: I noticed in the changelog for 2.1.3:
Added support for using the --apply and --enable commands without the --confirm command in automated deployment scenarios. (EXTPLESK-4831)

How does that work? There's no further information in this. I also provision with ansible (except the firewall because it isn't working).

 

[Peter Debik]

When you configure the Plesk firewall on the Linux console, please make sure that you use a different SSH session for confirming the new configuration than for appyling it.

 

[kassi]

I always do. Still this problem.

 

[Peter Debik]

The "emergency.sh" keyword caught my attention. I think it is a known issue PPS-14933, but not an issue with Plesk actually. Your hosting provider should resolve the iptables timing issue in order for iptables-related scripts to work properly.

As a workaround, please increase the timeout settings in panel.ini drastically, e.g.

[ext-firewall]
confirmTimeout = 660
confirmTimeoutCli = 660

 

[PeterKi]

The support did analyze my server and found that a timeout of 150 solves the problem.
They stated that the strato vServer seems to be the problem as it reacts very slow on the iptables scripts.
During the investigation Pleask supporters also locked out themselves several times.

Nevertheless, I think, that it must never happen that a firewall update leaves a server in an inaccessible state.
If there is a timeout, it must under all circumstance keep the server accessible and as a last resort flush the firewall rules and disable the firewall.
The too short default timeout is definitively a problem with the new firewall extension.

It is very common to have a blacklist for certain IP ranges and the Plesk firewall should have a special case for that.
Especially with the wars in Ukraine and Gaza I see frequent hacking attempts from Iranian, Russian and Chinese servers.
I have found ipsets (https://ipset.netfilter.org/install.html) which may be a solution as it allows changing a set without clearing and reloading all iptables rules.
Thus, the lock out problem may be avoided.
I encourage Plesk to look into this and possibly add ipsets to a reworked firewall extension.

 

[Peter Debik]

As far as I know, the geo-blocking feature of the new Firewall extension does exactly that.

 

[PeterKi]

geo-blocking? Where is it?
I do not see this anywhere and a Plesk search for it does not reveal anything.

 

[Peter Debik]

https://support.plesk.com/hc/en-us/articles/12377285410839-How-to-block-or-whitelist-specific-countries-through-Plesk-

 

[PeterKi]

Oh, I see.
But blocking a whole country isn't very helpful.
There are cloud hosters located in UK or NL which host servers from all over the world.
I use the dialog shown in your link to block specific IPs or IP ranges like e.g. 46.148.40.0/24 which currently does a lot of login scanning.
For that I have added a rule to the firewall which I call myBlacklist to which I add the IPs which I want to block.
With any changes to the firewall rules, the current firewall extension clears all rules at first though and then it adds them again one by one.
This is what can take so much time.
In contrast to that, fail2ban for example only manipulates single rules and thus doesn't show the timeout problem.
From my understanding, the ipset tool also only changes a set of rules and doesn't flush all the other rules which are not affected.
Thus, I encourage Plesk developers to look into ipset, so that subset of iptables rules e.g. for blacklisting or whitelisting can be maintained separately from other rules.