ACL Block List contains multiple IPs and some are not blocked

Hi! I’ll look into the issues soon. From my understanding, you have two. One with ip2long() and another with saving rows into the DB. Please confirm.

Hi Gregory,

no, it all breaks down to the ip2long-Problem.
Mine as well as the mentioned/linked ones from @gingerbooch and @ableads

Everything comes from this, if IPs are not correctly converted.

… Black-List-Entries are faulty created as begin-0-end-0-IP-Entries (negative values are cut off because unsigned)

… following IP Additions to the Block-List are inserted multiple times because the check-whether-ip-is-already-in-block-list fails (due to the faulty conversion)

… ACL detections do not work anymore/intrusions are not detected/blocked because the intrusion-IP-is-in-Block-List-Range-Check fails (due to the faulty conversion).

… your repair-DB-Script/Fix-ACL does not correct the faulty IPs, because the new long-IP-Value still is converted faulty…

I hope you can add the ip2log-Fix with the next Update, because I unfortunately do still have some 32-Bit Servers from a shared hoster…

The above mentioned solution in my first post is a fix that works great. Try to test it in a 32 Bit Environment. If you don’t have one, I can give you a test-access.

Many thanks in advance!
many greets, ingo

• This reply was modified 3 years, 8 months ago by ingonieur.

Hi there,

Thank you @ingonieur for linking to us too.

I realize I gave up on this thread because the problem was remaining and I decided to block the IPs from htaccess directly instead of Cerber, to make it really work.

Anyway, seeing this discussion today I took a look at the base first, and I’m glad to say that the db entries have finally been fixed. I don’t know how nor when it happened because the last time I used the repair option it did not fix it.

Thank you,

GB

Hey @gingerbooch,

haha, yeah, good solution! And very stable, ideed. But cerber is such a great tool and of course more comfortable than a htaccess List. : )

I also had such a “magic fix” on another Server because the ACL_Fixing-Function runs every time Cerber gets a Plugin-Update and on this Server my hoster switched from faulty 32 to properly functioning 64-Bit…

But the Problem itself in the Cerber-Plugin kept and still is the same.

thanks for your message!
ingo

• This reply was modified 3 years, 8 months ago by ingonieur.

What about $wpdb->insert? Why did you mention it? I don’t follow you here.

Hi Gregory.

wpdb->insert does its job, but not with log-int-values that cannot be stored as integers on 32-bit-machines.
You use PHP ip2long, that doesn’t work either.

Within the wpdb->insert Excerpt I wanted to focus on the INTEGER Format-Mapping of the long IPs. On a 32-Bit Machine this also leads to an Integer-Interpretation/mapping where the long-Value (even if correct) possibly leads to an overflow and a resulting negative value, that cannot be stored in the UNSIGNED-Int CERBER_ACL_TABLE field.

So take “%s” instead of “%d”:
array( '%s', /* >> */ '%s', '%s' /* << INSTEAD OF %d, %d */,

Did you get the rest? Please don’t get me wrong, i don’t want to appear harsh or arrogant or sth like that… I think it might be a misunderstanding here.
I do not have a question. I found a Bug and have a Solution.
Sorry, it’s a really serious bug – I was hoping that it would get it into the new update – I really think you should implement this fix as soon as possible…

I’ll try to recap:
For many IPs the whole Cerber Blocking Mechanism DOES NOT WORK with ip2long you are using in every Block-Check. The way Cerber currently converts and saves the IPs does not work as intended on 32-Bit-Machines.
The Blocking Mechanism is one of the most important things of a Firewall, but Cerber currently does not work on 32 Bit Servers – it fails silently without error…

PHP says:
ip2long:
https://www.php.net/manual/en/function.ip2long.php

Note:
Because PHP's int type is signed, and many IP addresses will result in negative integers on 32-bit architectures, you need to use the "%u" formatter of sprintf() or printf() to get the string representation of the unsigned IP address.

And in the cerber_acl Table the long IP values (ip_long_begin, ip_long_end) are stored in UNSIGNED bigint(20). Therefore: while trying to store a negative value it becomes cutted to Zeros…

That’s why functions (and several others) like “cerber_acl_add” in dashbaord.php (also in Version 8.8.3) keep failing:

5208	if ( cerber_is_ipv4( $ip ) ) {
5209		$begin = ip2long( $ip );
5210		$end   = ip2long( $ip );
5211	}

but if you would take

	if ( cerber_is_ipv4( $ip ) ) {
		$begin = sprintf("%u", ip2long($ip));;
		$end   = sprintf("%u", ip2long($ip));;
	}

or better – a helper-function like sth I mentiones in my first post, then it would work again, because with ip2long only “0”-Values are stored in the Database, because of the unsigned Storage (cerber_acl Table Structure) and negative Values cannot be checked correctly with a “greater-or-smaller-than-IP-range-check”… so the sprintf-U-way is one of the smartest solutions I think…

I hope this makes it more clear now.
If not, please tell me, then I will again try to explain what i mean.

Many greetings and nevertheless thanks again for this great plugin! : ))

ingo

• This reply was modified 3 years, 8 months ago by ingonieur.
• This reply was modified 3 years, 8 months ago by ingonieur.