tsimmons

Thanks. I have gone ahead and forked it (we have numerous blogs that take advantage of some of the other features I had created including logging to fail2ban, blacklisted usernames, etc.) but haven’t posted it to the WordPress plugin repository as of yet.

Cheers,

Toby

Actually, probably a better solution is to fork my own (I don’t mean to put work on you if you don’t see the need for those customizations.) Do you have any issue with me forking a copy of your plugin?

Thanks for your work!

Cheers,

Toby

By the way, it won’t just affect people that have a web server in the same subnet as users … it will also affect folks who have an internal blog server in one internal subnet, and users in another internal subnet; Plus, whitelisting is an EXTREME no-no in our environment, since sometimes even internal users get their systems infected.

Sometimes the worst damage comes from folks inside the perimeter that get compromised.

Anyway, 2 cents.

??

You betcha. Thanks for the great work on a great plugin!

ARGH! I’m sorry for spamming this topic, but I found a loophole in my code processing already-locked-out users. It would only extend their lockout period if they had failed the required number of times within the retry period each time. This update will extend their lockout period if their IP address is locked out regardless of how many they have had in the retry period. In other words, if they get locked out, then try again five minutes later (passed the retry period but while their IP is still locked out) they will extend their lockout period.

Another reason for this is to remove any calls to isLockedOut() because it assumes the entire class C subnet should be locked out because of one misbehaving client. If we have an internal user fail to log in properly, it will lock out all local users within their subnet which is unacceptable in our environment.

Here’s the (hopefully) final diff:

181a182,188
> 		// If this IP is already locked-down, then just extend the time of the lockdown!
> 		$lockID = isCurrentlyLockedDown();
> 		if($lockID != "") {
> 			$results = $wpdb->query("UPDATE $table_name SET release_date = date_add(now(), INTERVAL " .
> 				$loginlockdownOptions['lockout_length'] . " MINUTE) " .
> 				"WHERE lockdown_ID = " . $wpdb->escape($lockID) . "");
> 		} else {
188a196
> }
205a214,223
> function isCurrentlyLockedDown() {
> 	global $wpdb;
> 	$table_name = $wpdb->prefix . "lockdowns";
> 	$ip = $_SERVER['REMOTE_ADDR'];
> 	$lockID = $wpdb->get_var("SELECT lockdown_ID FROM $table_name " .
> 					"WHERE release_date > now() AND " .
> 					"lockdown_IP = '" . $wpdb->escape($ip) . "'");
> 	return $lockID;
> }
>
375,376c393
< 	$activatestr = str_replace(WP_PLUGIN_DIR . "/", "activate_", __FILE__);
< 	add_action($activatestr, 'loginLockdown_install');
---
> 	register_activation_hook( __FILE__, 'loginLockdown_install' );
426,429c443,447
< 		if ( "" != isLockedDown() ) {
< 			return new WP_Error('incorrect_password', "<strong>ERROR</strong>: We're sorry, but this IP range has been blocked due to too many recent " .
< 					"failed login attempts.<br /><br />Please try again later.");
< 		}
---
> 		// Commented so we can extend the lockout period if they are already locked out (now handled in lockDown())
> 		// if ( "" != isLockedDown() ) {
> 		// 	return new WP_Error('incorrect_password', "<strong>ERROR</strong>: We're sorry, but this IP range has been blocked due to too many recent " .
> 		// 			"failed login attempts.<br /><br />Please try again later.");
> 		// }
443c461
< 			if ( $loginlockdownOptions['max_login_retries'] <= countFails($username) ) {
---
> 			if ( $loginlockdownOptions['max_login_retries'] <= countFails($username) || isCurrentlyLockedDown() != "" ) {

Except my diff above is backwards, DOH!

Here’s the real one:

181a182,188
> 		// If this IP is already locked-down, then just extend the time of the lockdown!
> 		$lockID = isCurrentlyLockedDown();
> 		if($lockID != "") {
> 			$results = $wpdb->query("UPDATE $table_name SET release_date = date_add(now(), INTERVAL " .
> 				$loginlockdownOptions['lockout_length'] . " MINUTE) " .
> 				"WHERE lockdown_ID = " . $wpdb->escape($lockID) . "");
> 		} else {
188a196
> }
205a214,223
> function isCurrentlyLockedDown() {
> 	global $wpdb;
> 	$table_name = $wpdb->prefix . "lockdowns";
> 	$ip = $_SERVER['REMOTE_ADDR'];
> 	$lockID = $wpdb->get_var("SELECT lockdown_ID FROM $table_name " .
> 					"WHERE release_date > now() AND " .
> 					"lockdown_IP = '" . $wpdb->escape($ip) . "'");
> 	return $lockID;
> }
>
375,376c393
< 	$activatestr = str_replace(WP_PLUGIN_DIR . "/", "activate_", __FILE__);
< 	add_action($activatestr, 'loginLockdown_install');
---
> 	register_activation_hook( __FILE__, 'loginLockdown_install' );
426,429c443,447
< 		if ( "" != isLockedDown() ) {
< 			return new WP_Error('incorrect_password', "<strong>ERROR</strong>: We're sorry, but this IP range has been blocked due to too many recent " .
< 					"failed login attempts.<br /><br />Please try again later.");
< 		}
---
> 		// Commented so we can extend the lockout period if they are already locked out (now handled in lockDown())
> 		// if ( "" != isLockedDown() ) {
> 		// 	return new WP_Error('incorrect_password', "<strong>ERROR</strong>: We're sorry, but this IP range has been blocked due to too many recent " .
> 		// 			"failed login attempts.<br /><br />Please try again later.");
> 		// }

The problem (at least with our install where we are seeing this exact issue) is that if you define a default value for image_slug (like, say you issue

ALTER TABLE wp_ngg_pictures CHANGE COLUMN image_slug image_slug VARCHAR(255) NOT NULL DEFAULT ” ;

You now get the following error:


[15-Aug-2013 19:44:48 UTC] ##### C_CustomTable_DataMapper_Driver_Mixin::_create():entered
[15-Aug-2013 19:44:49 UTC] ##### C_CustomTable_DataMapper_Driver_Mixin::_create():entered
[15-Aug-2013 19:44:49 UTC] WordPress database error Incorrect integer value: '' for column 'exclude' at row 1 for query INSERT INTO wp_ngg_pictures (exclude,description,sortorder,imagedate,alttext,galleryid,filename) VALUES (”,”,’0′,’2013-08-15 19:44:49′,’cam-jpg’,’50’,’cam.jpg’) made by …. (truncated)
[15-Aug-2013 19:44:49 UTC] ##### C_CustomTable_DataMapper_Driver_Mixin::_create():$id=
[15-Aug-2013 19:44:49 UTC] ##### C_CustomTable_DataMapper_Driver_Mixin::_create():$entity=stdClass Object
(
[exclude] =>
[description] =>
[sortorder] => 0
[imagedate] => 2013-08-15 19:44:49
[alttext] => cam-jpg
[galleryid] => 50
[filename] => cam.jpg
)

So the code is turning a blank value for exclude in the stdClass into a ” string instead of an integer. That’s as far as I got today.

Gotcha!

If I had looked more closely, I would have seen what you are doing there. Good job, by the way, the plugin looks great.

Thanks
Cheers!

Toby

I am also seeing this across our blog network — it appears they try to register twice from one IP address, then move to the next address. The only consistent thing I’ve found is the user-agent is exactly the same for every single request (so far.)

I don’t have an easy answer, but I’m thinking about putting some code in the wp-config.php to block all requests that use that user-agent. It might block some valid users but at this point, that seems more attractive than dealing with literally hundreds of bogus registrations a day.

This is in spite of using SI CAPTCHA Anti-Spam 2.7.2 and Bad Behavior 2.0.43 which are ineffective against this kind of thing. It appears to be either a very sophisticated bot-net (capable of decoding CAPTCHA) or they are using humans or a combination of both.

Good luck &
Cheers,

Toby

Oooo, ooo, ooooooo! I think I have found the fix!!!! Since merging WP and WPMU, it appears the best way to use the WP theme engine in external pages is to load wp-load.php instead of wp-blog-header.php

So instead of using:

require('./wp-blog-header.php');

You would use:

require('./wp-load.php');

I found the answer on the BBPress forum.

Try that and see if it fixes it. If you reply here, I’ll mark the topic resolved.

Cheers,

Toby

The way I overcame it was (hacking core) editing wp-includes/classes.php and changing line 477 (the first test in handle_404()) to the following:

if ( ( 0 == count( $wp_query->posts ) ) && !is_404() && !is_robots() && !is_search() && !is_home() && (!defined('WP_EXTERNAL') || WP_EXTERNAL===false) ) {

Then in my external page, I define WP_EXTERNAL at the top like this:

define('WP_EXTERNAL', true);

Hacking core stinks but this was the best solution for my purposes. I sent a message to [wp-hackers] but I haven’t seen it hit the list yet. Is that list moderated or something?

I was wrong in my previous post (apples/oranges); … comparing 2.9.2 and 3.0 on the same install on the same platform, the number of posts returned is the same (0) in external pages; however, the 2.9.2 version of wp-includes/classes.php has a test in handle_404() — line 462:

if ( (0 == count($wp_query->posts)) && !is_404() && !is_search() && ( $this->did_permalink || (!empty($_SERVER['QUERY_STRING']) && (false === strpos($_SERVER['REQUEST_URI'], '?'))) ) )

On external pages, $this->did_permalink evaluates to false, as does !empty($_SERVER[‘QUERY_STRING’]), so it falls through to send a status 200.

In 3.0, the first test is changed to (on line 477)

if ( ( 0 == count( $wp_query->posts ) ) && !is_404() && !is_robots() && !is_search() && !is_home() )

On external pages, all of these evaluate to true, so it drops into the section to send a status 404.

Not real sure what the fix might be so external pages send the proper headers. Any advice?

Thanks &
Cheers,

Toby

Not to spam this forum, but I’m slowing working through the issue and wanted to document what I’ve found so far (at least in my case on two different installs/platforms):

• In WP 2.9.2, an external page like MichaelH’s above works exactly as expected
• In WP 3.0, and external page renders but sends 404 headers and the title of the page is “Site » Page not found”

In wp-includes/classes.php, in the function handle_404() one of the tests performed to determine whether or not to send a status 404 or 200 is to count the number of matching posts — in 2.9.2, the count of posts [count($wp_query->posts)] is equal to the total posts shown on a blog page (in my case, 10); in 3.0 the total is 0, hence the reason for the 404 headers and bogus title of the page.

There is something different about the query run to find posts on these external pages, which I haven’t found yet.

Thanks &
Cheers,

Toby

I have another host (running Ubuntu 8.04 LTS and Apache 2.2.8) and it seems to do the same thing, it displays the content wrapped in the 404 template (and the headers sent are 404 as well.)

Can you verify that yours doesn’t send 404 headers?

Hmmm. This still doesn’t work for me (IIS 5.0/Windows 2000 Server using IIRF Rewrite engine) — the above code results in a 404. This worked fine in 2.9.2.

I’m still digging into it but would love to hear any advice.

Thanks &
Cheers,

Toby