CIDR format in block list not recognized. For example 114.96.0.0/19

Thanks for finding this.

I finally had time to look at it. There was a problem in using PHP 5 and another one with using 32 bit vrs 64 bit versions of PHP. I now have a version that works on all my test hosts, so I think it is good to go.

You can download the latest version from my website
https://www.blogseye.com
There is a link to the beta test items at the top of the page.

If you have the Stop Spammer plugin updater installed you can use that to automatically install it.

Please report back if it is working on you installation.

Keith

I did install the newest beta three times, and 114.97.201.8 is still ending up today in my good cache, even when it is already also hardcoded without a mask in my deny-list since yesterday by marking it bad in my good cache and not visible in my good cache today. Quite strange. I’ll try the Diagnostics this weekend myself to see whether the isolated routine works.

Diagnostics still only recognizes 114.97.201.8. 114.96.0.0/19 does not show up.

The part of the code that seems to do this match, in stop-spammer-registrations-plugin/classes/be_module.class.php doesn’t differ between the productional and the beta version, so probably something is wrong with the beta updater, or we are looking at a different piece of code. I would expect line 89 to do the final match. The code above that line looks like it ought to.

By the way, the productional PHP-build of my provider we talk about is
PHP Version 7.0.3-5+deb.sury.org~trusty+1
Linux web20 3.16.0-59-generic #79~14.04.1-Ubuntu SMP Mon Jan 18 15:41:27 UTC 2016 x86_64

which is freely available on a foreign site.

The manually uploaded plugin does contain a difference. I am going to try the Diagnostics again.

Still the diagnostics of this new version doesn’t recognize 114.97.201.8 as 114.96.0.0/19

I now look at this version:

// searching for an cidr in the list
list($subnet, $mask) = explode(‘/’, $search);
$x2=ip2long($needle) & ~((1 << (32 – $mask)) – 1);
$x3=ip2long($subnet)& ~((1 << (32 – $mask)) – 1);
if ($x2 == $x3){
return “$searchname:$reason”;
}

Inspired by your previous version I would change the logic of the mask

& ~((1 << (32 – $mask)) – 1);

with

| ((1 << ($mask)) – 1);

That works on my prompt for this specific IP-check.

However, when I modify this piece of code in the plugin it doesn’t work for the same address. On the prompt I tested it with this php-program:

<?php
list($subnet, $mask) = explode(‘/’, ‘114.96.0.0/19’ );
$x2=ip2long(‘114.97.201.8’) | ((1 << ($mask)) – 1);
$x3=ip2long($subnet)| ((1 << ($mask)) – 1);
if ($x2 == $x3){
echo “match”;
} else
{ echo “no match”;
}
?>

— Diagnostics still only recognizes 114.97.201.8. 114.96.0.0/19 does not show up

It would not 114.96.0.0/19 is range from 114.96.0.0 to 114.96.31.255

I spent over an hour debugging and could not get it to work, but the code was OK, the data was wrong.

Keith

I guess you’re right.

And still it isn’t working with the new version.

I have 114.96.0.0/13 in my block list.

Now two new entries have entered my log:

2016/07/16 18:40:11 [email protected] 114.97.58.144 fifa 17 points /wp-admin/admin-ajax.php Good Cache:114.97.58.144
2016/07/16 18:35:33 [email protected] 114.97.58.144 buy fifa 17 coins /wp-admin/admin-ajax.php allow admin-ajax.php

Why is allow admin-ajax.php adding this blocked IP-address to my Good cache?

If you try the ip 114.97.58.144 in the “diagnostics” window you can see where it is rejected by the black list IP check as well as the SFS lookup.

Either of those should have blocked the IP. IP checking is working and the IP is clearly bad for those two reasons.

The “allow options” are executed first. For instance the “Good Cache” will accept the IP and not bother to check further. Check to see if any of the allow functions will let them slip through.

It could be that the captcha is turned on and the user is correctly entering the captcha. Turn off Captcha to check.

It could be that one of the other allow options is letting the person through.

I don’t know why the code is going to admin-ajax.php. This is not standard for logins or comments.

The plugin won’t work with JetPack protection, and it won’t work with other spam plugins. It will not work with plugins that do custom logins. It does not work with woo-commerce.

The plugin is designed to work with standard WordPress installations. It cannot work if you use a plugin that bypasses the WordPress login and comment screens.

Keith

It does show the reject by SFS lookup and IP check

chkblip : Deny List IP:114.96.0.0/13
Good Cache:114.97.58.144

JetPack doesn’t ring a bell. However I have some speed optimizations which can sometimes interfere with normal functioning of plugins, a combination of Varnish cache and Merge, Minify & Refresh.

I will experiment somewhat with my plugins, I had two Captcha plugins, one active, Really Simple CAPTCHA for Contact form 7, and one inactive which I deleted right away (from Bestwebsoft).

By the way, I also have the Heartbeat Control plugin active, with the settings

– Allow only on post edit pages.
– Use default

Probably while things end up in the Good cache the Heartbeat Control plugin, specially designed for blocking unwanted admin-ajax.php, is still keeping the spammers from my site after entering the Good cache. I wonder whether their order in the plugin-list influences the order of their execution.

I now changed Really Simple CAPTCHA for Contact form 7 to reCAPTCHA. Contact form 7 has changed the preferred CAPTCHA, so I adapted it.