What this doesn't prevent: Brute Force
all it does is prevent automatic brute force attacks?
No. This does not prevent brute force attacks.
In a brute force attack, an attacker has control over all parameters of the HTTP request. This includes the referer. As the attacker can send arbitrary referers, this does not prevent brute force attacks. (Almost) all brute force tools will allow the setting of a referer, and setting the site itself as a referer is pretty standard.
Mechanisms that do protect against brute force would be banning or throttling on an IP or username basis, as well as captchas.
What this might be intended to prevent: CSRF
This code might have been indented to add a referer check to all POST requests to the admin area. If the referer is not valid, the request is rejected.
In a CSRF attack, an attacker forces a victim to perform a state-changing POST request. This can eg happen by posting HTML and Javascript code at attacker.com, which then automatically sends a request to victim.com once an authenticated victim visits the site.
Referer checks are one mechanism to protect against CSRF. As only victim.com is accepted as a valid referer, an attacker cannot force the victim to send a request from their own domain.
Of course, WordPress has its own CSRF protection (via anti-CSRF nonces). But it might not catch all cases, and the security of plugins depends very much on the plugin developer.
An additional referer-check can help prevent CSRF vulnerabilities in WP core, and especially in plugins, from being exploitable.
Of course, if this was the intention, the code is bugged. The $
in RewriteCond %{REQUEST_URI} ^(.*)?wp-admin$
prevents the check for most requests.
The check can also easily be bypassed. The following referers would be accepted:
Referer: http://example.com.org
Referer: http://not-example.com
Referer: http://notexample.com
Referer: http://attacker.com/example.com
[...]
To add anything to the security of the site, these two issues would need to be fixed first. The code could also be further improved by not being restricted to POST requests (in poorly-written applications, GET requests may change server-state as well, or POST requests may be transformable into GET requests). As the check only applies to administrators, this should not restrict usability.