• 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.

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

P

Peter Debik

Community Manager until 3/2024
Plesk Guru
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:

Alternative "emergency" workaround:
Create a text file /etc/asl/whitelist with this content:
Code: 
127.0.0.1/8
then
Code: 
# chown tortix:root /etc/asl/whitelist
 
Peter Debik said:
Alternative "emergency" workaround:
Create a text file /etc/asl/whitelist with this content:
Code: 
127.0.0.1/8
then
Code: 
# chown tortix:root /etc/asl/whitelist
Click to expand...
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.
 
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.
 
Peter Debik said:
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.
Click to expand...
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.
 
Peter Debik said:
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:
Click to expand...

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.
 
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?
 
Comodo is version 2.9 ?????
I'm educated guessing that is at least 3 years old, if not older?
 
larryk said:
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?
Click to expand...

Hi, I've Atomic Advanced Mod Security, same problem. Now I've switched to Comodo, hope the situation can be resolved soon.
 
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:

Code: 
DOSWhitelist 127.0.0.1
DOSWhitelist <your server's public IP>
and reload the web server configuration afterwards
Code: 
# 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.
 
Peter Debik said:
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.
Click to expand...

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?
 
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.
 
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
 
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...
 
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
 
tkalfaoglu said:
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
Click to expand...
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.
 
You must log in or register to reply here.

Similar threads

G
Issue AH01574 - New configuration files for the Apache web server - No matches for the wildcard '*asl*.conf
Replies
0
Views
580
gmadkins
G
finbarr69
Resolved /var/awp/etc/config: No such file or directory, Failed to update the ModSecurity rule set
Replies
5
Views
3K
8tango
8
Bitpalast
Input How to overcome intermittent, occasional 502 errors due to Apache or PHP-FPM response failures
Replies
0
Views
4K
Bitpalast
Bitpalast
Back
Top