In reply to mark k..

The execution of core code and the invoking of DB connections is a real issue. Someone hitting your wp-login page a thousand times a minute invokes 1000 DB connections, loads the core code 1000 times, checks your mysql version 2000 times (it happens at least twice in start up) and does a myriad of other things. All of that takes system resources. Adding a failed login tracker that access a database and writes to it is the kiss of death.

This is actually the reason I tried (and posted a TRAC about) trying to get a "hook" at the start of each of these methods that would first run a PHP file which could be maintained and changed by the end user. As an example, if you use XMLRPC to update posts on your blog, but only do so from home or your office, you could limit the access by IP or country code (example), and reject all others before they even can access the wordpress code. You could also choose to exclude certain countries, IP blocks, or the like in an easier fashion.

Yes, you can do the same with htaccess, but most users are NOT going to be able to create reliable htaccess rules on a "by file" basis. The heavy duty core programmers don't seem to understand that not everyone can write complex code.

I am thinking that the access points (wp-login, xmlrpc, wp-comments, admin/index.php etc) need to be re-written in order to limit the amount of system resources required before credentials are checked. Those access points should have, almost as the first line of code, a call to a set php file that can be maintained by a user or plug in, that could set parameters for access to those programs. Eliminating the system load from these processes would limit the DDoS effects of just a few attempted logins to a site.

Remember: more and more often, hackers and spammers are using hosting services like OVH to create droplets / virtual servers, some of which do have very high speed connections to the net. I have seen some of them doing hundreds of connection requests a second (!). If each of those connection requests lead to opening a DB connection, loading a bunch of files, checking mysql version, running wp_maintenance routines and so on, then yes, they could drag down a server pretty solidly. Get a few of them pointing at the same server, and they can effectively lock out any normal user from gaining access to your site.

This is an area I think needs a huge improvement. WordPress is a magnet for this activity, and it's less than optimal design on this level is becoming it's archillies heel.