Cidram: IP-Test does not return positive data, when custom-module in use.

[Dibbyo456]

Server information.

CIDRAM version used:

1.3.0-DEV

PHP SAPI used:

fpm-fcgi

PHP version installed:

7.1.11

Operating system used:

Linux 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64

---

Issue

When using custom-module IP-Test does not check against the custom-module.

Expected behavior

The IP Should show blocked.

Actual behavior

The IP returning positive.

Steps to reproduce the behavior

Enabled Hostname Blocking
Module - Hostname Added
IP Test Result - http://prntscr.com/hcquiq

The actual hostname blocking working fine, but the IP-Test does not check the IP with custom module.

[Maikuolan]

Technically, this behaviour could be argued as not a bug per se, due to the description of the IP test page:

The IP test page allows you to test whether IP addresses are blocked by the currently installed signatures.

(In the sense that, although signature files and modules are both described as components, signature files and modules are not exactly the same thing; although, that said, whether we think of "signature files" when we see "signatures", or just signatures in the general sense, it could be argued both ways; both signature files and modules contain "signatures" after all, so, eh; by the meaning of the letter, it could be considered a bug, so, you're correct here). '^.^

In short, the IP test page was originally intended to test against signature files. But, I think it would be a good idea to be able to test IPs against modules too, due to that modules can influence which IPs are blocked by way of hostname signatures and such things (and so, testing against signature files alone, mightn't be enough to truly indicate whether an IP is blocked).

Marking this issue as a bug and working on a fix at the moment. Should have something ready soon. Thanks for reporting this. 😄 :+1:

[Dibbyo456]

Hahaha.. Thank you. Honestly, I did not read it was originally intended to only check against database. Anyway, glad I reported it. :)

One more thing, in the Forum, you stated you will write a proper doc for hostname blocking, but you never did, maybe you forgot. Anyway, I'm currently using caxanga334's instruction, Works fine. But something coming from the developer, is more trustworthy. :)

[Maikuolan]

Committed an update just now; Let me know how it goes. :-)

Works fine. But something coming from the developer, is more trustworthy. :)

Definitely. I'll get that done hopefully soon, when I've got some more spare time.

[Dibbyo456]

@Maikuolan I don't know what exactly happened, but after updating, the custom hostname blocking does not working anymore. I doubled checked everything, everything in perfect place.

[Maikuolan]

Hm, that's definitely very strange. Are there any error messages at all?

[Dibbyo456]

Nope. nothing, I did not touched anything.. I checked config.ini everything is same.

Also, IP test returning positive result. I mean not blocked.

[caxanga334]

My custom hostname signatures are working fine, only the IP test page doesn't show the IP is blocked.

[Maikuolan]

I wonder if something didn't update properly, or something broke during the update? I haven't been able to replicate the problem on my end; On my end, on my local test installations, as of the latest update, when using a module running a hostname block for boxmailbox.com, 185.189.56.118 is showing as blocked when testing it with the IP test page (when "also test against modules" is selected).

Exact signature used in my local test installations:

$Trigger(strpos($CIDRAM['Hostname'], 'boxmailbox.com') !== false, 'module_custom', 'Banned hostname. Access denied.');

Response on the IP test page:

Can you check whether there's any error_log file in the base directory for the installation? If an error_log file exists, it might be able to give us some clues as to what's gone wrong.

[caxanga334]

Tried using the signature you used for testing and it doesn't work (in the IP test page). Also no error_log files.

[Dibbyo456]

Same here, no error_logs. I'm going to make a fresh install.

[caxanga334]

Maikuolan I tested on a local fresh cidram install.
Hostname blocking is working, only the IP test page doesn't show it's blocked.

CIDRAM version used: 1.3.0-DEV
PHP version used: 7.1.11
SAPI used: cgi-fcgi
Operating system used: Windows NT USER-PC 6.1 build 7601 (Windows 7 Professional Edition Service Pack 1) i586
Web Server: Nginx 1.13.7

I downloaded CIDRAM 1.2.0 then updated using the front-end. Also no errors in the log.

[Dibbyo456]

After making a fresh install, hostname blocking now working again, but IP-Test page still returning "NO"

[DanielRuf]

@Maikuolan can you reproduce it? If yes try git bisect.

For example

git bisect start
git bisect bad
git bisect good CommitHashOrTagOfLastWorkingHead

[Maikuolan]

Confirmed. On my old test copies (which should've been up-to-date and should've corresponded to what's available in the repository, as I update both directly from my dev copy), the problem isn't replicated, and everything works properly. When I download the latest codebase from the repository though, and make a new test copy from that, the problem is replicated exactly as @Dibbyo456 has mentioned (module working correctly, but IP reporting as not blocked when testing via the IP test page). Sorry for the delay. Now that I have two different test copies though, one which works and one which doesn't, it shouldn't be too difficult to compare them to figure out what's different, and thus, what's gone wrong here. I'll reply again shortly.

[Maikuolan]

I think I found the problem.

There weren't any differences at all between the code of my two different test copies, but there were some very small configuration differences. In particular, in the copy that worked correctly, I had:

protect_frontend=false

..and in the copy that didn't work correctly, I had:

protect_frontend=true

It isn't immediately obvious why that would cause such a problem, and itself, shouldn't cause this type of problem. However, what it meant was that the modules were running both before testing occurred (when the user accesses the IP test page), as well as during testing (when testing each IP), and if we look at the specific code used by the modules for fetching hostnames, we find this:

/** Fetch hostname. */
if (empty($CIDRAM['Hostname'])) {
    $CIDRAM['Hostname'] = $CIDRAM['DNS-Reverse-IPv4']($CIDRAM['BlockInfo']['IPAddr']);
}

I.e., the hostname was only being fetched if the variable containing the hostname was empty (i.e., if no hostname had been fetched yet). This basically meant that if protect_frontend was true, the IP test page would always think that the hostname for each IP was the same as whoever was doing the testing (which is obviously wrong, and a bug). Conversely, if protect_frontend was false, the problem would still exist if testing multiple IPs anyway, because the IP test page would always think that the hostname for each IP was the same as whatever the hostname was for the first IP being tested.

My solution to this problem (and what I'm hoping should be a permanent fix for this bug), is to add the following code snippet to the SimulateBlockEvent closure:

        /** Reset hostname (needed to prevent falsing due to repeat module calls involving hostname lookups). */
        $CIDRAM['Hostname'] = '';

..which'll basically empty the hostname variable before each IP is tested, thus ensuring that new hostname lookups should occur per each IP.

About to commit the fix just now. When you've got a chance, update, and let me know whether the problem is resolved. :-)

[Dibbyo456]

Wow. Read every word & understood. Thank you for taking the time & having it well explained.
Updated to the latest version, everything working now.

[Maikuolan]

Awesome! Glad to hear that it's working now, and happy to help. :-)

[Dibbyo456]

@Maikuolan Found another bug.
I set HTTP_CF_CONNECTING_IP in ipaddr in the config.ini but in the front-end general->ipaddr: still shows REMOTE_ADDR
Also,
Updatinggeneral->ipaddr: from the front-end does not work.

[DanielRuf]

Please open a new issue.

[Dibbyo456]

Opened.