New DoS attacks

Try checking to make sure that these files don’t actually exist. For the first line, look for an “index.php” file in that directory. If they’re still getting the “500” response code, then your host (or another plugin, or .htaccess) may already be blocking them, but it could be something within the file that is causing the 500 error — these files shouldn’t exist on a normal installation. If it’s the host’s settings or .htaccess that’s handling them, the attempts should use minimal resources, but if the files are there and starting to run, then failing, it might.

If the files aren’t there, and the host isn’t blocking the requests, WordPress may be treating them like 404’s, but there could be headers or content in the requests that you can’t see in the logs, causing WordPress itself to generate the “500” errors.

-Matt R

The files in the attempts do not exist. They also use names like 1.php or 2.php.

In my case, I talked to my hosting and I have mod_security enabled. So, how could they exhaust resources? a bad implementation in the host?

Nevertheless, Google results show more examples that surely don’t have mod_security. Some show cached pages for the attempts’ results.

Ok. The host still may or may not be blocking them intentionally with mod_security — it depends on the rules they have set up. If server resources are still being used excessively though, the attempts probably are being processed by WordPress as if they were 404’s, like in the last paragraph in my previous post.

There isn’t currently a way to block them any better by using Wordfence, since the attempts keep changing IPs. You could try adding them to “Immediately block IP’s that access these URLs” in Wordfence’s settings, but it currently only works for exact URLs and does not accept wildcards, and the 500 error may be generated before the request gets that far, too.

You could check the error log for any new details, but I know you said last time there was nothing relevant. The host might also have a mod_security audit log, that may help. If you know .htaccess well enough, you could try blocking those requests manually, using the filenames from your log.

-Matt R

WordPress may be treating them like 404’s, but there could be headers or content in the requests that you can’t see in the logs, causing WordPress itself to generate the “500” errors

I don’t like the idea that something can be included in a request and causes WordPress to throw “500” errors. Do you mean WordPress core?

If you know .htaccess well enough, you could try blocking those requests manually, using the filenames from your log.

Is it possible to use <Files> with wildcards in order to block anything containing an URL parameter like “abdullkarem=1”?

Edit: I found here that it’s possible to implement it with <If>.

Yes, it could be the WordPress core, or even a plugin or theme causing the “500” errors, or it could also be PHP’s settings. There are some php.ini settings like max_input_time or max_input_vars which may cause errors when there are bad requests. I don’t know for sure if they would give a 500 error or something else.

I’m glad you found what you were looking for, for .htaccess — I’m not an expert in all the options myself. We do have a feature request open for blocking URL patterns including wildcards, so this type of blocking may be easier in a future version.

-Matt R

Ok, thanks for your help!

We do have a feature request open for blocking URL patterns including wildcards, so this type of blocking may be easier in a future version.

That feature plus .htaccess blocking would be awesome ??