wp3zzz

Thank you!
It’s not the hosting provider, I am the hosting provider.
The issue is that this is a brand new domain name purchased from namecheap and the DNS is not set yet, the host command returns this ip address “162.255.119.254” which i presume is some kind of namecheap landing server, and the command
time php -r ‘gethostbyaddr( “162.255.119.254” );’
take forever : bingo. When I plug in the public ip address of the server, it’s lightning fast. So once this goes to production the issue would have cleared up, and since it’s inaccessible in the meanwhile it doesn’t need security yet.

I’m using a local hosts file entry on my windows PC to override the public DNS during development, but that doesn’t help the hostname lookup on the server itself. Maybe I just need to make a temporary ‘hosts’ entry there to resolve it. Anyway, thanks again – I REALLY appreciate it, this is the kind of thing that can drive me crazy!

You are brilliant. I commented out the call to “is_behind_cloudproxy” in function initialize() and now the site loads super fast the way it should. So I must assume this new server of mine has some bad RDNS or something along those lines, that I need to fix up.

I really appreciate not only that you responded twice within the same day but actually gave me the exact solution.

Thank you sir!

I clicked to force the scan and watched the server load climb all the way up to 0.09 (from 0.00) and now I see the last scan date shown.

Now with the plugin activated, loading the dashboard and site take about 9 seconds. Every click or change inside the dashboard takes this long, it’s unbearable.

I have added no themes, no plugins (other than sucuri) and no content.
I really like sucuri and am using it on several other sites (versions prior to 1.7.9 however) wish I could use it on this new site. I’d be glad to help test or troubleshoot this issue, but this is unusable for me as is.

I deactivated sucuri and now the site and dashboard load within 1 second again.

Thanks for the suggestion, tried that but got the same result. Now I enabled debug in wp-config and see this;

Warning: mysql_connect(): mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD(‘your_existing_password’). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file in /wp-includes/wp-db.php on line 1141

not sure why only this user is affected, but thanks to this clue, I finally did find the solution. In my.cnf was ‘old_passwords=1’, so I had to comment it out and then had to update the user’s password as above, flush privileges, woo hoo it works!

The goal of my request isn’t to prevent the brute force attempts themselves (which of course would be nice) but to prevent servers from getting overloaded by them, and in that regard I believe it will alleviate what I’ve been seeing. I’m going to give that plugin a try.
Thanks for the links and info!

Thanks Andrew – what sort of security measure should the hosting provider implement; is there a name or a specific product that can tell this brute force attack on wordpress from a legitimate request?

1) if they’re blocked for 5 seconds, they won’t be locked out. If they think they are, tell them to “try again now”.

2) What do you mean the server should be protecting you, how does it know a legitimate login request from a non? WordPress itself is processing the login request. It could fairly easily do something to lock itself for 5 seconds before processing the next request.