CrowdSec - lightweight and collaborative security engine

Thanks.

It seems that your “api_url” setting is empty as your log shows ”api_url”:””

Can you set http://localhost:8080 in your Local API URL setting and try again ?

Thanks

• This reply was modified 3 years, 2 months ago by CrowdSec - lightweight and collaborative security engine.

Hi @houdini69,
Thanks for your message.

Your error message indicates that you received no response for the tested curl call.

I suppose you are using the last version of Crowdsec and the plugin.

Maybe a first step to debug this problem would be to make a direct curl call with this type of command:

curl -H "X-Api-Key:your-bouncer-api-key" your-crowdsec-url/v1/decisions\?ip=192.168.1.254

It should look like below on a basic installation:

curl -H "X-Api-Key:ab4429********725d43feb2" http://localhost:8080/v1/decisions\?ip=192.168.1.254

Could you test it to see if it works or if you can get a useful error message ?

(If it works, you should get “null” for an IP with no active decision”)

Thanks

• This reply was modified 3 years, 2 months ago by CrowdSec - lightweight and collaborative security engine.
• This reply was modified 3 years, 2 months ago by CrowdSec - lightweight and collaborative security engine.
• This reply was modified 3 years, 2 months ago by CrowdSec - lightweight and collaborative security engine.
• This reply was modified 3 years, 2 months ago by CrowdSec - lightweight and collaborative security engine.

Hello @alekscee ,
you are right: server-side rules should be added to prevent access to these files. If this is not possible, the logging of files can be completely disabled using the “Disable prod log” parameter.

As we can not do this in the plugin sources (we don’t know if user works with Apache, Nginx or anything else), I think we should at least add this notice in the advanced settings and add some configuration examples in the documentation.

Will do so asap.

Thank you for pointing that out.

[UPDATE] : For those using Apache, we will add a .htaccess file in the .logs folder with some “deny” directives.

• This reply was modified 3 years, 3 months ago by CrowdSec - lightweight and collaborative security engine.

Hi,
I just tested with Lite Speed Cache (not connected to any external cloud service and using the Essentials presets).

I tested to access a cached page with a banned IP and the ban wall has been displayed. Thus, it seems to be working without the need of enabling auto_prepend mode.

Maybe there are other advanced settings with the Lite Speed Cache plugin that could break the process but this basic check works as expected.

Thanks

Hi,

I just realized that I did not understand your initial message correctly.
Sorry for that.

This plugin has not been tested with a WordPress “MultiSite feature” installation. And I guess it is not supported. Some users have already multiple WordPress connected to one single CrowdSec agent but they are using individual WordPress sites with a Bouncer plugin for each site (cache can be shared with Redis for example and it is possible to use the same bouncer key)

Considering your last issue : “ban wall is not displayed whereas a ban remediation is logged“, I wasn’t able to test the LiteSpeed cache as it seems to be required to register for some external service. If you can test to disable it and see if this is better, it could help us.

For now, I am not sure if the issue comes from this Cache plugin or from a MultiSite installation (or from something else …).

• If this is a Multisite issue:

I can’t tell if or when we will be able to work on a MultiSite support. There is a feature request for it but I have no idea on the time it will take to add this support. As you mentionned, there is only one static file created for the auto_prepend mode, thus this will be maybe be a part of the work.

• If this is a Lite Speed compatibility issue
  
  If this is the same kind of problem that we had with the WP Super Cache plugin, the problem is that those kind plugin bypasses all the plugin loading process and serves the cached content. One can consider that not bouncing cached content is not a real issue. Uncached content (form POST …) should be still protected. But if showing a ban/captcha wall is really wanted, the auto_prepend mode seems to be the only way to act before such Cache plugins.
  
  
  Thanks again.
  
  

Hi,

I just realized that I did not understand your initial message correctly.

I was not aware of this Multisite feature you are talking about.

And as it just happened a feature request about this : https://github.com/crowdsecurity/cs-wordpress-bouncer/issues/128
I just realized my mistake. Sorry about that.

Well, I guess now that this plugin does not support this Multisite feature for now.

If you make new tests with the new version of the plugin, do not hesitate to tell me what you notice.

I think that the compatibility with MultiSite will require a lot of work, but it is something that should be possible one day.

We’ll take a closer look, and I’ll get back to you if there’s any news.

Thanks again.

Could you test to disable LSCache ?

If the html is cached before bouncing can act, then I guess it could lead to your issue.

We had the same issue with WP Super Cache plugin : https://github.com/crowdsecurity/cs-wordpress-bouncer/blob/main/docs/USER_GUIDE.md#auto-prepend-file-mode

I did not test with LSCache but, for the WP Cache plugin, a solution was to use the auto-prepend-file mode (see the above link to).

Please let me know.

Thanks

Hi,
Looking at your PHP errors, I understood what could possibly happen.

I released a new 2.0.2 version of the plugin with a fix for your issue.

Please let me know if it is ok with this new release.

Thanks