• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Urgent / Big problem with apache/nginx [mod_evasive denylisting]

Current work-around we implement on our side :
exclude the mod_qos and mod_evasive under /etc/yum.conf
exclude=mod_evasive mod_qos
Then if that package has been installed (you can confirm via rpm -qa or yum info )
Code:
yum info  mod_evasive | grep -i repo
Repo        : installed
From repo   : epel
            : firewalls, routers, etc. mod_evasive presently reports abuses via

yum info  mod_qos | grep -i repo
Repo        : installed
From repo   : epel

You can run this command :
Code:
yum remove mod_qos mod_evasive -y && service httpd restart ( just to restart the apache with the right conf )
 
Is there any permanent solution or we have to be worried about all the updates from now on?
The solution (workaround) that we can currently provide is:
The issue was brought in by an Atomic update that should actually fix the broken /etc/asl issue from before, but it also replaced mod_evasive. At the moment if you want to be sure that it won't happen again, the only solution is to remove mod_evasive (and disable it in Apache modules).
 
I see an updated aum version had been pushed overnight :

aum-1:6.0.48-29386.el7.art.x86_64

I guess it contains a permanent fix for this problem?
 
I think the concept of "permanent fix" does not match to "aum". It hasn't in the past, so likely it won't in the future. The problem is, too, that with such security services there are so many other aspects involved that there is always something that can fail. Just to make sure that the mod_evasive issue cannot bring your server down, I'd still recommend to have DOSWhitelist entries for 127.0.0.1 and your public IP in place in /etc/httpd/conf.d/mod_evasive.conf. We never know when a similar issue might return.
 
I have had the same issue today and i have manged to stop this by disabling mod_evasive as mentioned on the ticket https://support.plesk.com/hc/en-us/articles/14861542533911

However, i am unable to resolve the issue using my external IP address like in the example below. I would rather add the IP Whitelist and not disable this but im not sure why its not working. Are these the only 2 entries needed? The IP in /var/log/messages is my internal IP


DOSWhitelist 127.0.0.1
DOSWhitelist <my external IP>
 
@Olly95 Please show an excerpt of /etc/httpd/conf.d/mod_evasive.conf with your DOSWhitelist entries. Also please show an excerpt from the logs where that IP is still blacklisted. For both, please redact the IP address for privacy reasons.
 
@Olly95 Please show an excerpt of /etc/httpd/conf.d/mod_evasive.conf with your DOSWhitelist entries. Also please show an excerpt from the logs where that IP is still blacklisted. For both, please redact the IP address for privacy reasons.
Hi Peter, thank you for your help. I changed this to my private IP and it worked fine thanks.
 
Mod_evasive is very old code.. like untouched for 7 years.. -- yet very popular.. I'm surprised no one picked it up and improved it..
or at least, kept it up to date..
 
Was anything pushed automatically last night? Been having the Apache 123 page appearing sporadically since the 26th. Been getting round it by turning off Apache and going entirely via Nginx on certain subs. Then this morning, everything back to normal, all my machines acting like this never happened.
 
Mod_evasive is very old code.. like untouched for 7 years.. -- yet very popular.. I'm surprised no one picked it up and improved it..
or at least, kept it up to date..

It's so ancient that the README even mentions Frontpage:

KNOWN BUGS

- This module appears to conflict with the Microsoft Frontpage Extensions.
Frontpage sucks anyway, so if you're using Frontpage I assume you're asking
for problems, and not really interested in conserving server resources anyway.
 
This issue was really bad!

I think these are related to the May 26, 2023 update.



It is very unacceptable to install a Apache module to the server without the user's knowledge.

What are the other modules have been installed with this AUM update?

We were struggling for days due to this issue.
 
It is very unacceptable to install a Apache module to the server without the user's knowledge.
Please let Atomic know about it.

I'd like to add that Plesk is in the process of taking precaution by using a kind of "shadow" algorithm for future updates so that vendors won't have this influence on user servers any longer.

Please also take into account that no technical system is perfect. The number of files and software involved became so large that it is impossible to predict all cases.
 
Back
Top