Plugin Author
AITpro
(@aitpro)
That would mean that either humans or bots are going directly to the BPS Security Logging 403 template URI: example.com/wp-content/plugins/bulletproof-security/403.php. Are you seeing normal Security Log entries too or do all of your Security Log entries have the same Request URI to the BPS Security Logging template file?
-
This reply was modified 9 years, 2 months ago by
AITpro.
Thread Starter
Anonymous User 9269003
(@anonymized-9269003)
all this type of logs has the same Request URI: /wp-content/plugins/bulletproof-security/403.php
I have lot’s of them and as mentioned earlier each has different REMOTE_ADDR and HostName from around the world.
I got few other alerts about spammers who wants to publish some comments.
-
This reply was modified 9 years, 2 months ago by
Anonymous User 9269003.
Plugin Author
AITpro
(@aitpro)
My first logical guess would be that there is some sort of caching problem going on. If you are using a caching plugin then delete/clear/flush your plugin cache. Next logical guess would be something else you have installed is intercepting or handling(?) the 403 errors and sending them directly to the 403.php logging template instead of what the normal functionality should be.
Thread Starter
Anonymous User 9269003
(@anonymized-9269003)
I use WP SuperCache and clearing cache not change anything.
I have no idea, what else make these logs.
Perhaps, I will deactivate the Logs.
Plugin Author
AITpro
(@aitpro)
Post a link to your website and I’ll check the frontend of your site to see if I see any clues for why this is happening on your site. If you do not want to post your website domain link publicly then email it to us using our contact form: https://www.ait-pro.com/contact/
Plugin Author
AITpro
(@aitpro)
I received your site link. After looking at the Source Code of your site what I think is the causing the strange Security Log entries has to do with the Autoptimize plugin. Minification/compression can cause all sorts of odd problems since the original Source Code of your site has been combined together. My hunch (I could be wrong of course) is that what is occuring is this type of scenario: Autoptimize has combined js scripts and there is a 403 error occurring somewhere with something, but that 403 is not being logged “normally” and is instead redirecting directly to the 403.php logging template. It could also be some sort of combination issue with Autoptimize and WPSC caching. I will install and test Autoptimize on a testing site and see if can reproduce the problem, but the same problem may not occur if another plugin is involved in the equation. Example: Plugin X has a js script that has been combined into the Autoptimize js script with all other js scripts. The 403 error is occurring in Plugin X’s js script, but due to the way Autoptomize combines js scripts the normal 403 Security Logging functionality is not working normally. I will know more after doing some testing.
Plugin Author
AITpro
(@aitpro)
I was unable to reproduce the problem on my testing site. So if you want to try messing around with the Autoptimize plugin settings and test things. ie “Optimize JavaScript Code” setting. Or of course you can just ignore these Security Log entries or turn Off Security Logging. The Security Log is automatically zipped, emailed to you and replaced when it reaches the size limit setting you have chosen. So basically it does not hurt anything to not do anything about this issue.
based on the above, “plugin x” would be the culprit, rather then AO, no? anyways, once you’ve found a page that includes a request resulting in a 403, you can disable AO on a per-request basis by adding ?ao_noptimize=1 to the URL to see what “origin JS” request the 403’ing resource.
hope this helps,
frank (ao dev)
Plugin Author
AITpro
(@aitpro)
@futtta – The problem may not have anything at all to do with your plugin or the plugin X scenario. 😉 I was just doing some logical guessing based on the end result of the way the BPS Security logging problem is doing what it is doing. In any case, it does not seem like it would be very difficult or time consuming to completely rule out/eliminate your plugin. 😉 If the BPS Security logging problem was happening for every single log entry then I think the most logical thing to look at would be the server or something on the server. It’s a strange problem that I have never seen before so I have no history to go on. 😉
Plugin Author
AITpro
(@aitpro)
@futtta – Oh and thanks for posting the disabling per-request info.
Plugin Author
AITpro
(@aitpro)
hmm I just noticed this – “…all this type of logs has the same Request URI…” For some reason I thought it was stated that not all Security Log entries were being logged with the same problem. So actually the most likely thing that is occurring is something on the server is handling 403 errors in a way that sends/redirects all 403 errors directly to the BPS 403.php logging template without capturing the origin/source of the 403 error. Normally a 403 error occurs and BPS does the redirect using the ErrorDocument directive. So I guess the next most logical thing to do would be to contact your web host folks and ask them how they handle 403 errors and if they allow the Apache ErrorDocument directive in htaccess files.
-
This reply was modified 9 years, 2 months ago by AITpro.
Plugin Author
AITpro
(@aitpro)
Or maybe another htaccess file somewhere is redirecting the 403 errors? Are you using any other htaccess code anywhere else that redirects 403 errors?
Thread Starter
Anonymous User 9269003
(@anonymized-9269003)
I got this in htaccess
# BPS ERROR LOGGING AND TRACKING
# Use BPS Custom Code to modify/edit/change this code and to save it permanently.
# BPS has premade 400 Bad Request, 403 Forbidden, 404 Not Found, 405 Method Not Allowed and
# 410 Gone template logging files that are used to track and log 400, 403, 404, 405 and 410 errors
# that occur on your website. When a hacker attempts to hack your website the hackers IP address,
# Host name, Request Method, Referering link, the file name or requested resource, the user agent
# of the hacker and the query string used in the hack attempt are logged.
# All BPS log files are htaccess protected so that only you can view them.
# The 400.php, 403.php, 404.php, 405.php and 410.php files are located in /wp-content/plugins/bulletproof-security/
# The 400, 403, 405 and 410 Error logging files are already set up and will automatically start logging errors
# after you install BPS and have activated BulletProof Mode for your Root folder.
# If you would like to log 404 errors you will need to copy the logging code in the BPS 404.php file
# to your Theme’s 404.php template file. Simple instructions are included in the BPS 404.php file.
# You can open the BPS 404.php file using the WP Plugins Editor or manually editing the file.
# NOTE: By default WordPress automatically looks in your Theme’s folder for a 404.php Theme template file.
ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php
ErrorDocument 401 default
ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
ErrorDocument 404 /404.php
ErrorDocument 405 /wp-content/plugins/bulletproof-security/405.php
ErrorDocument 410 /wp-content/plugins/bulletproof-security/410.php
Plugin Author
AITpro
(@aitpro)
That is standard BPS error logging code, which looks normal/fine. So if you have not added any additional custom htaccess code to BPS Custom Code or manually created any other htaccess files somewhere else under your hosting account then I guess check with your web host and see if they are doing anything with HTTP Status 403 code logging/handling.
Plugin Author
AITpro
(@aitpro)
Oh and you should probably eliminate that the AO plugin has anything to do with this issue. Could still be the Plugin X scenario that I described above. 😉
