Firewall might disable itself after updating to Plesk 11.5

[LarsenD]

I already posted this as a bug report and now wanted to inform other users.

Starting with Plesk 11.5, the file "/opt/psa/var/modules/firewall/firewall-emergency.sh" contains the following line:

rm -f /opt/psa/var/modules/firewall/active.flag

That line stems from updating

Preparing to replace psa-firewall 11.0.9-debian6.0.build110120608.16 (using .../psa-firewall_11.5.30-debian6.0.build115130819.13_amd64.deb) ...
Unpacking replacement psa-firewall ...

Now, when you stop the firewall, you cannot start it again, cause deleting the active.flag disables the firewall:

# ll /opt/psa/var/modules/firewall/active.flag
-rw-r--r-- 1 root root 0 2013-11-26 09:22 /opt/psa/var/modules/firewall/active.flag
    
# /etc/init.d/psa-firewall stop
psa-firewall: firewall successfully disabled
    
# ll /opt/psa/var/modules/firewall/active.flag
ls: cannot access /opt/psa/var/modules/firewall/active.flag: No such file or directory
    
# /etc/init.d/psa-firewall start
psa-firewall: service is disabled

You then have to manually "touch" the active.flag to be able to start the firewall again.
A workaround is to remove the line:

sed -i 's:rm -f /opt/psa/var/modules/firewall/active.flag::' /opt/psa/var/modules/firewall/firewall-emergency.sh'

I really hope that Parallels fixes this asap, as normally you won´t notice that the firewall is not active when every works fine (nothing is blocked) and Plesk still shows all the rules.


Regards,
Lars

 

[Nikolay.]

So... how is this a bug, exactly?

firewall-emergency.sh script, as its name suggest, is called in following conditions:

1) to disable firewall rules due to internal condition, e.g. when firewall extension is uninstalled;

2) "OMG, I screwed up badly, please disable all rules ASAP and permanently!"

The only valid reason to call it manually is the second condition. Of course this implies that bad (current) firewall rules should not be applied on the next machine boot as well.

Note that applying firewall rules from UI will generate and apply new iptables rules and make sure they are applied on next boot as well.

 

[LarsenD]

Yes, that´s also what I thought would be logical. Though, as you can see from the output I posted above, you can see that the firewall is not only stopped but disabled.

With Plesk 11.0 you could restart the firewall, with Plesk 11.5 you cannot.

 

[Nikolay.]

OK. I'll rephrase. Imagine you screwed up your firewall configuration in Plesk, for example you can't open new SSH connections to the server. However, Plesk firewall GUI applied the changes (there is a failsafe, yes, but it only protects against cutting off access to the Panel GUI). Now you go and call firewall-emergency.sh script, then forget about it. Then, some time in the future the server is rebooted. Voilà! You are unable to access it due to a faulty firewall configuration.

With Plesk 11.0 you could restart the firewall, with Plesk 11.5 you cannot.

Things get better, don't they?

 

[LarsenD]

I am not sure I understand your previous post correctly...

How would you restart the firewall with this bug?

 

[Nikolay.]

How would you restart the firewall with this bug?

a) This is not a bug, IMO.

b) You don't. Otherwise you'll just apply "bad" firewall policy. Instead you need to go to firewall module in Plesk UI, fix policy there and apply it there. This will "start" the firewall.

 

[LarsenD]

I think you don´t understand the problem. How would restarting the firewall apply "bad firewall policy" if nothing had been changed!? The rules are ok, I (for whatever reason) restart the firewall and boom, the firewall is automagically disabled when it should be running. And you think this is not a bug?

Another example: No rules have been changed, the server needs maintenance and is shut down ergo all init scripts are called to stop the daemons, etc. Therefore, the firewall is stopped. When you start the server again, the active.flag is missing and the firewall won´t start. This clearly is a bug.

 

[Nikolay.]

Oh. I see your point now, thank you. This indeed looks like a bug. However all my previous conclusions hold as well (that firewall init script probably needs to be disabled if firewall-emergency.sh was called manually).

 

[timber]

Yup..I agree, this looks like a bug. Every time /etc/init.d/psa-firewall is called to stop the firewall, it also calls the firewall-emergency.sh script which ultimately removes the active.flag. So next time the system boots up, the psa-firewall script thinks the firewall service is disabled.

Somebody should submit this to Parallels?

 

[LarsenD]

Yes, I have already submitted it (see first post).

 

[timber]

Ah, right. Excellent. It's kind of a weird bug to introduce imho. Brings your firewall down after a reboot and it's not easily noticable unless you look into it.

 

[IgorG]

It is known issue (PPPM-1222 for your reference)
We plan this fix in the one of nearest microupdates.

 

[andyb-uk]

Is there an update to this ?

This is still occurring now on the latest Plesk 11.5 On Ubuntu 12.04/LTS.

Its a ridiculous bug - you reboot the server and unless you check you are not aware you have no firewall.

Not great in terms of security.

 

[OlivrL]

I even removed the whole firewall extension, reinstalled and configured it from scratch. Installation was done from the standard update / add modules plesk panel -> no change. I have to call

/opt/psa/var/modules/firewall/firewall-active.sh

after reboot. This is in fact a SEVERY SECURITY HOLE in Plesk !!!

Addendum: commenting out the rm line and touching the flag as recommended by Lars solved the issue for me. Reboot is now safe. Thank you for you post, Lars! And thx to bing for finding it immediately .-)

 

[Ma3xl3]

This bug still exists with plesk 11.5.30 Update #45
When will it be fixed?