Thomas O.

If you have experience editing the site’s .htaccess file, you can do something with it to help protect those files.

I haven’t tested it lately, but something like the following should work (it uses the cookie that’s set after the password is accepted):

# BEGIN file lock-downs
RewriteCond %{HTTP_COOKIE} !wp-postpass
RewriteRule \.(pdf|docx?)$ https://www.ioofhawaii.org/excelsior-members-only/ [R=302,L]
# END file lock-downs

I only used the following types of media files in the code:
pdf doc docx

You can easily add other file types like so:

# BEGIN file lock-downs
RewriteCond %{HTTP_COOKIE} !wp-postpass
RewriteRule \.(pdf|docx?|jpg|png)$ https://www.ioofhawaii.org/excelsior-members-only/ [R=302,L]
# END file lock-downs

Where I added the jpg and png file extensions.

But you’ll still want to stop search engines from indexing that page/post. You might be able to add something in the site’s robot.txt file. Or, add something like the following to your child theme’s functions.php file or create a plugin:

// Prevent search engines from indexing protected posts
function noindexpp_print_header() {
	global $post;
	if (!empty($post->post_password)) {
		echo '<meta name="robots" content="noindex">'."\n";
	}
}

add_action('wp_head', noindexpp_print_header);

Hopefully that helps, and if not, maybe it will get you going in the right direction.

I can give you a partial example that I have posted on my website. But it involves a bit, because if they were able to get an executable file to your server and it ran automatically, they could create/edit an .htaccess file and use a handler to make any file run as PHP. So make sure after you have placed an .htaccess file in your uploads directory that it is not writable.

# Disable any cgi-scripts and prevent directory browsing
Options -ExecCGI -Indexes

# Whitelist the following file extensions
# This includes the blocking of double extensions using [^.]
Order Allow,Deny
<FilesMatch "^[^.]+\.(?i:jpe?g|png|gif)$">
Allow from all
</FilesMatch> 

# Secure MIME-types
<FilesMatch "\.[Jj][Pp][Ee]?[Gg]$">
ForceType image/jpeg
</FilesMatch>
<FilesMatch "\.[Pp][Nn][Gg]$">
ForceType image/png
</FilesMatch>
<FilesMatch "\.[Gg][Ii][Ff]$">
ForceType image/gif
</FilesMatch> 

# Make sure mod_rewrite is running
RewriteEngine On

# Disable scripts
RewriteRule !^[^.]+\.(?:jpe?g|png|gif)$ - [H=cgi-script,NC,L]

The reason you want to make sure that use ForceType for the images, is to keep anyone from trying to add a handler to an image file to make it run as PHP, like I mentioned above.

Personally, I believe you should be careful of purchasing any product from a company that doesn’t have any version here at www.ads-software.com. At least if they have a version here at www.ads-software.com, you know that they strive to keep up with WordPress standards. Which usually means they pay attention to security. It’s not 100%, but seems to help.

In regards to the .htaccess code mentioned, that code only prevents access to those files from HTTP. It does not prevent execution. You would need to apply a handler to make that so:
https://www.ads-software.com/support/topic/please-fix-disable-php-in-uploads-issue-files-with-php-in-the-name-are-blocked?replies=7

In all reality, you would be better off whitelisting instead of blacklisting files. Because files with a PHP extension are not the only ones that can be executed.

There’s actually a plugin that is supposed to help, but I’ve never used it:
https://www.ads-software.com/plugins/ajax-heartbeat-tool/

The problem has been reported before. See here for my explanation and fix:
https://www.ads-software.com/support/topic/please-fix-disable-php-in-uploads-issue-files-with-php-in-the-name-are-blocked?replies=7

I do not believe this IP is a legitimate Google Bot:
173.194.99.134
https://googlewebmastercentral.blogspot.com/2006/09/how-to-verify-googlebot.html

It might be one of their other services though.

Hi,

Thanks for the reply. Did you have any of the plugins mentioned in the Master List thread installed and activated?
https://www.ads-software.com/support/topic/wordpress-40-master-list?replies=5

This happened to a client. Did you ever figure this out? I assumed it was the installation of WordPress 4.0.

I usually don’t share too many of my creations, but I figure it’s time. You can use .htaccess to block abnormal behavior, as most skiddies don’t have their scripts set up completely. Yet, I do see a few that do. Granted most headers can be spoofed, the majority of legitimate browsers either have them or don’t and they are either normal or they’re not normal. The code is below with explanations in the comments. The only thing you might want to change is the RewriteRule. It could include comments.php and/or other files. And the target of the RewriteRule could be changed to whatever you want as well. Sending it back to the sender or even redirecting to a 404 Not Found page, but I digress. That’s your choice. I just placed example.com, but you can do whatever you want.

# WordPress login and brute-force protection
# First set a cookie
# Where cookie-name is your cookie name
# Where cookie-value is your cookie value
# Where example.com is where the cookie is valid (your domain)
RewriteRule ^ - [CO=cookie-name:cookie-value:example.com]
# If no cookie, then bounce them
RewriteCond %{HTTP_COOKIE} !cookie-name=cookie-value [OR]
# If referrer doesn't match the HTTP host, then bounce them
# Comment out the line below if your server does not incorporate Atom Back References
RewriteCond %{HTTP_HOST}@@%{HTTP_REFERER} !^([^@]*)@@https?://\1/ [NC,OR]
# If a known proxy header is detected, then bounce them
# You can always add others. These are just the ones I mainly see.
RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
RewriteCond %{HTTP:X-FORWARDED-FOR} !^$ [OR]
RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$ [OR]
RewriteCond %{HTTP:HTTP-CLIENT-IP} !^$ [OR]
RewriteCond %{HTTP:VIA} !^$ [OR]
# If not a valid GET or POST request, then bounce them
# This is more than just allowing a GET or POST request only. The request must be valid.
RewriteCond %{THE_REQUEST} !^(?:GE|POS)T\ .+\ HTTP/1\.1$ [NC,OR]
# Since HEAD is implied with GET, bounce it because it should not be used on the login
RewriteCond %{REQUEST_METHOD} ^HEAD [NC,OR]
# If the known header fields for most humans are not present or invalid, then bounce them
RewriteCond %{HTTP:Connection} !^keep-alive$ [NC,OR]
RewriteCond %{HTTP:Accept-Encoding} !^gzip [NC,OR]
# If your site is only viewed in English, they you could modify the line below to look like this:
# RewriteCond %{HTTP:Accept-Language} !en [OR]
RewriteCond %{HTTP:Accept-Language} ^.?$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(?:.{0,49}|.{299,})$ [OR]
RewriteCond %{HTTP_USER_AGENT} \n [OR]
RewriteCond %{HTTP_ACCEPT} ^(?:\*/\*|.)?$
RewriteRule wp-login\.php https://example\.com [R=301,L,NS]

You could do that with an .htaccess file in that plugin directory. Much easier than trying to edit PHP files.

So the plugin is here:
site.com/wp-includes/plugins/my-plugin/my-plugin.php

In the my-plugin directory you would place an .htaccess file. In the .htaccess file, if there are no files in that plugin directory that need to be accessed via HTTP, you can place this:

ErrorDocument 403 /404
deny from all

Normally you would want to make it go to an HTML file. But that above should work.

But what if you have files that need to be accessed from HTTP, you ask? Well, then you need to whitelist those files, but you can still use the same ErrorDocument line. Here is an example:

I’ll use Akismet as an example. This is the default .htaccess file in Akismet with the ErrorDocument line added at the top:

ErrorDocument 403 /404
Order Deny,Allow
Deny from all

<FilesMatch "^(form|akismet)\.(css|js)$">
	Allow from all
</FilesMatch>

#allow access to any image
<FilesMatch "^(.+)\.(png|gif)$">
	Allow from all
</FilesMatch>

Me personally, that code is very inefficient and not as secure as it could be. I would do it like so, but it is much harder to interpret for beginners:

ErrorDocument 403 /404
Order Allow,Deny
<FilesMatch "^(?:akismet\.(?:cs|j)s|form\.js|logo-full-2x\.png)$">
Allow from all
</FilesMatch>

There are several plugins that should do that:

https://www.ads-software.com/plugins/wp-block-admin/
https://www.ads-software.com/plugins/st-admin-protection/

There are also some user role plugins that may do that as well.

If the .htaccess trick doesn’t work, it could also mean that mod_php is not installed on your server. Your best bet would be to contact your host on how to increase it with your set up.

You can make it expire with the session. Just add this to your child theme’s functions.php file or create a plugin:

add_action( 'wp', 'post_pw_sess_expire' );
    function post_pw_sess_expire() {
    if ( isset( $_COOKIE['wp-postpass_' . COOKIEHASH] ) )
    // Setting a time of 0 in setcookie() forces the cookie to expire with the session
    setcookie('wp-postpass_' . COOKIEHASH, '', 0, COOKIEPATH);
}

Hi,

If everything is working fine now, would you mind marking this as “Resolved”?

Thanks.

Are you using this plugin? It looks like there’s a reference of it in your last post.
https://www.ads-software.com/plugins/all-in-one-wp-security-and-firewall/

If so, you may want to contact their support for the issue(s) that you’re having.