HTTP 503 error – Service Unavailable

[AITpro Admin]

Logged into the site and connected via FTP.  See my findings below:

Troubleshooting, fixes, etc.
############################

Steps to remove the Server Protocol Brute Force Login protection htaccess code that does not work on this particular host server/website:
1. Connect via FTP.
2. Go to folder: /wp-content/bps-backup/autorestore/root-files/auto_.htaccess
3. Edit the auto_.htaccess file and delete the Server Protocol Brute Force Login protection htaccess code.
4. Edit the Root .htaccess file in the WordPress installation folder and delete the Server Protocol Brute Force Login protection htaccess code.
5. Login to the site, delete the Server Protocol Brute Force Login protection htaccess code in BPS Custom Code, click the save button and activate Root Folder BulletProof Mode.

You cannot use the Server Protocol Brute Force Login protection htaccess code on this server because all Requests are forced to use the outdated HTTP/1.0 Server protocol. I assume this is because the server is using a Reverse Proxy. What is unusual is that the HTTP_X_FORWARDED_FOR: log entry field is not displaying the Proxy IP and Client IP address.

[403 GET Request: October 8, 2016 3:09 pm]
Event Code: BFHS - Blocked/Forbidden Hacker or Spammer
Solution: N/A - Hacker/Spammer Blocked/Forbidden
REMOTE_ADDR: 108.213.94.121
Host Name: 108-213-94-121.lightspeed.irvnca.sbcglobal.net
SERVER_PROTOCOL: HTTP/1.0
HTTP_CLIENT_IP:
HTTP_FORWARDED:
HTTP_X_FORWARDED_FOR:
HTTP_X_CLUSTER_CLIENT_IP:
REQUEST_METHOD: GET
HTTP_REFERER:
REQUEST_URI: /wp-login.php
QUERY_STRING:
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Login delay checking:
######################

Your wp-login.php file was quarantined and autorestored on: 2016-10-06 19:49:59. At the top of the wp-login.php file I found this php function: sleep(2);  What this function does is it delays login processing of all logins and Login page loading for 2 seconds. I assume that was done by your host support for some reason to test the wp-login.php page/script. Your current wp-login.php file does not contain the php sleep function since the wp-login.php file was autorestored.

Logical Guesses|Theorys for the Login page high usage and performance issue/problem:
######################

Most Likely Cause (Note: the js script tags have been removed so that this js code can be displayed in the forum topic):
#################
I see this Source Code on your Login page: script if("sessionStorage" in window){try{for(var key in sessionStorage){if(key.indexOf("wp-autosave-")!=-1){sessionStorage.removeItem(key)}}}catch(e){}}; script
This is not standard WordPress code. I do not recognize it. I did google searches and could not find any clues about what is adding this code to your login page, but I believe this code is causing the high usage/performance problems on your Login page. You will have to try and track down where this code is coming from.  It could be that a plugin or theme that you have installed is adding this code.

Less Likely Cause (only do anything with this after you have eliminated the above most likely cause for the problem):
#################
The problem may be related to however the Reverse Proxy is configured. Ask your host to create a whitelist rule on the Reverse proxy to not to check the WP Login page.  I am not sure how that would be done or if that is possible to do. The logic is this: However the Reverse proxy is processing POST Login Requests is causing the high resource usage/performance issues and most likely because the Bot POST Requests are malformed. Logically it seems very possible to handle 400 errors at the Reverse Proxy so that they are killed before being sent to your website/server by filtering HTTP Status Code 400.

Additional, other, etc
########################

Uptime Robot Custom Code needed: See this forum topic for the solution: http://forum.ait-pro.com/forums/topic/split-uptimerobot-whitelist-uptimerobot-bot/#post-8003
WooCommerce Custom Code needed: See this forum topic for the solution: http://forum.ait-pro.com/forums/topic/woocommerce-read-me-first/
WPBakery Visual Composer Custom Code needed: See this forum topic for the solution: http://forum.ait-pro.com/forums/topic/visual-composer-blocked-by-bps-pro/
AutoRestore single file exclude rule needed for this file: /home/xxxxx/public_html/.ftpquota
See this forum topic for how to add that: http://forum.ait-pro.com/forums/topic/autorestore-quarantine-guide-read-me-first/#autorestore-exclude-rules
Found this code below in your wp-config.php file that is in the wrong location in your wp-config.php file.
Solution: Moved this code to the correct location in your wp-config.php file.

# Disables all core updates. Added by SiteGround Autoupdate:
define( 'WP_AUTO_UPDATE_CORE', false );

No code should ever go after these 2 final lines/blocks of code in your wp-config.php file:
#########################

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

# Disables all core updates. Added by SiteGround Autoupdate:
define( 'WP_AUTO_UPDATE_CORE', false );

[armintz]

First off, thank you for such an in depth response. I really appreciate it and it speaks a lot about your level of support.

I’ve removed the Server Protocol Brute Force Login protection htaccess code on all sites on my server and am now able to access the dashboard of my sites without issue.

As far as the high usage on the login page that is causing me issues, I looked into this code that you pointed out:

script if("sessionStorage" in window){try{for(var key in sessionStorage){if(key.indexOf("wp-autosave-")!=-1){sessionStorage.removeItem(key)}}}catch(e){}}; script

I found it on every single one of my sites, not just my sites with siteground hosting, but other accounts that I manage – in a variety of hosting environments, with a variety of different themes, plugins, etc. I also checked with a friend who had a bare bones WP install on his server and the wp-login.php file showed the above code too.. so I don’t think that code snippet is out of the ordinary or a reason for the resources being exhausted…

I’ve submitted another ticket with siteground, although they seem to be a bit baffled. If they can’t make any logical suggestions (they’ve already upsold me on “adding more account resources” on two occasions, which they’ve since told me was not necessary) I will ask them about this, per your suggestion:

Ask your host to create a whitelist rule on the Reverse proxy to not to check the WP Login page. I am not sure how that would be done or if that is possible to do. The logic is this: However the Reverse proxy is processing POST Login Requests is causing the high resource usage/performance issues and most likely because the Bot POST Requests are malformed. Logically it seems very possible to handle 400 errors at the Reverse Proxy so that they are killed before being sent to your website/server by filtering HTTP Status Code 400.

If they can’t offer an explanation and/or resolve the issue with the suggestion above, I will pay the extra $ to move my sites to wpengine… a more expensive host which I never have issues with.

For the sake of being thorough, I’ll update this thread if/when I get any updates, but I think it’s safe to say that my resource issue is not related in anyway to BPS Pro! Thank you again for checking on this and going above and beyond to ensure your plugin was playing nice with my hosting configuration.

[AITpro Admin]

Ok I figured out where that WP Autosave code is coming from:  https://codex.wordpress.org/Editing_wp-config.php#Modify_AutoSave_Interval  When I add this code:  define( 'AUTOSAVE_INTERVAL', 160 ); in my wp-config.php file then I see the Autosave Session code displayed in my Login page Source Code.  I tested that autosave code and it only affects autosaving time intervals when editing Posts and does not affect the overall Browser Session adversely.  I don’t think you need to spend any money or switch hosting accounts to solve this problem.  Obviously there is a root problem going on and most likely that has to do with your Proxy server.  If you are the only person who logs into your website and you do not allow just anyone to register, login and post comments on your website then you can use this IP based Login page protection code below:  http://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/  It uses an “allow” vs “block” method of allowing your IP address vs blocking millions of IP addresses.

This .htaccess code will protect your WordPress Login page from Brute Force Login Attacks based on IP address, but keep in mind if you are allowing folks to login to your website then they will not be able to login.  This .htaccess code is for folks who do not want to allow anyone else, but themselves to login to their website’s.  You can add additional IP addresses to allow other people access to your login page or allow access to your login page from different locations/computers:  work, home, etc.  See the IMPORTANT NOTES help section below before using this code.

# Protect wp-login.php from Brute Force Login Attacks based on IP Address
<FilesMatch "^(wp-login\.php)">
Order Allow,Deny
# Add your Public IP Address using 2 or 3 octets so that if/when
# your IP address changes it will still be in your subnet range. If you
# have a static IP address then use all 4 octets.
# Examples: 2 octets: 65.100. 3 octets: 65.100.50. 4 octets: 65.100.50.1
Allow from 65.100.50.
</FilesMatch>

[armintz]

I forsee too many issues with whitelisting specific IPs… clients having various work stations, traveling, etc. It would also be a disservice to the sites which have user/commenting functionality.

I did check with my hosting about your other suggestion:

Ask your host to create a whitelist rule on the Reverse proxy to not to check the WP Login page. I am not sure how that would be done or if that is possible to do. The logic is this: However the Reverse proxy is processing POST Login Requests is causing the high resource usage/performance issues and most likely because the Bot POST Requests are malformed. Logically it seems very possible to handle 400 errors at the Reverse Proxy so that they are killed before being sent to your website/server by filtering HTTP Status Code 400.

They responded with this:

please provide us Reverse proxy’s IP address and we will whitelist the rules that are hit by it.

Thank you.

[AITpro Admin]

Ok well I’m out of ideas.  Whatever the problem is it is not being caused by BPS.  I believe this is a host server issue.  So your host would have to fix whatever the issue is.  I do not know for sure if your host uses a Proxy.  The only reason it appears they are using a Proxy is because Server Protocol HTTP/1.0 is being used and is displayed in Security Log entries.  At this point there is nothing else I can assist you with since this appears to be a host server related issue.

[armintz]

Are you able to tell me what I am supposed to provide to my hosting provider after they sent this note?

please provide us Reverse proxy’s IP address and we will whitelist the rules that are hit by it.

If not, I understand. It was their response to this suggestion:

Ask your host to create a whitelist rule on the Reverse proxy to not to check the WP Login page.

Thanks

[AITpro Admin]

The question they asked you does not make technical and logical sense.  Your host should know everything about your hosting environment and server because they are you host and they provide the environment and server.  Ask your host to switch your PHP server to another PHP server or do that yourself.  Usually that can be done by using php/php.ini handler htaccess code to load a different PHP version/build.  The problem could be that there is a problem with this particular PHP server itself.  ie the build is bad and switching to a different PHP server will resolve the problem since you will be using a “good” PHP version/build.

[armintz]

They responded with this:

You can change the PHP version for your website via cPanel -> PHP Version Manager.

[AITpro Admin]

Actually they gave you a correct response on how to change your PHP server version. So change your PHP version and see if it resolves the problem not.  Do these steps below.

Do these steps below:
1. Turn Off AutoRestore.
2. Go to F-Lock > File Lock > unlock your root htaccess file.
3. Do the SiteGround steps to change your PHP version in your web host control panel/cPanel.
4. Go to B-Core > htaccess File Editor page > Your Current Root htaccess File tab > check to see if any php/php.ini handler htaccess code was created/added at the top of your Root htaccess file by SiteGround after you change your PHP version.
5. Go to Custom Code > paste your php/php.ini handler htaccess code to this Custom Code text box:  CUSTOM CODE TOP PHP/PHP.INI HANDLER/CACHE CODE (if you found any php/php.ini handler htaccess code added to your Root htaccess file).
6. Click the Save Root Custom Code button.
7. Go to the Security Modes page and click the Root Folder BulletProof Mode activate button.
8. Go to F-Lock and lock your Root htaccess file.
9. Run the Pre-Installation and Setup Wizard again.

[armintz]

Thanks, I’ll try this with BPS and see if it fixes the issues. There system default php was 5.6.25 so I’ve updated to 7.0.10.

Also it looks like siteground didn’t add anything to my root htaccess after the update (screenshot below) so I should be safe to ignore steps 4-6.
https://s16.postimg.org/plsnqr0fp/Screen_Shot_2016_10_20_at_11_58_36_AM.png

Will be interesting to see if this solves the original issue, and if so, why it took my security plugin dev’s to solve an issue that clearly lies on the hosting side… maybe I’ll make a blog post about it.

Thanks again!

edit: php/php.ini handler code found is apparen appearing in root htaccess after the update, screenshot:
https://s22.postimg.org/pe88rm1sh/Screen_Shot_2016_10_20_at_12_12_39_PM.png

[AITpro Admin]

EDIT:  I see that you posted an edit and that SiteGround does add/create php/php.ini handler htaccess code in your Root htaccess file so follow the steps to add the SiteGround php/php.ini handler htaccess code Custom Code, etc.

Yes, you can actually ignore all of the steps if your host does not use/create php/php.ini handler htaccess code for each PHP server version.  I posted those steps just in case SiteGround does use/create php/php.ini handler htaccess code.

When you have an odd problem that should not be happening on a PHP server the first thing you should try is to switch your PHP server version to a different PHP server version.  There could be something wrong with a particular PHP server version installation that you are using.

[Nitin]

The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.

[Author]

Posts