johanee

This woul require whatever user the webserver runs as to have the permissions to change iptables. Probably not a good idea, really.

It would perhaps be more reasonable to restrict the ip in the .htaccess file. I would prefer not to have to do this myself for now, but with a normal WP action it would be possible for someone else to creatw this functionality.

Yes, I’ve read the explanation and looked at the code diff. I should add MU compatability on at least this level soon.

There is no problem staying on 1.6.1 for now. And I’ll make sure to note MU changes in the changelog.

Thanks for being active here!

My working version (not availible in SVN yet) makes it an action with IP as argument.

Would you need anything else for your use case? Lockout duration?

I’m very wary of potentially logging real but misspelled passwords in cleartext, and I’m not sure what additional value it would give to most users.

I won’t add this functionality unless you have an amazing argument. ??

It would be an interesting experiment to track all attempted logins for research when you know it is a brute force attempts (for example if there is no “admin” user), but that would be a separate thing.

Ovidiu,

I’ll add an action “limit_login_lockout” to the lockout path. Look for it in version 1.7.1. I would be very careful, though, with automatic firewall rules.

Stergos,

If you have this plugin + a somewhat decent password they will never break in. It can still be very annoying though, which is reason enough to ban the IP I guess.

The change vs stock seems to be to use “manage_network_options” for the options page, which along with network activation should work well enough.

It would be possible to use this if the plugin is network activated, but I’m not sure if everyone would like that.

I have some extended MU functionality on the todo list. Basically I want to add the option to enable an MU mode with network options which tracks retries & lockouts on the network level.

Unfortunately I would also like to finaly get my 2.0 rewrite done before this, as the MU mode would otherwise result in a log format change. And there are as always a lot of things competing for my time.

As there has been no further development for a week I’ll mark this topic as resolved for now.

I’ll put it on the todo list to add a more visible warning (perhaps on all admin pages) at a probable reverse proxy setting error.

Please post again or send me an e-mail at [email protected] if you still have this problem.

As there has been no further development for a week I’ll mark this topic as resolved for now.

Please post again or send me an e-mail at [email protected] if you want any further help with your problem.

As there has been no further development for a week I’ll mark this topic as resolved for now.

If you have any further information please send me an e-mail.

Hi, sorry for the long silence!

The requirements for a custom login page is:
– call do_action(‘login_head’); in the header
– if there are any errors they must be filtered using something similar to: $errors = apply_filters(‘login_errors’, $errors);

Good luck!

If you are still around, please send the files to [email protected] !

Hi,

Would you be able to make updated .po/.mo files and send them to [email protected] ?

It seems that most WordPress blogs get a lot of login attempts these days. I get them on a number of blogs. An unfortunate fact of having a WP blog these days it appears.

I guess there are people that has automated probing for and then attempting a brute force login.

It would be interesting to set up a honeytrap style WP installation and watch what they’ll do once they are inside.

As noted above the attempts will still get logged in access logs and with tools such as Activity Monitor even when they are being blocked by the plugin.

The visitor (bot) gets a login page with information about the lockout and no attempt to login is actually made.

It is not a bad idea to block specific IP in htaccess as they can make more trouble apart from trying to log in (spam, etc).

Hi,

As far as I know there is no way to get around the enforcement, so I would be really interested in investigating this further.

Do you have any kind of access log for the time period to show what access the IP in question was doing?

Do you otherwise get working lockouts?

Would you be willing to run a version of the plugin with some extra checks to help us understand what is happening here?

Please contact me at [email protected] to investigate this further.