Input Atomic Tortix ruleset for ModSecurity breaks Apache configuration due to missing files in /etc/asl

[Peter Debik]

Server operating system version

CentOS

Plesk version and microupdate number

Plesk Obsidian 18.x

Since Wednesday, May 24th, at around 4 am Atomic ruleset updates are removing important files from /etc/asl, including "whitelist". A missing whitelist file leads to a broken Apache configuration, hence Apache won't reload or restart.

The issue is currently under investigation. So far we see an issue on Atomic's side and have already contacted them for a fix.

For a workaround:

https://support.plesk.com/hc/en-us/articles/14801826549527

Alternative "emergency" workaround:
Create a text file /etc/asl/whitelist with this content:

127.0.0.1/8

then

# chown tortix:root /etc/asl/whitelist

 

[Dork]

Alternative "emergency" workaround:
Create a text file /etc/asl/whitelist with this content:

127.0.0.1/8

then

# chown tortix:root /etc/asl/whitelist

I did that but I get:
modsecurity_ctl failed: Command '['sed', '-i', '-e', 's#^MODSEC_RULES_PATH\\s*=.*#MODSEC_RULES_PATH="/etc/httpd/conf/modsecurity.d/rules/tortix/modsec"#g', '-e', 's#^RESTART_APACHE\\s*=.*#RESTART_APACHE="no"#g', '-e', 's#^AUTOMATIC_UPDATES\\s*=.*#AUTOMATIC_UPDATES="no"#g', '-e', 's#^MODSEC_50_PLESK\\s*=.*#MODSEC_50_PLESK="yes"#g', '/etc/asl/config']' returned non-zero exit status 2.

 

[Peter Debik]

That is well possible, because other files are missing from /etc/asl, too. Please then go for the other workaround. Mine was only meant to being able to immediately restore Apache operations if needed.

 

[Dork]

That is well possible, because other files are missing from /etc/asl, too. Please then go for the other workaround. Mine was only meant to being able to immediately restore Apache operations if needed.

Switching to comodo doesn't change the error message about Apache config so this workaround seems to be useless.
Deinstallation of modsecure did the job - my server is reachable again now.
Please let me know when modsecure is useable again.

 

[Bobbbb]

Since Wednesday, May 24th, at around 4 am Atomic ruleset updates are removing important files from /etc/asl, including "whitelist". A missing whitelist file leads to a broken Apache configuration, hence Apache won't reload or restart.

The issue is currently under investigation. So far we see an issue on Atomic's side and have already contacted them for a fix.

For a workaround:

https://support.plesk.com/hc/en-us/articles/14801826549527

The workaround of switching to the Comodo ruleset worked for me. Apache restarted successfully. I did have to manually restart one of the PHP-FPM services.

 

[larryk]

FYI. I had support go to Comodo ruleset via "CLI", as using the Plesk interface didn't work. I got the same errors.

But CLI got the comodo ruleset working.

My question:
When will Atomic work?
anyone know if the Paid Atomic works? Works better?


thank you
PS. the Comodo rules are... uh... old? I dont' think they are updated. Support couldn't tell me a version?

 

[larryk]

Comodo is version 2.9 ?????
I'm educated guessing that is at least 3 years old, if not older?

 

[Maarten]

My question:
When will Atomic work?
anyone know if the Paid Atomic works? Works better?

This is an overview of Basic and Advanced Atomic ModSecurity Rule Sets:

Atomic ModSecurity Rule Sets

The Atomic Basic ModSecurity rule set includes the following: SQL injection protection. Cross-site scripting protect...

docs.plesk.com

 

[Jonathan B]

FYI. I had support go to Comodo ruleset via "CLI", as using the Plesk interface didn't work. I got the same errors.

But CLI got the comodo ruleset working.

My question:
When will Atomic work?
anyone know if the Paid Atomic works? Works better?


thank you
PS. the Comodo rules are... uh... old? I dont' think they are updated. Support couldn't tell me a version?

Hi, I've Atomic Advanced Mod Security, same problem. Now I've switched to Comodo, hope the situation can be resolved soon.

 

[larryk]

This is an overview of Basic and Advanced Atomic ModSecurity Rule Sets:

Atomic ModSecurity Rule Sets

The Atomic Basic ModSecurity rule set includes the following: SQL injection protection. Cross-site scripting protect...

docs.plesk.com

But Maarten, it is not working.
Have you tried to use it?
It is currently broken.

 

[jorge ceballos]

Hi,

Any update on this?

TIA

 

[Peter Debik]

We're in contact with Atomic on this issue. It needs a fix from them. That has not been provided yet.

 

[Peter Debik]

Unofficial: On my servers here updates were installed and /etc/asl configuration is back including a working ruleset. I don't have an official statement on the update yet.

However, since /etc/asl is working again, I also got warnings on all machines that mod_evasive has blacklisted their own IPs. Because Apache is receiving many requests from Nginx an logs them as requests from the server's public IP. If you are facing a similar issue I recommend to add these lines to your /etc/httpd/conf.d/mod_evasive.conf file:

DOSWhitelist 127.0.0.1
DOSWhitelist <your server's public IP>

and reload the web server configuration afterwards

# apachectl -t
# service httpd reload

Else it can happen that mod_evasive blacklists the server's own public IP and Apache quits responding to internal requests. At this time I do not yet know why this is now happening (it did not before). If you are not using mod_evasive, no action is required.

 

[Bobbbb]

Unofficial: On my servers here updates were installed and /etc/asl configuration is back including a working ruleset. I don't have an official statement on the update yet.

Thanks. It did reactivate OK, except it cleared out my list of Security rule IDs that were turned off. Switch to Comodo didn't delete them so I didn't expect that switching back to Atomic would wipe them out.

Any chance there are located somewhere I can find?

 

[Bobbbb]

Hmm. Now, after a short time many of my sites started showing the Apache testing 123 page. Since the reactivation of Atomic rules in ModSecurity was the only recent change, I suspect that is related. I have switched back to Comodo and restarted Apache and ngenx to see if that resolves the issue.

 

[jorge ceballos]

Tried it in one of my servers and still shows missing asl/whitelist and wont activate the module
* did not apply the "emergency workaround" just deactivated the module when trouble hit.
should I before trying again ?

TIA

 

[jcgalvez]

Seems like the "new update" wiped the login/password from plesk on the installation/update, so requests a new login/password (the original login/pass is missing on the new plesk update)

Going to the atomic site and registering, and entering the new login/pass may work

for me in order to make it work I had to follow this steps

change to atomic disabled
change to comodo disabled
change comodo to enabled

otherwise apache was not starting...

 

[Peter Debik]

The issue has been brought in by an Atomic update last night. The solutions we can currently provide are documented here:

https://support.plesk.com/hc/en-us/articles/14861542533911

 

[tkalfaoglu]

I had it set for Comodo.. the new update did nothing to me.. but my apache got wiped by PHP itself -- had to reinstall about 50 packages
not a good day for servers, I guess?
-t

 

[Peter Debik]

I had it set for Comodo.. the new update did nothing to me.. but my apache got wiped by PHP itself -- had to reinstall about 50 packages
not a good day for servers, I guess?
-t

That should not happen at all and there are no records here that Plesk can do that. I recommend creating a support ticket on the case so that staff can check that Plesk is installed correctly and the system is stable.