search

crowdsecurity / cs-wordpress-bouncer

CrowdSec is an open-source cyber security tool. This plugin blocks detected attackers or display them a captcha to check they are not bots.
https://wordpress.org/plugins/crowdsec/
MIT License
37 stars 6 forks source link

PHP Fatal error: Uncaught Error: Call to a member function error() on null in wp-content/plugins/crowdsec/inc/Bounce.php:339 #91

Closed cRUSHr2012 closed 2 years ago

cRUSHr2012 commented 2 years ago

I have this issue : in STREAM mode, wordpress cron task does not work for updates from the local API.

In /wp-content/debug.log

`[11-May-2022 09:17:14 UTC] PHP Fatal error: Uncaught Error: Call to a member function error() on null in /var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/Bounce.php:339 Stack trace:

0 /var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/bounce-current-ip.php(27): Bounce->safelyBounce()

1 /var/www/clients/client0/web5/web/wp-includes/class-wp-hook.php(307): safelyBounceCurrentIp()

2 /var/www/clients/client0/web5/web/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters()

3 /var/www/clients/client0/web5/web/wp-includes/plugin.php(474): WP_Hook->do_action()

4 /var/www/clients/client0/web5/web/wp-settings.php(450): do_action()

5 /var/www/clients/client0/web5/web/wp-config.php(106): require_once('/var/www/client...')

6 /var/www/clients/client0/web5/web/wp-load.php(50): require_once('/var/www/client...')

7 /var/www/clients/client0/web5/web/wp-cron.php(44): require_once('/var/www/client...')

8 {main}

thrown in /var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/Bounce.php on line 339`

I'm testing this on 4 WP sites (different themes / plugins / WP versions) on the same ISPConfig Debian 11 server with NGINX & PHP 7.4. Crowdsec plugin version is 1.4.1 I have crowdsec installed locally. In the LIVE mode, i see events in /var/log/crowdsec_api.log. In STREAM mode i only see expected events when activating the plugin or manually clicking on "Refresh the cache now"

This also blocks all other Wordpress cron jobs. I can see this with Wordpress plugin "WP Crontrol". Manually executing the task from "WP Crontrol" trows the same error.

cRUSHr2012 commented 2 years ago

Update, i noticed that if I use another plugin "Advanced CRON Manager" and issue "Execute now" for the task, it gets executed without error, and in crowdsec_api.log i get the expected result.

time="11-05-2022 12:33:55" level=info msg="127.0.0.1 - [Wed, 11 May 2022 12:33:55 EEST] \"GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 61.844197ms \"WordPress CrowdSec Bouncer/v1.4.1\" \""

For the scheduled task the error still persists. I don't know how each "CRON" plugin manually executes the task, maybe this can help.

Wordpress is 5.9.3, timezone is UTC+3, Crowdsec plugin is 1.4.1, PHP 7.4.29, MariaDB 10.3.34 Crowsec version:

2022/05/11 13:22:22 version: v1.3.4-debian-pragmatic-ddfe95e45d98d1e7a6496d2499e2e44a023135be
2022/05/11 13:22:22 Codename: alphaga
2022/05/11 13:22:22 BuildDate: 2022-04-29_09:36:16
2022/05/11 13:22:22 GoVersion: 1.17.5
2022/05/11 13:22:22 Platform: linux
2022/05/11 13:22:22 Constraint_parser: >= 1.0, <= 2.0
2022/05/11 13:22:22 Constraint_scenario: >= 1.0, < 3.0
2022/05/11 13:22:22 Constraint_api: v1
2022/05/11 13:22:22 Constraint_acquis: >= 1.0, < 2.0
julienloizelet commented 2 years ago

Thanks for reporting this. As for the issue https://github.com/crowdsecurity/cs-wordpress-bouncer/issues/90 , it seems that something does not work as expected for some cron process. We will try to debug this as soon as possible.

julienloizelet commented 2 years ago

Hi @cRUSHr2012, for now, I can not reproduce the issue.

I tried by installing different plugins that run different cron, but with no luck.

By reading your logs, it seems that:

Could you tell me if you are using the native wp-cron.php to run cron tasks, or if you have disabled it by adding somewhere in your code a define('DISABLE_WP_CRON', 'true'); directive ?

In any case, I will try to publish a next release in order to log the root cause error even if something goes wrong before the logger initialization.

cRUSHr2012 commented 2 years ago

Hi. I am using normal wp-cron.php. I've also tried disabling it with : define('DISABLE_WP_CRON', 'true'); and setting a system cronjob to run at each minute. I get the same error in the wp-content/debug.log. Cronjob used: * * * * * wget -qO- https://my-example-site.net/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Other info : I'm using a custom port for the API, because 8080 is used by another app. It's set also in the plugin. And I am using this list of Cloudflare's CDN IP's : 173.245.48.0/20, 103.21.244.0/22, 103.22.200.0/22, 103.31.4.0/22, 141.101.64.0/18, 108.162.192.0/18, 190.93.240.0/20, 188.114.96.0/20, 197.234.240.0/22, 98.41.128.0/17, 162.158.0.0/15, 104.16.0.0/13, 104.24.0.0/14, 172.64.0.0/13, 131.0.72.0/22

I have tested the plugin without any CDN IP's but it's the same.

Another custom option that i have is in NGINX logging, replacing _$remoteaddr with _$http_cf_connectingip, but this should't influence the cron jobs.

Also the two CRON plugins that i've tested do not change the way WP cron runs (this is what I think). They just show what's in the DB in wp_options / cron row.

If you need more info, just let me know.

cRUSHr2012 commented 2 years ago

Another update : I've installed crowdsec plugin on a WP site that's on cPANEL (different server) with PHP 8.0 / Apache 2.4 / WP 5.9.3 I've set crowdsec to listen on 0.0.0.0 IP vs 127.0.0.1 and allowed connections from outside. I get the same error in _php.error.log

The api log shows only the initial connection when I activate "STREAM" mode.

time="12-05-2022 18:51:40" level=info msg="xx.yy.zz.xzy - [Thu, 12 May 2022 18:51:40 EEST] \"GET /v1/decisions/stream?startup=true&scopes=Ip%2CRange HTTP/1.1 200 621.596527ms \"WordPress CrowdSec Bouncer/v1.4.1\" \""

julienloizelet commented 2 years ago

Hi @cRUSHr2012 , I just released a 1.4.2 version on of the crowdsec plugin : this will not solve the issue, but you should find more relevant error messages in your wp_content/debug.log file (assuming the WP_DEBUG and WP_DEBUG_LOG constants are defined to true).

Those messages should begin with safelyBounce error:.

Could you please use the 1.4.2 version and share the messages you will find in your debug.log ?

cRUSHr2012 commented 2 years ago

Hi, after the update I see this in debug.log :

[13-May-2022 10:45:53 UTC] safelyBounce error:session_start(): Cannot start session when headers already sent (Error level: 2) in file:/var/www/clients/client0/web5/web/wp-content/plugins/crowdsec/inc/Bounce.php(line 322)

But, it works !

crowdsec_api.log

time="13-05-2022 13:45:53" level=info msg="127.0.0.1 - [Fri, 13 May 2022 13:45:53 EEST] \"GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 131.251212ms \"WordPress CrowdSec Bouncer/v1.4.2\" \""
time="13-05-2022 13:46:53" level=info msg="127.0.0.1 - [Fri, 13 May 2022 13:46:53 EEST] \"GET /v1/decisions/stream?startup=false&scopes=Ip%2CRange HTTP/1.0 200 79.684122ms \"WordPress CrowdSec Bouncer/v1.4.2\" \""

I've tested it also on the WP site running on cPANEL, and it works. The log for this one is the same:

[13-May-2022 11:00:25 UTC] safelyBounce error:session_start(): Session cannot be started after headers have already been sent (Error level: 2) in file:/home/redacted/public_html/wp-content/plugins/crowdsec/inc/Bounce.php(line 322)

julienloizelet commented 2 years ago

Thanks for the update.

Well, the initial error is now well logged without throwing the fatal error. So, I guess it should not break any other processes anymore.

But, the initial error is still there, and I will work on it.

As far as I understand, headers are already sent when we are trying to start the session. I guess some other process is sending the header before the crowdsec plugin loading. I will see what we can do to handle this in a better way.

julienloizelet commented 2 years ago

Hi @cRUSHr2012, I just released a 1.4.3 version of the crowdsec plugin : it should avoid the "headers already sent" error.

Could you please try it ?

The debug.log file shouldn't have any safelyBounce error in it anymore. Thanks

cRUSHr2012 commented 2 years ago

All good now ! Tested on both sites.