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

[Erwan]

Server operating system version

CentOS Linux 7.9

Plesk version and microupdate number

18.0.52

Hi all,

Since one hour, with a have a problem with a server.
We have errors 403 with in the logs: "client denied by server configuration"

Nota: we don"t have made any change on the server.

If we go to "Apache & Nginx" and we Apply directly, website is ok but only one minute and after errors 403.

The web page say: "You do not have permission to access this document.".
Nota: we have disabled fail2ban.
Do you have an idea of the problem?

There is an .htacces file in the website but only with rewrite rules:
RewriteEngine on
RewriteCond %{REQUEST_URI} !assets/(.*)$
RewriteCond %{REQUEST_URI} !data/(.*)$
RewriteRule ^(.*)$ index.php [L]

Thabk you for your ideas...

 

[Erwan]

Currently we use:
FPM by Apache with PHP 7.3

 

[Peter Debik]

Please check if you have a file /etc/httpd/conf.d/mod_evasive.conf. If so, add these lines to it:

DOSWhitelist 127.0.0.1
DOSWhitelist <your server's public IP>

(replace <your server's public IP> with your IP)

Then reload the web server configuration

service httpd reload

 

[gennolo]

I had the same issue this morning in several Centos 7 boxes.

The problem was due to an automatic update that upgraded those packages :

---> Package mod_evasive.x86_64 0:1.10.1-22.el7
---> Package mod_qos.x86_64 0:11.70-1.el7
causing something very wrong in Apache refusing all web requests...

I solved by rollbacking the update, you can use yum history list to get the last update transaction ID,
then launch a "yum history rollback xxxx" and restart Apache afterwards.

Any help or insight on how to fix this permanently is appreciated.

 

[Peter Debik]

Any help or insight on how to fix this permanently is appreciated.

It's under investigation here.

 

[gennolo]

Thanks , it has been an exciting morning !

 

[Erwan]

Thanks a lot Peter.

 

[Erwan]

Thanks , it has been an exciting morning !

I confirm

 

[delefant]

Thanks , it has been an exciting morning !

+10

 

[JonasF]

It seems soemthing (aum?) has forced the additional install of mod_evasive this morning. But mod_evasive is unconfigured thus its limits are way below anything usable for a public webserver - and this causes the 403 errors.
This appears to only have hit older servers with CentOS 7, Alma 8 and 9 arent affected.

 

[tkalfaoglu]

Um, I uninstalled mine.. still have the same issues

 

[JonasF]

Um, I uninstalled mine.. still have the same issues

Did you restart httpd?

 

[Ludo]

FIX my problem, thank you so much !

 

[Mountaineer]

We're having the same issues. Replying for updates

 

[David_Courtney]

We have had the same issue this morning. Intermittant 403 errors which disappear after apache restart then come back not soon after. We have actioned the rollback. Fingers crossed this resolves the issue!

Thanks gennolo

 

[martin.g]

We have had the same issue this morning. Intermittant 403 errors which disappear after apache restart then come back not soon after. We have actioned the rollback. Fingers crossed this resolves the issue!

Thanks gennolo

There´s already an official workaround/fix: https://support.plesk.com/hc/en-us/articles/14861542533911
I guess your fix won´t be persistent as the aum_nighly.sh cron will install the module tomorrow again.

 

[David_Courtney]

There´s already an official workaround/fix: https://support.plesk.com/hc/en-us/articles/14861542533911
I guess your fix won´t be persistent as the aum_nighly.sh cron will install the module tomorrow again.

Thanks,

We have disabled the yum update until the vendor had presented us a fix. We will update accordingly.

Thanks for your help

Dave

 

[gennolo]

So, even if I rolled back the update, will the cron "aum_nighly.sh" reinstall silently mod_evasive packages even if "yum update"
now sees nothing to update ?

Is there a way to recall aum_nightly.sh from CLI to test some scenarios on a dev VM ?

I tried launching it and it did nothing.

 

[martin.g]

Of course you can run it manually.On our server with about 100 websites it takes 3 seconds but it has no output:

cat /etc/cron.daily/aum_nightly.sh

  #!/usr/bin/env /bin/bash
  source "/var/awp/etc/config"

  if [ "$AIR_GAPPED" == "yes" ]; then
    echo "AIR_GAPPED set to yes. Skipping execution of aum_nightly.sh"
    exit 0
  fi

  /var/awp/bin/aum_nightly &

I don´t know exactly how the atomic updater works. If it does not install anythin by manual run, it won´t by night unless something changes. Perhaps a new aum package would reinstall mod_evasive, perhaps not.

 

[JuanG]

Please check if you have a file /etc/httpd/conf.d/mod_evasive.conf. If so, add these lines to it:

DOSWhitelist 127.0.0.1
DOSWhitelist <your server's public IP>

(replace <your server's public IP> with your IP)

Then reload the web server configuration

service httpd reload

Is there any permanent solution or we have to be worried about all the updates from now on?