CIDRAM log entries with no IPs

[Gaffnet]

Hi, Maikuolan

I've been seeing these CIDRAM log entries that have no IPs recorded:

ID: 1439
Script Version: CIDRAM v0.1.2
Date/Time: Thu, 17 Mar 2016 08:09:47 -0400
IP Address: 
Query: 
Referrer: 
Signatures Count: 1
Signatures Reference: Invalid IP!
User Agent: Wget/1.15 (linux-gnu)

ID: 1442
Script Version: CIDRAM v0.1.2
Date/Time: Thu, 17 Mar 2016 08:18:54 -0400
IP Address: 
Query: 
Referrer: 
Signatures Count: 1
Signatures Reference: Invalid IP!
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0

I didn't find correlating entries in the web server logs that might give me a clue on what triggered these entries. I don't have any CRON events that correlate either.

I'm on a typical shared hosting plan so my investigative means are severely limited. My site is Wordpress-based and working through CloudFlare.

Any ideas on what these blank IPs might be?

Thanks

[Gaffnet]

I think I may have found the problem and it was an error on my part.

When I was copying over country blocks from ZBBlock to CIDRAM, I had missed editing a few comment lines in the ZBBlock .INC file that were prefixed with double forward slashes.

I'll keep an eye on the log files to confirm.

[Maikuolan]

Cool, cool. :-)

Sorry for the delayed reply, BTW; I got caught up with some other things this morning and didn't get the chance to reply earlier.

This certainly sounds like an usual issue.

I'm not entirely sure if commented lines could be the culprit here, in that anything in the CIDRAM signature files not recognised by CIDRAM as being signatures should normally just be treated and regarded as comments (and thus ignored, without any influence on the overall behaviour of CIDRAM). Though, for lack of any other ideas at this point, I wouldn't want to dismiss anything too hastily.

The fact the the User Agent and Date/Time fields are still being populated would suggest that these entries aren't merely dummy entries (meaning that, CIDRAM isn't just randomly dumping entries to the logfile from nowhere; these entries must actually correlate to some requests made from somewhere), but, that said, it's rather unusual to receive actual requests from somewhere without there being any accompanying IP address for these requests (and even if CIDRAM believed the IPs were invalid, it should still nonetheless include the relevant IP addresses in the logfile entries, which appears to have not happened in these instances).

_If_ this was happening for _all_ requests, generally, my suggestion would be to double-check the configuration file to make sure that the ipaddr directive had been set correctly, but, considering that some requests are coming through normally (and that, therefore, this isn't happening for _all_ requests, but just _some_), clearly, the ipaddr directive couldn't have been set _incorrectly_ (because if it was absolutely incorrect, we would expect CIDRAM to be blocking all requests and we would be expecting nothing to be getting through at all).

Just to put a theory out there (and this is entirely speculative; I don't know for certain if this is the true cause of the problem and don't have any direct evidence of this, either).. Your sites wouldn't by any chance be receiving traffic via multiple IP source headers (IP source headers in the sense of which server headers contain the source IP address for requests), would they? This could be possible, in theory, if, perhaps, you were somehow simultaneously receiving traffic proxied through Cloudflare and/or a similar proxy service and receiving traffic _not_ proxied through such a service (which would mean you would simultaneously have the Cloudflare IP header as well as the normal direct IP header), or could, in theory, be possible if your sites were somehow being powered by multiple servers simultaneously (and whereby one server handles IPs one way and the other server handles IPs in a different way). This theory is a bit of a long-shot (and I'm not 100% sure whether it's actually a viable or possible theory anyhow), but, it's just something that came to mind.

I always try to replicate these types of problems on my end whenever I read/hear about them, both to try to get to the bottom of the problem, as well as for the chance that the culprit could possibly be my own _faux pas_ via some coding bug somewhere (as, of course, with any project and for any developer working on said project, can potentially be the case, and attempting to replicate the problem will usually determine this, one way or the other, much more quickly than would otherwise be the case). I haven't yet been able to replicate this particular problem, but I'll keep at it and reply here again a bit later to let you know how it goes (and whether I can think of other possibilities while I'm at it). :-)

[Gaffnet]

Your sites wouldn't by any chance be receiving traffic via multiple IP source headers (IP source headers in the sense of which server headers contain the source IP address for requests), would they?

Yes! This is the cause!

All my sites are accessed via subdomains according to topic and are proxied through Cloudflare. But I have no site installed for the top level domain, so naturally the TLD wasn't configured to be proxied in Cloudflare.

Since I don't publicly reference my top level domain at all, I'm reasonably sure anything that hits up my top level domain directly is typically automated, black hat or generally unwanted in nature.

My top level domain had become an impromptu honeypot, so I had installed a non-Cloudflare configured version of ZBBlock as another way to monitor malicious traffic on my top level domain.

When CIDRAM came out, I began hooking it alongside where I had hooked ZBBlock, completely forgetting that it was necessary to set up a non-Cloudflare configured installation of CIDRAM specifically for the TLD so the correct IPs could be determined via REMOTE_ADDR instead of HTTP_CF_CONNECTING_IP.

_facepalm_

[Maikuolan]

Ah, cool cool. That's that answered then. XD

Shall I mark this issue as closed? :-P

[Gaffnet]

Sure, or I can do that. ^_^

[Gaffnet]

Hi, Maikuolan

CIDRAM is still recording log entries with no data. This time, I've been able to correlate it with a cron event being activated every 15 minutes via CPanel cron. The cron event is fired using this shell commands:

cd /home/myuserdir/public_html/mysitesubdir; php -q wp-cron.php > /dev/null 2>&1

I also have the option of calling wp-cron.php via CURL, if that matters any...

Can CIDRAM be prevented from recording these CRON events?

EDIT: Should I remove the Quiet mode (-q) switch which suppresses headers?

[DanielRuf]

Cronjobs run locally and have the IP address of the origin server (yours) and are not routed through CloudFlare. Some fallback to REMOTE_ADDR can be added when the current value is not set and if a different header field than REMOTE_ADDR is used.

Same is also when someone directly sends requests to the original origin IP and bypasses CloudFlare (you can prevent this using some .htaccess rule, you can see it in the .htaccess file here: https://github.com/DanielRuf/daniel-ruf.de ).

Check the headers in the accesslog entries created by the cronjob. The IP should be there. The quiet mode of PHP just suppresses the output of the script exrcuted by the cronjob. You can not "remove" the IP header from packets.

-q / --no-headers just suppresses the output, nothing more

http://php.net/manual/en/features.commandline.options.php

http://stackoverflow.com/questions/5777792/what-does-it-mean-to-run-php-in-quiet-mode

[Maikuolan]

Good point about the fallback.

I'm going to add that to the to-do list for v0.2.0 and try to code something to that effect; Makes sense.

[DanielRuf]

Apache still and always logs the IP of all requests ;-)

[Maikuolan]

The latest commit (committed about ~10 minutes ago) includes some modified code in the loader to serve as a fallback for missing IP address server variables (loader.php:L85-L93).

I've tested it locally and it seems to work correctly for me, but it hasn't yet been tested live.

Would you be able to give it a try and let us know how it goes?

[Gaffnet]

Would you be able to give it a try and let us know how it goes?

Sure. I've just installed it, will let you know how it goes.

EDIT: Unfortunately, CIDRAM is still recording empty log entries for CRON events.

[DanielRuf]

Create a test.php file with the following content and run it with a cronjob.

<?php
ob_start();
var_dump($_SERVER);
$result = ob_get_clean();
file_put_contents("test.txt", $result);

And create an empty test.txt file.

Also try to access your website through its IP to see if the request gets logged.

Cronjobs (using wget and curl) send normal HTTP requests.

Is the file cached? Try to clear all caches on the server (restart?), CloudFlare cache and check your accesslog for the cronjob requests.

[dev-101]

I would log entire header content, just to be sure what we are dealing with. There are different fields that could hold IP information.

var_dump($_SERVER['REMOTE_ADDR']);

with

var_dump($_SERVER);

and report when you catch something (but preferably from cron, not real visitor)

---

I think both isset() and empty() should be checked, because variable could be set with empty value and still "pass" the check.

[DanielRuf]

I think both isset() and empty() should be checked, because variable could be set with empty value and still "pass" the check.

I was wrong, emptyalso checks !isset ;-)

Just empty is needed, see here http://stackoverflow.com/a/4559976/753676

[Gaffnet]

Create a test.php file with the following content and run it with a cronjob.

Here's the output of test script as generated with a cronjob:

text/plain wp-crontest.txt 
ASCII text
array(16) {
  ["SHELL"]=>
  string(31) "/usr/local/cpanel/bin/jailshell"
  ["MAILTO"]=>
  string(19) "[email protected]"
  ["USER"]=>
  string(7) "myhostingacctusername"
  ["PATH"]=>
  string(13) "/usr/bin:/bin"
  ["PWD"]=>
  string(34) "/home/myhostingacctusername/public_html/mysitesubdir"
  ["LANG"]=>
  string(11) "en_US.UTF-8"
  ["SHLVL"]=>
  string(1) "1"
  ["HOME"]=>
  string(13) "/home/myhostingacctusername"
  ["LOGNAME"]=>
  string(7) "myhostingacctusername"
  ["OLDPWD"]=>
  string(13) "/home/myhostingacctusername"
  ["_"]=>
  string(12) "/usr/bin/php"
  ["PHP_SELF"]=>
  string(0) ""
  ["REQUEST_TIME_FLOAT"]=>
  float(1458486423.4726)
  ["REQUEST_TIME"]=>
  int(1458486423)
  ["argv"]=>
  array(1) {
    [0]=>
    string(15) "wp-crontest.php"
  }
  ["argc"]=>
  int(1)
}

Also try to access your website through its IP to see if the request gets logged.

Turned off routing in Cloudflare and accessed my site via IP, the site loads and the request is logged in the access logs.

Is the file cached? Try to clear all caches on the server (restart?), CloudFlare cache and check your accesslog for the cronjob requests.

I can't restart the web server since I'm on a shared host. I've cleared Cloudflare cache entirely and created a Cloudflare Page Rule to prevent any file starting with "wp-" from being cached.

I've cleared the cache in Wordfence (it's an app level firewall plugin that does caching) and made a cache rule exception so files beginning with "wp-" are not cached.

Neither the Wordpress cronjob nor the test script cronjob appear in the access logs.

I get a confirmation email when the Wordpress cronjob fires, with the contents being the CIDRAM error page, indicating that CIDRAM blocked access to wp-cron.php.

I don't get an email notification when the test script cronjob fires but I confirmed that the test script cronjob is working by looking at the file modification date/time and the REQUEST_TIME_FLOAT and REQUEST_TIME variables within the text file. The test script output file is indeed being updated on schedule.

[DanielRuf]

Thanks for the feedback, you can revert the changes now and remove the testfile.

Wordfence is mostly just some auditing, if you want some good WAF, use NinjaFirewall ;-) https://websectools.com

Seems no IP address is actually logged as this is PHP CLI as it seems.

http://stackoverflow.com/a/2339149/753676

I can not test this here as I can mostly create cronjobs which point to a public URL and which also create the entries in the accesslog with the IP. Would have to use some exec() wrapper here.

If PHP is running in CLI, CIDRAM can use this http://stackoverflow.com/a/1814627/753676

Other alternatives are ifconfig and other shell commands.

Reference: http://php.net/manual/de/reserved.variables.server.php#92121

[Maikuolan]

Hm.

Ideally, if PHP is running in CLI, CIDRAM shouldn't ever block anything anyway (because it's really only intended to block requests that arrive via a webserver, and these types of requests don't normally arrive via CLI).

The exact code responsible for blocking "invalid IPs" in CIDRAM could be controlled and/or optionally disabled reasonably easily by encapsulating it with a small condition check, so, maybe what I should do is just create a new directive to be added to the configuration to optionally enable/disable the blocking of "invalid IPs"? This could help in this situation and more broadly with potentially similar compatibility issues.

If we did this, I think, probably, it would be best to have blocking invalid IPs disabled by default, but have it possible to enable it via the configuration.

Thoughts?

[DanielRuf]

Why not just check if the current environment the script is executed in is cli? http://stackoverflow.com/a/2421484

As this is just a problem with PHP CLI and we should not blindly disable this if the IP is somehow invalid, which would make debugging harder.

But we should properly test this: http://stackoverflow.com/questions/933367/php-how-to-best-determine-if-the-current-invocation-is-from-cli-or-web-server#comment24662227_933375

http://stackoverflow.com/questions/933367/php-how-to-best-determine-if-the-current-invocation-is-from-cli-or-web-server

[Maikuolan]

It's possible that php_sapi_name() might be reporting something other than "cli" in this case, because technically, this should already be accounted for by the loader (php_sapi_name() value saved to a variable at loader.php:L131 and then used at loader.php:L153 prior to calling the output generator).

@Gaffnet : Would you be able to save this to a new PHP file:

<?php
echo php_sapi_name();

..run it via a cron or via your CLI, and let us know the results? Cheers. :-)

(When we know the results, we might be able to use this to refine the code currently used to determine whether we're in CLI).

[DanielRuf]

It's possible that php_sapi_name() might be reporting something other than "cli" in this case,

Sure. Let's see what @Gaffnet gets as result and we can improve this a bit, other php_sapi_names values can then be added to the check.

[Gaffnet]

Using a cron event, php_sapi_name returns the following result:

cgi-fcgi

[Maikuolan]

Cheers. :-)

I'll write a fix for this now; Will reply again when committed.

[Maikuolan]

..And committed (1 updated file, "loader.php").

Give this a try and let us know how it goes.

[DanielRuf]

There might be more =) http://stackoverflow.com/a/933376/753676

Shouldn't this be cgi instead of cli? https://github.com/Maikuolan/CIDRAM/commit/009a42f37f5ed565773c36c530627156f516b3eb

[Maikuolan]

Eep.. Good catch; You're right.

Late night fumble on my part. Will re-fix again now! XD

[Maikuolan]

Okay; Re-committed. Should be good now.

(That list you've linked to could be very useful; May add more in the future, after checking through each item carefully).

[Maikuolan]

Hmm.. Possible problem.

I just double-checked this solution against my local Nginx server, and it doesn't work there. On my local Nginx server setup, cgi-fcgi seems to be returned for calls made to PHP from the server (so, it's possible that this value may be ambiguous, in that it may indicate CLI for things like cron but may still indicate a web-app and/or server request for some server software).

May need to refine this further. >.x

[DanielRuf]

Mh, or add some config value where users can set it to the right value for their server?

[Maikuolan]

..Maybe we could leverage this?

  ["argv"]=>
  array(1) {
    [0]=>
    string(15) "wp-crontest.php"
  }

I've noticed that the $_SERVER['argv'] variable is always set whenever I try running PHP scripts in CLI-mode on my own PHP installation, but is never set whenever I try running anything through the server or as a web-app, and I've noticed this variable in the $_SERVER dump supplied by Gaffnet above.

Something like a if (isset($_SERVER['argv'])) { // We're in Cli. } else { // We're *NOT* in CLI. }.

[DanielRuf]

I've noticed that the $_SERVER['argv'] variable is always set whenever I try running PHP scripts in CLI-mode on my own PHP installation

This could be definitely useful.

[Maikuolan]

I'll sync a new commit to leverage this; Might have better luck this way (fingers crossed, third shot lucky).

[Maikuolan]

..And committed.

[Maikuolan]

@Gaffnet

Sorry about the messing around there. Should be able to re-test now, and it should, hopefully, fix the problem. When you've got the chance, let us know how it goes. :-)

[Gaffnet]

The no-IP log entries are no longer written to the log.

The cron event notification email contains the CIDRAM "Invalid IP" error page and it has empty fields. No IP address, no User Agent etc...

Also, I tried test banning my IP but CIDRAM didn't block me.

[DanielRuf]

The no-IP log entries are no longer written to the log.

Which log?

There is no IP when running PHP CLI, the code runs on the server (localhost).

The cron event notification email contains the CIDRAM "Invalid IP" error page and it has empty fields. No IP address, no User Agent etc...

You mean the latest commit did not fix this?

Also, I tried test banning my IP but CIDRAM didn't block me.

What exactly did you do?

[Gaffnet]

Which log?

The CIDRAM log file, the one specified in config.ini under the 'general' section.

This latest March 21st version of loader.php did not create log entries for the cron jobs in the CIDRAM log. In previous versions, CIDRAM would create log entries for the cron jobs but without any data for IP, Query, User Agent etc.

You mean the latest commit did not fix this?

That's right. I installed the latest version posted by Maikuolan and ran a cron job to test it.

The cron notification email, which includes a copy of the CIDRAM message page, indicated that the cron job had been blocked by CIDRAM due to my IP being invalid. No IP data was recorded by CIDRAM.

Also, I tried test banning my IP but CIDRAM didn't block me.
What exactly did you do?

When the cron job was blocked, I wanted to see if CIDRAM was functioning in some capacity so I entered my computer's IP in ipv4_custom.dat to see if I would be banned. But CIDRAM didn't enforce the ban and allowed me to access my site.

To confirm that it was the March 21st version of loader.php that wasn't working correctly, I copied over the March 20th version of loader.php. My IP ban worked correctly with the March 20th version of loader.php.

At present, I'm running the March 20th version of loader.php and running the Wordpress wp-cron.php script via EasyCron.

[Maikuolan]

So, cron is being blocked, but when you try to block yourself, CIDRAM won't enforce it? Very unusual. :-/

When you mention you entered your computer's IP, do you mean your local IP or your public IP? Depending on which of these you entered, it's possible that CIDRAM might be seeing a different IP (ie, if connecting to your website over the internet, your public IP, versus if connecting to a website hosted locally on your computer, in which case, your local IP).

[Gaffnet]

So, cron is being blocked, but when you try to block yourself, CIDRAM won't enforce it?

Yes, that's right.

When you mention you entered your computer's IP, do you mean your local IP or your public IP?

My dynamic public IP assigned by the ISP. Since my sites aren't critical, I don't use local development versions and just work with the live sites directly on the host's web server via my regular ISP connection.

[DanielRuf]

And it is not run with fcgi, cgi or something else? What is different ftom normal requests? Because CIDRAM should still work. Can you check this?

[Gaffnet]

And it is not run with fcgi, cgi or something else? What is different ftom normal requests? Because CIDRAM should still work. Can you check this?

Unfortunately, I'm limited by my inexperience (not an IT guy) and the fact I'm on a shared host under a turn-key hosting plan rather than a dedicated server plan.

[Maikuolan]

At this point, I'm a little stumped about this, to be honest. I'm going to try asking some other devs that I know, to see if any of them have any fresh ideas.

[DanielRuf]

And it is not run with fcgi, cgi or something else? What is different ftom normal requests? Because CIDRAM should still work. Can you check this?

Unfortunately, I'm limited by my inexperience (not an IT guy) and the fact I'm on a shared host under a turn-key hosting plan rather than a dedicated server plan.

Which address did you try to access? Was it some html, css, js file?

[Gaffnet]

Which address did you try to access? Was it some html, css, js file?

I have CIDRAM hooked into Wordpress' bootstrap loader, wp-load.php. During my IP ban test, I tried accessing my site by its subdomain, Wordpress Dashboard and tried loading a URL pointing to one of my blog posts.

[DanielRuf]

Can you please describe a bit more?

So you hooked it to domain.com, accessed domain.com and tried domain.com/post?

[Gaffnet]

Sorry, I think I'm misunderstanding your question.

Just to clarify for my benefit... CIDRAM is blocking wp-cron.php from being executed via cron. I tried the March 21st commit version of CIDRAM and when it didn't appear to be working, I wanted to see if CIDRAM was working in _any_ capacity so I entered my own IP to CIDRAM's .dat file to see if I would be blocked.

With the March 21st commit version of CIDRAM, wp-cron was still being blocked, however, my IP ban test also showed that the IP ban I just entered wasn't working either.

I reverted to the March 20th version of CIDRAM and tried my IP ban test again by using the following:

http://sub.domain.com
http://sub.domain.com/wp-admin
http://sub.domain.com/2016/1234/my-article-title

(The last URL is in the format: /<currentyear>/<post-id>/<article-title>)

With the March 20th version of CIDRAM, wp-cron was still being blocked but the IP ban worked when I tried to access the above.

[DanielRuf]

Please create a PHP file with the following content and execute it

<?php
var_dump($_SERVER['REMOTE_ADDR']);
var_dump($_SERVER['argv']);
var_dump(php_sapi_name());

Is this the version which you use? https://github.com/Maikuolan/CIDRAM/commit/22f08d3bbbc9a4b68f84afb462b1b9b63ba8df94

Was CloudFlare on? Because it also caches these files, when you change a file on the server (also PHP files) you should empty the CloudFlare cache.

[Gaffnet]

The script returns the following:

NULL array(0) { } string(8) "cgi-fcgi"

NinjaFirewall reports the follwoing:

CGI-FCGI (5.4.45)

When running these tests, I put CloudFlare into development mode to turn off its caching.

Is this the version which you use? 22f08d3

I'll get back to you on this in a moment.

[Gaffnet]

Strange, I can't seem to find the exact version I'm using. Maybe I need more sleep. :-P

Here's the code (pastebin) of the loader.php version that I'm currently using.

[DanielRuf]

You are using this version: https://github.com/Maikuolan/CIDRAM/blob/31a04dfc7bf7eea21c48d1dd8ff98785f1fed35f/loader.php

This was before the changes were made, see https://github.com/Maikuolan/CIDRAM/commits/master/loader.php

These were the changes since your version: https://github.com/Maikuolan/CIDRAM/compare/3c400cfdbb531c535f356e44e76516a34b1f7bf9...22f08d3bbbc9a4b68f84afb462b1b9b63ba8df94

[Gaffnet]

You are using this version: https://github.com/Maikuolan/CIDRAM/blob/31a04dfc7bf7eea21c48d1dd8ff98785f1fed35f/loader.php

This is the version that "sort of" works for me. wp-cron is still blocked but IP bans work.

I'm fairly sure I tested version 22f08d3 but I'm going to test it again just to be sure.

[Gaffnet]

I installed 22f08d3 and tested with my IP ban and CIDRAM failed to block me. I didn't bother with the cron job test.

I re-installed 3c400cf and tested with my IP ban and CIDRAM successfully blocked me.

[DanielRuf]

wp-cron should not be blocked if $_SERVER["argv"] is set, according to the latest commit.

I installed 22f08d3 and tested with my IP ban and CIDRAM failed to block me.

Sitll please run a PHP script with var_dump($_SERVER); so we can see what happens when you access the website as you are using the cgi version of PHP.

[Gaffnet]

Sitll please run a PHP script with var_dump($_SERVER); so we can see what happens when you access the website as you are using the cgi version of PHP.

I received the following result:

NULL array(0) { } string(8) "cgi-fcgi"

[DanielRuf]

When you just execute var_dump($_SERVER);? There should be more.

What code did you use now for getting NULL array(0) { } string(8) "cgi-fcgi"?

Is the NULLfrom var_dump($_SERVER['REMOTE_ADDR']);? Did you try using the CloudFlare header instead of REMOTE_ADDR, eg HTTP_CF_CONNECTING_IP? Because the requests should be still routed through CloudFlare.

jfyi, the development code just disabled minifaction and caching, not the routing https://support.cloudflare.com/hc/en-us/articles/200168246-What-does-CloudFlare-Development-mode-mean-

Please check if your CIDRAM settings use the HTTP_CF_CONNECTING_IP header field.

So please also try var_dump($_SERVER['HTTP_CF_CONNECTING_IP']);

[Gaffnet]

Whups, made a mistake in the script. I think this is the result you want:

array(45) {

["CONTEXT_DOCUMENT_ROOT"]=> string(34) "/home/username/public_html/myblog"

["CONTEXT_PREFIX"]=> string(0) ""

["DOCUMENT_ROOT"]=> string(34) "/home/username/public_html/myblog"

["GATEWAY_INTERFACE"]=> string(7) "CGI/1.1"

["HTTP_ACCEPT"]=> string(74) "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,_/_;q=0.8"

["HTTP_ACCEPT_ENCODING"]=> string(4) "gzip"

["HTTP_ACCEPT_LANGUAGE"]=> string(14) "en-US,en;q=0.8"

["HTTP_CF_CONNECTING_IP"]=> string(14) "888.888.888.888"

["HTTP_CF_IPCOUNTRY"]=> string(2) "CA"

["HTTP_CF_RAY"]=> string(20) "288d9476fc7b3036-YYZ"

["HTTP_CF_RESPECT_STRONG_ETAG"]=> string(1) "0"

["HTTP_CF_VISITOR"]=> string(17) "{"scheme":"http"}"

["HTTP_CONNECTION"]=> string(10) "Keep-Alive"

["HTTP_DNT"]=> string(1) "1"

["HTTP_HOST"]=> string(22) "myblog.mydomain.com"

["HTTP_UPGRADE_INSECURE_REQUESTS"]=> string(1) "1"

["HTTP_USER_AGENT"]=> string(72) "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0"

["HTTP_X_FORWARDED_FOR"]=> string(14) "888.888.888.888"

["HTTP_X_FORWARDED_PROTO"]=> string(4) "http"

["PATH"]=> string(13) "/bin:/usr/bin"

["PHPRC"]=> string(42) "/home/username/public_html/myblog/php.ini"

["QUERY_STRING"]=> string(0) ""

["REDIRECT_STATUS"]=> string(3) "200"

["REMOTE_ADDR"]=> string(14) "888.888.888.888"

["REMOTE_PORT"]=> string(5) "25760"

["REQUEST_METHOD"]=> string(3) "GET"

["REQUEST_SCHEME"]=> string(4) "http"

["REQUEST_URI"]=> string(13) "/phpsappy.php"

["SCRIPT_FILENAME"]=> string(47) "/home/username/public_html/myblog/phpsappy.php"

["SCRIPT_NAME"]=> string(13) "/phpsappy.php"

["SERVER_ADDR"]=> string(13) "198.46.81.134"

["SERVER_ADMIN"]=> string(32) "[email protected]"

["SERVER_NAME"]=> string(22) "myblog.mydomain.com"

["SERVER_PORT"]=> string(2) "80"

["SERVER_PROTOCOL"]=> string(8) "HTTP/1.1"

["SERVER_SIGNATURE"]=> string(0) ""

["SERVER_SOFTWARE"]=> string(6) "Apache"

["UNIQUE_ID"]=> string(24) "VvRrA63NfMIAABT6Tz4AAApS"

["WRDFNC_ENC"]=> string(5) "_gzip"

["PHP_SELF"]=> string(13) "/phpsappy.php"

["REQUEST_TIME_FLOAT"]=> float(1458858755.8148)

["REQUEST_TIME"]=> int(1458858755)

["argv"]=> array(0) { }

["argc"]=> int(0) }

[Gaffnet]

Did you try using the CloudFlare header instead of REMOTE_ADDR, eg HTTP_CF_CONNECTING_IP? Because the requests should be still routed through CloudFlare.

I've been using HTTP_CF_CONNECTING_IP all this time.

[DanielRuf]

["argv"]=> array(0) { }

["argc"]=> int(0) }

Not good, both are set. And I think I know what the problem is. This will be fixed in an upcoming commit. Thanks for the helpful feedback so far.

@Maikuolan we should check it like this: http://stackoverflow.com/a/16044755/753676
https://github.com/drush-ops/drush/blob/4931c4537037dc4527707386885fefe021e47dc8/includes/environment.inc#L442
http://ideone.com/DnkW2d

empty should be probably better and also the check if it is greater than 0

https://github.com/Maikuolan/CIDRAM/blob/22f08d3bbbc9a4b68f84afb462b1b9b63ba8df94/loader.php#L131

Hopefully register_argc_argvis not set.

[Maikuolan]

Yep, I think you've found the source of the problem. :-)

I'll do some local testing on my end now, and if all goes well, sync a new commit shortly.

[Maikuolan]

Local testing passed; New loader.php committed.

@Gaffnet @DanielRuf @dev-101

[Gaffnet]

Local testing passed; New loader.php committed.

So far, so good. No cron jobs are being logged to CIDRAM's log, I received a cron result message instead of the CIDRAM message page stating Invalid IP" and my IP ban test worked too.

I'll keep an eye on things and report back.

Thanks! I really appreciate the effort it took to troubleshoot and fix this.

[DanielRuf]

Thanks for the feedback, it seems this was the problem and it is fixed now.

This was very helpful and revealing for us as this taught us that we can not just blindly trust the argc and argv values.

[Maikuolan]

Awesome! Glad to hear we've gotten it working, and happy to help. :-)

In deed; This has definitely been an insightful learning experience.

Anyhow, seeing as the problem seems to be resolved, I'll mark this issue as closed again; And of course, feel free to reopen it again if the problem reappears.