Hosting Account Suspended for High Usage

  • tgh745

    (@tgh745)


    11 years, 9 months ago

    We just got an e-mail that said our Word Press site has been suspended by our host. We need to figure out what may be causing usage like this and how can we solve the problem.

    bin/php | c133235/harttantiquesgallery.com/xmlrpc.php (8916) cpu_min: 98.45, ram: 432435.44 MB, disk_read: 0.3 MB, disk_write: 0.06 MB.

    Your website, or a feature of your website, has caused an overload on the web server it resides on. To stop degradation of server performance, we have temporarily suspended harttantiquesgallery.com, but you still have FTP access to work on scripts or files that may be causing this issue. Your consumption of CPU resources are listed below:

    2014-09-03 159.66
    2014-09-02 96.29
    2014-08-31 10.31
    2014-08-30 4.85
    2014-08-29 5.71
    2014-08-28 6.36
    2014-08-27 4.99

    Scripts that possibly perform a server overload:

    bin/php | c133235/harttantiquesgallery.com/xmlrpc.php (8916) cpu_min: 98.45, ram: 432435.44 MB, disk_read: 0.3 MB, disk_write: 0.06 MB.
    bin/php | c133235/dadsofdetroit.org/xmlrpc.php (8949) cpu_min: 61.62, ram: 314560.97 MB, disk_read: 0.17 MB, disk_write: 0.05 MB.
    bin/php | c133235/harttantiquesgallery.com/index.php (109) cpu_min: 1.20, ram: 4783.33 MB, disk_read: 23.33 MB, disk_write: 0.0 MB.
    bin/php | c133235/harttantiquesgallery.com/wp-cron.php (43) cpu_min: 0.42, ram: 1837.26 MB, disk_read: 2.56 MB, disk_write: 0.0 MB.
    bin/php | c133235/dadsofdetroit.org/index.php (52) cpu_min: 0.30, ram: 1580.46 MB, disk_read: 0.15 MB, disk_write: 0.0 MB.
    bin/php | c133235/harttantiquesgallery.com/wp-login.php (9) cpu_min: 0.08, ram: 385.9 MB, disk_read: 0.02 MB, disk_write: 0.0 MB.
    /usr/bin/perl | N/A (3) cpu_min: 0.03, ram: 49.71 MB, disk_read: 0.0 MB, disk_write: 0.03 MB.
    bin/php | c133235/harttantiquesgallery.com/wp-admin/index.php (3) cpu_min: 0.02, ram: 143.4 MB, disk_read: 0.27 MB, disk_write: 0.0 MB.
    bin/php | c133235/dadsofdetroit.org/wp-login.php (5) cpu_min: 0.02, ram: 152.21 MB, disk_read: 0.02 MB, disk_write: 0.0 MB.
    bin/php | c133235/harttantiquesgallery.com/wp-admin/admin-ajax.php (1) cpu_min: 0.00, ram: 47.75 MB, disk_read: 0.26 MB, disk_write: 0.0 MB.
    bin/php | c133235/dadsofdetroit.org/wp-cron.php (2) cpu_min: 0.00, ram: 61.11 MB, disk_read: 0.18 MB, disk_write: 0.0 MB.
    /bin/bash | N/A (6) cpu_min: 0.00, ram: 6.5 MB, disk_read: 0.13 MB, disk_write: 0.56 MB.

    In many cases, this issue can be improved or resolved with one or more of the following steps:

    1) Make sure all Content Management Systems (WordPress, Joomla, phpBB, etc.) are updated to the latest versions. Also, make sure that your updates and upgrades are compatible with your current software.
    2) Disable and remove all unused plugins.
    3) Enable caching for the data that rarely changes.
    4) Create a good robots.txt AND .htaccess file to reduce the number of bot hits to your website.
    5) If you think your website is under attack, you can use your .htaccess file to block suspicious IP addresses. To find these IP’s, go to your Control panel and click on web options and then select the domain you wish to check. Next, click to view the transfer logs. You can also check for malicious IP’s through Webalizer and AWstats.
    6) Additional research may be necessary depending on your website applications.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Moderator James Huff

    (@macmanx)

    11 years, 9 months ago

    If xmlrpc.php and wp-login.php are among the top files, you might be the target of a brute-force login attack, where a bot is constantly running common username and password combinations against your blog to find the “winning” combo.

    First, add this to your .htaccess file:

    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
RewriteCond %{HTTP_REFERER} !.*(example.com|jetpack.wordpress.com).* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]
</ifModule>

    Replace “example.com” with your domain, and if you aren’t using Jetpack Comments, remove “|jetpack.wordpress.com”.

    This will prevent bots from directly attacking wp-login.php and wp-comments-post.php, they will need to go through the forms to login or leave comments.

    After that, install a plugin like http://wordpress.org/plugins/bruteprotect/ to both catch anything else that makes it through and protect xmlrpc.php.

    sffandom

    (@sffandom)

    11 years, 9 months ago

    Use the RENAME WP-LOGIN.PHP plugin instead and then just add this code to your site’s .htaccess file:

    <Files "wp-login.php">
Order Allow,Deny
deny from all
</Files>

<Files "xmlrpc.php">
Order Allow,Deny
deny from all
</Files>

    The botnets will be stopped in their tracks and hackers won’t know where to try to login manually.

    Although the plugin suggests a new name for your login page, I suggest you change it to something else you can easily remember. That way anyone who knows about the plugin won’t be able to try to attack the default login page.

    If you ever forget the page name then just delete the plugin and login to reinstall it.

    Thread Starter tgh745

    (@tgh745)

    11 years, 9 months ago

    I have been using a plugin called Bullet Proof Security for at least three years and have never had any problems before. After this recent attack on our site, I blocked access to xmlrpc.php using the .htaccess file.
    This seems to have solved the problem.

    I still have a few questions:

    1) Does anyone believe that I should take more steps or should this be sufficient?

    2)Does anyone know if http://wordpress.org/plugins/bruteprotect/ and http://wordpress.org/plugins/bulletproof-security/ are compatible together?

    3) How can I monitor the server usage? I’d like to know before my account is shut down. Ideally this should be an automatic notification that server usage has increased.

    4)Also after I blocked xmlrpc.php I started getting notifications from my BPS plugin that indeed the 403 errors were being served. This log contains a lot of IP addressees; should I somehow block them?

    [Large code excerpt removed by moderator per forum rules. Please use the pastebin for all large code excerpts. It works better anyway.]

    sffandom

    (@sffandom)

    11 years, 9 months ago

    It’s really not necessary to cite so much data in your post as an example of what you’re seeing.

    As to your question, if the bots are being served 403s that is really all you can do unless you have access to your server’s firewall (this would be IP TABLES on a Unix/Linux system). There you can add IP addresses to be DROPed (they receive no response whatsoever) but this is a tedious process and a risky one if you don’t know what you are doing.

    Moderator James Huff

    (@macmanx)

    11 years, 9 months ago

    1. Yes, if your host says the extreme load has passed, that should be sufficient.

    2. No, not really, but Bulletproof should have been protecting you from those brute-force attacks.

    3. You’ll need to ask your hosting provider about that. There isn’t really anything through WordPress that can accurately monitor server load.

    4. No, don’t block by IP, let the plugin continue to handle them. IP addresses are still dynamic from many ISPs, so what may be an attacker today could be a legitimate visitor tomorrow.

    If Bulletproof was serving 403s for each attack attempt, then it was actually doing its job, but the attack was probably so massive that having the plugin (and therefore PHP and MySQL as well) process each attack attempt was probably doing your load more harm than good.

    Using one of the .htaccess-based methods above will stop a majority of the attacks at the server-level before they even hit WordPress, PHP, and MySQL, which should spare you a significant amount of load during the next attack.

Viewing 5 replies - 1 through 5 (of 5 total)

The topic ‘Hosting Account Suspended for High Usage’ is closed to new replies.