bulletproof-security.0.47.5 not working

Yep sure no problem. I am currently looking for a way to permanently block this tool. I do not know yet if this is possible since it is a Server-side tool, but someone must have figured out how to block this junk tool by now after 10 years. ??

What is even more pathetic is that when you look in the cPanel Forums you see years of people’s posts reporting this problem. obviously they either do not think there is really a problem or maybe they just think its not that important. either way someone from cPanel should have researched this further due to the 1,000’s of posts that state that this tool is broken. ugh.

I would be more than happy to fix the broken cPanel HotLink Protection Tool coding myself for free even just so i would not have to deal with this baloney for another decade.

hmm this looks promising – cPanel modules and addons are written in PERL so logically there is a good chance that a PERL script could actually kill the HotLink Protection Tool. still researching, but this does look promising. ?? Since the modules are located in a protected Server location than the way to kill it would be to find the correct variable and make it malfunction to render it harmless/non-destructive.

Since cPanel modules are parsed internally by the cPanel software,
you will not be able to call system-installed modules from your custom
modules. Only a few pre-compiled modules (located in /usr/local/cpanel/perl/)
and the other modules in the Cpanel:: namespace are available.
If you need to install additional modules, you can place them in:
/usr/local/cpanel/perl

Getting warmer. ?? Once i zero in on the target i can shoot it out of the sky. LOL

Mime::add_hotlink
API Version: 1 – Click here for documentation
Syntax: Mime::add_hotlink( urls, exts, redirect, direct )
Description: Add hotlink protection to a specified site. This will redirect users to another URL if they come to a file with a specified extension, but haven’t been referred by an allowed URL.
Parameters:
urls (string)
This parameter allows you to specify URLs that are allowed to hotlink to your site. Specify multiple URLs by separating them with newline characters (e.g., example.com/).
exts (string)
File types that should use hotlink protection. Specify multiple extensions by passing a comma-separated list to this parameter (e.g., jpg,jpeg,gif,png,bmp).
redirect (string)
The URL to which users who violate the hotlinking policy will be sent (e.g., example.com/badhotlinker).
direct (boolean (optional))
Allow users to directly visit files with matching extensions. The default value is off (0).
Returns:

This function does not produce any output.

Before getting into the workarounds listed on your link, can you tell me, does this broken Hotlink Protection Tool mean everyone on Namecheap (or other hosts with the same problem) will have troubles with WordPress?

Actually this thread has at least 2 totally separate problems going on. So your problem is actually #1 and not #2. That is what i suspected from the get go would happen – totally different problems all getting lumped as 1 problem, which is not the case. ??

1. Namecheap has a new malware scanner that is incorrectly quarantining the BPS root .htaccess file because it believes there is malicious code in that file and obviously this is a mistake. This is also affecting BPS Pro users as Namecheap is additionally quarantining plugin files as well as the .htaccess file. I have contacted them hours ago and hopefully they are calibrating the scanner so that it does not continue to make this mistake.

2. The broken cPanel HotLink Protection Tool that has been broken for over 10 years now and continues to break WordPress websites year after year after year…

Okay, thanks for the clarification. So anyone using WordPress installations at Namecheap who installs BPS will have this problem until Namecheap fixes the issue of their malware detection thinking .htaccess is malicious code.

This thread is ridiculously overwhelming, so it’s no wonder that different problems are being “lumped into” one problem. Perhaps separating out the problems into new threads would have been helpful.

Yep you are correct. What i recommend is that you wait a few days before upgrading BPS.

NOTE: This ONLY applies to folks who have Namecheap as their web host.

Yep i feel like a juggler on this one. LOL

Yeah tell that to the people who posted different problems under the same thread. ha ha ha. In all fairness it is actually difficult to find the exact origin or source of problem until you see enough of the problem’s pattern. There are a finite number of HTTP Status Error codes and they could be generated for an infinite number of reasons. ?? What I was most concerned with as usual is the total number of folks with issues compared to the total number of folks with no problems at all. The ratio was somewhere around 4,000 good upgrades / 10 bad upgrades so this obviously indicates isolated problems and not a major problem like a coding mistake in BPS.

This is pretty standard though each time a BPS upgrade is released. I have to make sense of things quickly and make sure that several people yelling “FIRE” does not get out of hand. I’m getting better and better at quickly handling these types of threads before everyone starts panicking and running for the exits. LOL

Given that the prior version of BPS works, I’m a bit iffy on the logic of this being all the fault of Namecheap’s malware detection. See, I reinstalled the prior version and created an .htaccess file without problem, so Namecheap doesn’t think THAT is malware. Only the .htaccess created by the updated BPS is seen as malware by Namecheap.

Seems like something new was added to the .htaccess file generated by BPS which causes this issue. Is this true? Is this new thing added to the .htaccess file necessary or can it be removed, just as a workaround for right now?

As for your other comments, I don’t think I was merely a troublemaker “yelling FIRE” and “panicking” at all. I understand your frustration, but honestly, plug-ins are breaking constantly. They screw things up or get hacked or don’t play well with the new WordPress version. We had a trojan in one plug-in download, for pete’s sake. On top of all that, we are constantly being hit with hackers.

So while I appreciate you’re trying to protect your plug-in’s reputation, I’m just trying to protect my websites. After all the problems we’ve had, and as important as security is for our sites, I don’t think I was overreacting or panicking in the least.

Yes, new code in BPS is seen as malicious by 2 web hosts out of over 1,000. 4,000 BPS upgrades went perfectly smoothly with that new code on 1000’s of different web hosts. No, the new code is not absolutely necessary, but when you look at the numbers you see a clear picture and the obvious question is why are 2 hosts out of 1,000’s not seeing valid code when all the other 1,000’s of web host do see valid code?

The obvious answer is all those 1,000’s of web hosts use scanners, but only 2 web hosts scanners are seeing malicious code so the answer is not to change working code in BPS. The answer is to fix/calibrate those scanners that are not working correctly on those 2 web hosts. This is typically very simple to do. Scanners look for signatures and coding patterns. If the scanner is not calibrated to find actual malicious code and is calibrated to generally then it will generate false flags/alarms for legitimate safe coding as is the case with Name Cheap and one other Host. These scanners are not broken they just need to be calibrated correctly.

Did i call you a troublemaker yelling Fire. Please look at my comment again and you will clearly see that I most certainly did not say that to you. I am not frustrated at all this is completely normal. This same thing happens with every BPS upgrade release. People always worry about upgrading any plugin – i in fact hold my breath as well – this is also completely normal as people do make mistakes – we are all human. I will not address the rest of your statement because it is just venting so a reply is not necessary.

I actually care about folks and gladly and generously donate my time and efforts to helping folks so your last statement is kind of offensive to me, but i am not taking it personally. I completely understand where you are coming from.

In closing i just want to say that 4,000 upgrade installations went perfectly smoothly without a problem. There were around 10 isolated incidents. This is pretty much par for the course for BPS upgrade releases. ??

Here’s the thing: You have framed this as “Namecheap has a new scanner on their Servers that is incorrectly quarantining both BPS plugin files and BPS .htaccess files.” But that doesn’t seem right, unless you’re saying Namecheap just by coincidence had a new scanner installed the day of the BPS update.

Their scanner didn’t think the prior version of BPS contained malware. So I think it’s perfectly logical to ask why you say this is Namecheap’s new “malfunctioning scanner” when it seems more like new code in BPS has caused a conflict with Namecheap’s existing malware scanner.

All I was trying to do is ask if, as a workaround, we could remove or comment out that conflicting code so we could still update BPS, because security is a huge issue on my websites, plus I know out-of-date plug-ins are a security problem.

It feels very much like you think I’m attacking you by asking these questions, and you have spent a lot of time on this thread complaining about Namecheap, and about people posting “different problems under the same thread” and “panicking” and “yelling FIRE” and “just venting” so therefore don’t deserve a reply.

It makes the entire thread feel hostile. Therefore, I’m bowing out of this thread.

AITPRO

I am the host for heartwood and am looking into this for her now.

This may help, the scanner is CXS scanner (https://www.configserver.com/cp/cxs.html) and here is the report its giving

# Known exploit = [Fingerprint Match] [Exploited .htaccess [P0176]]:
'/home/userdir/public_html/.htaccess'
and
# Known exploit = [Fingerprint Match] [Exploited .htaccess [P0176]]:
/home/userdir/public_html/wp-content/plugins/bulletproof-security/admin/htaccess/secure.htaccess

I can certainly whitelist it but this problem will happen with all hosts using cxs and its a pretty popular scanner. so what changed to make it think your file is a bad one?

let me know if you need any more info.
John

Hi ethical,

Thank you for jumping in. ??

Here is the new coding that was added in BPS .47.5. these are 3 different areas of the root .htaccess file but i have just dissected/extracted only the new code, which is shown below. So either the HTTP_REFFER lines of code are triggering the scanner or more likely the grouping of IP addresses in the FilesMatch block of code. Thanks.

This entire new block of code was added
# FORBID EMPTY REFFERER SPAMBOTS
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} (wp-comments-post\.php)
RewriteCond %{HTTP_REFERER} !^.*example.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* - [F]

This line of code was added to the existing block of code below
RewriteCond %{HTTP_REFERER} ^.*example.com.*

RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
RewriteCond %{HTTP_REFERER} ^.*example.com.*
RewriteRule . - [S=1]

This entire new block of code was added below

# FORBID COMMENT SPAMMERS ACCESS TO YOUR wp-comments-post.php FILE
# This is a better approach to blocking Comment Spammers so that you do not
# accidentally block good traffic to your website. You can add additional
# Comment Spammer IP addresses on a case by case basis below.
# Searchable Database of known Comment Spammers https://www.stopforumspam.com/

<FilesMatch "^(wp-comments-post\.php)">
Order Allow,Deny
Deny from 46.119.35.
Deny from 46.119.45.
Deny from 91.236.74.
Deny from 93.182.147.
Deny from 93.182.187.
Deny from 94.27.72.
Deny from 94.27.75.
Deny from 94.27.76.
Deny from 193.105.210.
Deny from 195.43.128.
Deny from 198.144.105.
Deny from 199.15.234.
Allow from all
</FilesMatch>

Few web hosts do malware scanning and certainly there are quite a few who are not commenting on the issue or would not think to comment here…

I imagine there will be quite a few accounts out in the world who will wake up in the morning with there sites suspended as a result (and not to happy at BPS I imagine).

Though you should applaud those hosts who do actively monitor for malware, and make amends where possible IMHO.

@sbbn – I am not trying to pass blame. I do not think or operate that way. I think and act like Spock – strictly facts and strictly logic. Sometimes that comes across as me being a harsh person. If you feel that i am being harsh with you then i apologize for that. This is just the way i am programmed. ??

Ok now to get back on task. Just continue to use .47.4. The new .htaccess coding in .47.5 is doing a little focusing on Spam as i have gotten a lot of requests to add this type of coding (for a very long time) and i have finally gotten around to adding it. There is one important security coding improvement, but that may be the code that is triggering the scanner so once i find the actual code that is triggering the scanner I will then be able to make a determination on the next best course of action and that may be something like having to create different htaccess files based on Hosts. I of course would like for all the code to work fine on all hosts, not just for convenience sake, but because that offers the most folks the most protection.

Yep i think your last statement is a good idea. ?? Everyone has bad days and good days. ??

not really sure how to tell what its doing based on the response i saw but any chance you can message chirpy (jonathan I think his name is) at configserver and see if he can shed some light on it? He might understand that response code of P0176 and what it might relate to.

i can see about posting on the forums there too, but figured might be best programmer to programmer ??

I did paste both those sections of code into another htaccess file as well as the one heartwood is working on, and it did not trigger the quarantine, so its quite possible its something related to the whole as opposed to a specific part?

I think it has more to do with HOW the file is getting update along with the content, since simply pasting it in using file manager didnt do anything to flag the scanner?