Viewing 5 replies - 1 through 5 (of 5 total)
  • Suggest that you review your website access logs, on cPanel they are “Raw access logs”, also change the settings to keep these day on day, you may want them later.

    These logs show the loading of every page, every script and every graphic. You will be able to see if it is wp-login.php or xmlrpc.php or wp-admin/index.php that is being attacked.

    Thread Starter David Burkhart

    (@dlburkhart)

    What I found after checking logs is that the attack is definitely automated, occurring 1 to 2 times per second. From what I can tell, the bot is using wp-login.php. Most every entry looks identical to the following:

    207.45.179.178 – – [11/Sep/2014:08:16:29 -0400] “POST /wp-login.php HTTP/1.0” 200 3806 “-” “-“

    I temporarily renamed the wp-login file and the log entries changed in the code numbers on the end:

    207.45.179.178 – – [11/Sep/2014:13:27:46 -0400] “POST /wp-login.php HTTP/1.0” 302 – “-” “-“

    I can take the “302” to mean an HTTP redirect message, “302 found”, since when I try to login, my browser is redirected to the home page. So, this technique effectively hid the login from the bot for now.

    Now that I know what is being attacked, any suggestions as to what I can do about it?

    The login does not seem to work after renaming it, likely due to recursive calls or named calls from interdependant modules. And, since I have clients that use it, I cannot leave the login renamed. I know I could probably scan and replace the references to “wp-login.php”. But, that’s an unappealing proposition best left for last resorts.

    Is there a different way to hide the login from the bot without disabling it from ordinary use?

    Use the RENAME WP-LOGIN.PHP plugin to create a different login page. Then in your .htaccess file put the following code:

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

    Thread Starter David Burkhart

    (@dlburkhart)

    sffandom: That is exactly what I was looking for. Thank you.

    I’m guessing that since the plugin doesn’t actually rename the file, your little tweak to .httaccess hides it.

    The plugin does suggest a new name for the login URL but you should change it. The file itself stays in place but WordPress (because of the plugin) intercepts all those attempts to get to it.

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

The topic ‘Security and hack attempts’ is closed to new replies.