WPDogger
Forum Replies Created
-
I just experienced the exact same problem after doing plugin updates. There were random, multiple attempts to log in using the Display Name, which your plugin successfully blocked. Changing the login address did not stop the attempts. There are calls to getUsersBlogs in the stack trace. I just checked Completely block access to XMLRPC and Disable pingback functionality from XMLRPC, as you recommend. I’ll let you know if the problem is resolved in a few days. Do you know what is causing the XMLRPC calls? Is it WordPress, another plugin, or something external? The IPs for the invalid logins are coming from all over Europe, so they appear to be external calls.
Thanks for the response. My issue is with trying to monitor whenever a registered user logs in. Unfortunately, I cannot monitor the logs all day.
This could be a useful feature to add.
I think I figured this out after I replaced all the WP scripts, all the active plugins (many were now obsolete and abandoned so I removed them), the Genesis theme files, and regenerated the .htaccess file from scratch.
I believe the .htaccess.admin_edit_htaccess_too_big message is due to a combination of a new bug in cPanel and old IPs I had blocked in cPanel using IP Blocker. Each corrupted .htaccess file ended with the following directive. This directive does not show up in any of the newly generated .htaccess files.
<Files 403.shtml>
order allow, deny
allow from all
</Files>This is used by cPanel to block IPs manually entered in IP Blocker. WP Security uses a different method to block blacklisted IPs. It should only be there if you have blocked IPs in cPanel. I have done that in the past. The 403 problem appears to occur if there is no list of denied IPs following the directive. I checked cPanel and there are currently no IPs blocked, which means GoDaddy either wiped out the list or they are not being displayed. I think cPanel is running a routine to update .htaccess files and is creating the problem when no blocked IPs exist in cPanel, yet the old directive still exists in the .htaccess files. A rep I talked to at GoDaddy admitted a scheduled update routine on the server could be at fault.
All the sites went down early on Sunday morning for the past two weeks. The big test will be if they go down again this coming Sunday.
If anyone else experiences this, I suggest you remove the Files 403.shtml directive from the .htaccess file, any deny statements that follow it, and all IPs you may have blocked in IP Blocker. At this point I’m about 90% sure that will fix the problem.
Thanks for the tips, guys.
I saw the thread about the 500 error. I did check that and didn’t find any duplicate closing tag in the .htaccess file. Something was trying to re-write the .htaccess file, which is what generated the error. It shouldn’t be doing that with no one in the admin updating the settings.
I don’t have the 5G firewall enabled on any of the sites.
This isn’t a random 403 error. All of my WP sites went down simultaneously in the middle of the night — and it did it twice, both times very early Sunday morning. The .htaccess files were corrupted and the strange file was left in the root. The file appears to contain the original copy of the .htaccess file.
The error file could be coming from WP, or Apache, of Linux, or PHP. I’m genuinely surprised there is no information about that file name on the web.
I’m also surprised that hundreds — if not thousands — of sites are not reporting this. There is nothing unique about my sites. I’ve only heard about one other site that experienced this.
I’ve gone through the databases and the sites looking for something malicious. I’m now going to replace all the WP, theme, and plugin files.
If anyone finds any additional info, I’m all ears.
@mbrsolution, please keep this thread open. I see no evidence that it’s your plugin causing the problem, but the feedback is good.
I only have a couple of simple cron jobs running. I’ve checked those. There is no unusual code and the last saved date for the scripts on the server is several years ago.
However, thus far this appears to be a scheduled event. Your plugin is the only one common to all these sites, so I had to ask.
If I find the source of the problem, I’ll post it here for others.
Thanks for the tips. This does not appear to be a hack to me. I’ve been building WP sites for 15 years and have always hardened the sites. None have ever been hacked. I have fixed other sites that have been hacked. I know, there is always a first time.
I’ll go through all the actions you offered, but I suspect this will be back next week.
The odd part is the file named .htaccess.admin_edit_htaccess_too_big. I cannot find any info about it anywhere. I suspect something is trying to update the .htaccess files, which are only about 9k to 11k in size for each site.
Forum: Plugins
In reply to: [WP-DBManager] Your backup folder is NOT writableThat was it. I changed the path on the DB Options page. The problem is fixed.
That was too easy. I was looking in the wrong place because most plugins do not offer easy options for changes.
Thanks, Lester.
- This reply was modified 7 years, 11 months ago by WPDogger.
Forum: Plugins
In reply to: [All-In-One Security (AIOS) – Security and Firewall] WHOIS Lookup Not WorkingYes, I mentioned that above.
The tech at GoDaddy had no idea why the WHOIS lookup does not work.
I think it’s a server configuration issue because a PHP utility I have on my server that does WHOIS lookups is also not working since I moved my sites to GoDaddy. Something is likely blocking the call.
Forum: Plugins
In reply to: [All-In-One Security (AIOS) – Security and Firewall] WHOIS Lookup Not WorkingWindows 7 and FireFox 47.0.
I think the WHOIS request is being blocked by GoDaddy.
The real questions are:
1) Is anyone else experiencing the same issue with GoDaddy?
2) Is the WHOIS lookup working for anyone using GoDaddy for hosting?
Forum: Plugins
In reply to: [All-In-One Security (AIOS) – Security and Firewall] WHOIS Lookup Not WorkingI’ve tried that before.
I just updated to the current version of All In One Security & Firewall and tried it again. All plugins except this one were disabled. Same results. The page says “WHOIS lookup successfully completed. Please see the results below:”, but there are no results.
It doesn’t appear to be a plugin conflict. All my sites use Studio Press responsive themes. I thought perhaps CSS was preventing the display, but I don’t see anything in the page code that tells me the results are getting generated. For example, I can plug in an IP address for a spammer in Turkey, but do not find the word ‘Turkey’ anywhere in the resulting HTML code.
My GoDaddy configuration looks like this:
Plugin Version : 4.0.8
WP Version : 4.5.1
WPMU: No
MySQL Version : 5.5.45
PHP Version : 5.4.45
PHP Memory Limit : 256M
PHP Max Script Execution Time : 30 SecondsAre there any specific PHP extensions that need to be compiled with PHP in order for a WHOIS lookup to work?
Forum: Plugins
In reply to: [All-In-One Security (AIOS) – Security and Firewall] WHOIS Lookup Not WorkingThanks for the follow-up.
No, it has not been resolved. The tech at GoDaddy had no idea why the WHOIS lookup does not work.
I’m not seeing any error messages. When I do an IP search it returns the message, “WHOIS lookup successfully completed. Please see the results below:.” However, no results are displayed.
I’m using iplocation.net to do my IP lookups, so this is not really a problem.
Forum: Plugins
In reply to: [All-In-One Security (AIOS) – Security and Firewall] WHOIS Lookup Not Working