• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • 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

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.
I was most surprised myself that it happened -- and all by itself. I hadn't touched the server in some time.. Anyway, it's cured now.. It was very strange however.. As I said, re-installing ALL php packages seems to have cured it somehow..
 
Is there a reaction of Atomic in the meantime?
Is Plesk not in the position to make pressure?
 
Atomic provided two updates, neither fixed the situation completely. For the time being, new installations cannot install their ruleset, only existing installations can keep using it. This is temporary. Plesk and Atomic are both still striving to provide a final fix.
thanks for keeping us in the loop.
 
Hi,

Any news on this?
We use(d) Atomic advanced version bought through Plesk.
Just tried it again and got:

AH00526: Syntax error on line 220 of /etc/httpd/conf/modsecurity.d/rules/tortix/modsec/10_asl_rules.conf:
Error creating rule: Could not open phrase file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/sql.txt": No such file or directory

Reviewed the the path and sql.txt is there - chmod 600 -
Is it a permission issue or still not working?

TIA
 
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.
That would not be a problem if apache only listened via loopback when nginx is reverse proxy. Just saying.
 
@jorge ceballos When you do ll /etc/httpd/conf/modsecurity.d/rules/tortix/modsec/sql.txt do you see
Code:
-rw-r--r-- 1 root root    959 Jun  1 06:31 sql.txt
?
Thanks,

No, its chmod 600
-rw-------. 1 root root 2609 Jun 6 10:15 /etc/httpd/conf/modsecurity.d/rules/tortix/modsec/sql.txt

Should it be 644 ( -rw-r--r-- ) ?

If its the case, how can we rectify ASL permissions?

TIA
 
Thanks,

No, its chmod 600
-rw-------. 1 root root 2609 Jun 6 10:15 /etc/httpd/conf/modsecurity.d/rules/tortix/modsec/sql.txt

Should it be 644 ( -rw-r--r-- ) ?

If its the case, how can we rectify ASL permissions?

TIA
-rw------- 1 root root 959 24. Mai 13:34 /etc/httpd/conf/modsecurity.d/rules/tortix/modsec/sql.txt
On servers that had Atomic running before the first issue occured, all should be normal.
OK - everything works fine now ...
but is it a permanent solution to the problem?
 
I just don't know. We are not looking at the issue as finally resolved, but also there is no ETA on a reliable, persistent solution yet.
 
Back
Top