Title: Another brute force attack thread
Last modified: August 21, 2016

---

# Another brute force attack thread

 *  [zimisme](https://wordpress.org/support/users/zimisme/)
 * (@zimisme)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/)
 * With all the attacks going on we see a number of servers increasing their work
   load because all the login attempts trigger disk i/o. So we decide to block all
   attempts not coming from an approved ipaddress.
 *     ```
       <FilesMatch "wp-login.php">
       order deny,allow
       deny from all
       Allow from 1.2.3.4
       </FilesMatch>
       ```
   
 * Usually this works. The site’s accesslog file will show the following:
 * `4.3.2.1 - - [30/Aug/2013:11:23:24 +0200] "POST /wp-login.php HTTP/1.1" 403 431"
   http://whatchamacallit.fake/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; WOW64;
   rv:18.0) Gecko/20100101 Firefox/18.0"`
 * Note the ‘403’ after the post statement. Apache throws a 403 error (Forbidden),
   as it should be.
 * However, sometimes when we put up this block, we get a different result:
 * `[30/Aug/2013:11:46:40 +0200] "POST /wp-login.php HTTP/1.0" 302 473 "thingamabob.
   fake/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/
   19.0"`
 * Note the ‘302’ after the post statement. Apache does a redirect to the wp-login.
   php file, which puzzles me, because we blocked the access. Yet, it redirects 
   and redirects and redirects and redirects… about 9 – 12 times. I have yet to 
   figure out why this happens. The load on the server doesn’t deminish though, 
   it stays the same.
 * Removing wp-login.php doesn’t help either. For some reason going to [http://whatever/wp-login.php](http://whatever/wp-login.php)
   doesn’t actually call the /wp-login.php file.
 * Some sites have the default .htaccess as posted by the wordpress installation,
   namely
 *     ```
       # BEGIN WordPress
       <IfModule mod_rewrite.c>
       RewriteEngine On
       RewriteBase /
       RewriteRule ^index\.php$ - [L]
       RewriteCond %{REQUEST_FILENAME} !-f
       RewriteCond %{REQUEST_FILENAME} !-d
       RewriteRule . /index.php [L]
       </IfModule>
   
       # END WordPress
       ```
   
 * Some sites throw the 403, some do the 302.
    When removing the last rewrite rule(
   RewriteRule . /index.php [L] ) the 302 redirects stop, but when someone requests
   a different page on the site, you get a 404. So, this then doesn’t help.
 * I read somewhere that editing wp-includes/functions.php and adding
 *     ```
       update_option('siteurl','http://siteurl');
       update_option('home','http://siteurl');
       ```
   
 * should fix this, but all it does is break the site.
 * And no, we don’t run mod_security. It is not an option right now. How does one
   fix that 302 off wp-login.php? Anybody?

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

 *  Moderator [t-p](https://wordpress.org/support/users/t-p/)
 * (@t-p)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080942)
 * Codex: [http://codex.wordpress.org/Brute_Force_Attacks](http://codex.wordpress.org/Brute_Force_Attacks)
 *  Thread Starter [zimisme](https://wordpress.org/support/users/zimisme/)
 * (@zimisme)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080943)
 * I already did. Many times. It does not answer the question why some sites ignore
   the wp-login.php file completely and thusly trigger a 302 instead of a 403. as
   I describe in my previous post.
 *  [esmi](https://wordpress.org/support/users/esmi/)
 * (@esmi)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080949)
 * You’d need to ask the hosts about this. That’s nothing to do with WordPress.
 *  Thread Starter [zimisme](https://wordpress.org/support/users/zimisme/)
 * (@zimisme)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080950)
 * It has everything to do with wordpress, and I am the host.
 *  [esmi](https://wordpress.org/support/users/esmi/)
 * (@esmi)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080951)
 * No – WordPress does not dictate what header is sent. The server does that.
 *  Thread Starter [zimisme](https://wordpress.org/support/users/zimisme/)
 * (@zimisme)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080968)
 * Read my first post. Some sites serve a 302, some a 403. Same server. Same .htaccess.
   So it’s wordpress.

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

The topic ‘Another brute force attack thread’ is closed to new replies.

 * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
 * 6 replies
 * 3 participants
 * Last reply from: [zimisme](https://wordpress.org/support/users/zimisme/)
 * Last activity: [12 years, 9 months ago](https://wordpress.org/support/topic/another-brute-force-attack-thread/#post-4080968)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics
