CrowdSec - lightweight and collaborative security engine

Hi, I’m closing this issue. I assume that completing the missing configuration solved the problem.

Happy to continue the conversation here or elsewhere.

Thanks

@tinaponting, thanks for your message.

The logged error indicates that you don’t have any configured LAPI url. Did you configure it in your plugin setting ?

Thanks

Hi, I’m closing this issue. Happy to continue the conversation here or elsewhere.

Hi @dade88,

I’ve done some basic tests using XHPROF as profiler.


Testing condition

I’m testing locally, with a totally fresh installation of WordPress 6.6.1 and no other plugins than the CrowdSec bouncer :This may not represent production conditions at all, but it’s a start.

details: WordPress 6.6.1, PHP 8.1, Stream Mode ON, Debug log OFF

The test is a simple access to the homepage with a clean IP (no associated decision with this IP) and we are watching the main function of the plugin called safelyBounceCurrentIp

Results

I ran several tests with the same conditions, playing with the cache system and, as the results were not significantly different, I’ll just write a few average measurements :

The total execution time of the safelyBounceCurrentIp function is around 5000 μs (micro-seconds). This is between 4 and 5% of PHP’s total execution time (around 120000 μs).

This function is mainly divided in 3 parts:

– loading settings in database with the getDatabaseConfigs function: between 500 and 600 μs

– instantiating the bouncer (mainly init filesystem, redis or memcached cache, init curl or file_get_contents client, and init the bouncer rules depending on various setting) with the CrowdSecWordPressBouncer\Bouncer::__construct function: between 3500 and 4000 μs

– bouncing: retrieve decision (from cache here) and acts accordingly (do nothing here as we test a clean IP) with the CrowdSecBouncer\AbstractBouncer::run function: between 600 and 800 μs

Conclusion

I’m not sure these metrics are fast enough for you: it’s a bit subjective. And it should be consolidated with production tests (to see if those 4/5% increase or decrease with high web traffic and a WordPress site with lots of other plugins).

The second part of the process (instantiating the bouncer) is clearly the slower one. Perhaps, we could find a way to improve this.

Finally, if we see a large number of users complaining about performance degradation, we could work on a way to cut out parts 2 and 3 altogether (with your cookie solution or otherwise).

Feel free to open an issue on our GitHub repository if you want us to work on it.

Thanks again

Hi @dade88 ,

Thanks for the “cookie” idea.

I don’t know if checking for the presence of a cookie will really be faster than checking for a cached value.

But if need be, it could be a solution.

In any case, we need to go back to your original question and highlight a few time/performance metrics.

We will try to do that as soon as possible.

Thanks again

Hi @dade88,

thanks for your message.

Indeed, we don’t have such a “grace period”.

In live mode, you can configure some settings to avoid too frequent calls to the Local API: (see Advanced settings “Recheck clean IPs X seconds” and “Recheck bad IPs X seconds”): for a given IP, only the cached decision will be used for a certain period of time, without the need for a call to the local API.

In stream mode, the cache is always the source of truth.

But in all cases, we will always look for a decision (cached or not).

I wonder how we could implement such a grace period to speed up the process:
For me, we should store this grace period for the current IP somewhere (probably in the cache…), and we should compare the grace period with the current time minus the last decision check (stored as well somewhere) : so there will always be a need to do something and consume resources.

Thanks

Hi @dade88 , thanks for your message.

The aim of this plugin is to protect your website for every incoming request. So “yes”, it will look for a CrowdSec decision associated with the current IP and act accordingly for each request: ban, captcha or nothing.

To minimize the impact of this plugin on your speed and performance, it’s best to opt for streaming mode: decisions are retrieved asynchronously with this mode (instead of calling the local API for each request in “live” mode).

But even in this mode, the plugin will take some time to :

• retrieve the plugin parameters
• look in the cache to see if there’s a decision
• display a ban/captcha wall if there’s a ban or captcha decision (if there’s no decision, this step won’t “do anything” and won’t cost time)

I don’t recall a resource with profiling showing how much it costs in terms of speed and performance.

As a subjective reassurance, this plugin uses the Symfony Cache component (which is known to be one of the fastest in the PHP world) and I don’t recall anyone complaining about significant performance degradation.

But, like you, I’d prefer objective measurements. As soon as possible, I’ll try to see if I can do profiling and show some useful metrics.

Thanks again.

Hi @brndnl0,

I’ve just published release 2.6.4 of the plugin, with the Redis DSN fix.

Now, you should be able to use the following DSN settings:

• redis:redis_user:redis_password@?host[redis_host:6379]
  
  or

• redis://redis_user:redis_password@redis_host:6379

Please let me know if it works for you.

Thanks

Hi @brndnl0,

I was able to reproduce the bug: Redis connection failed with a user/password pair when the user is not the default one.

I discovered that there was an issue about it in the Symfony repo.

This has been fixed and, for some reason, the version included in this plugin doesn’t have the fix.

I’ll see as soon as possible how to fix this in the plugin code as well.

Thanks again for pointing this out.


P.S: It’s not important but I don’t see your last post in this topic. It’s probably a bug in this WordPress forum. Luckily, I received an email with the content of your last post.

Hi @brndnl0 ,
thanks for your message.

I think it should work unless there’s a problem with the Symfony cache component itself.

On reading the documentation, you may have to use redis:user:pass@localhost:6379

Can you try with this ?
Can you also try a password without special characters (especially @)?
Just in case, maybe try also redis:user:[email protected]:6379

Do you have an error message somewhere ? (maybe in wp-content/uploads/crowdsec if you activate the debug log mode in the advanced settings of the plugin, or in the admin view when you save settings or try the bouncer)

Thanks

Hi @rolekwp,

In the 2.6.0 release, we’ve changed the log an cache folder to a wp-content/uploads/crowdsec folder.

Plugin should pass now the checksum verification.

Thanks again

Hi @rolekwp,

Thanks for your message.

For the moment, it’s not possible to choose the location of log and cache files.
I’ve just created an issue to improve this.

For your information, if you choose Redis or Memcached as cache system, there will be no more cache files in the file system. You can also disable all logs (prod and debug).

Thanks again.

• This reply was modified 9 months, 1 week ago by CrowdSec - lightweight and collaborative security engine.

Hi, I’m closing this issue. Happy to continue the conversation here or elsewhere.

Hi, I’m closing this issue. Happy to continue the conversation here or elsewhere.

Hi @tokar86a ,
You should be able to set the Redis DSN with the password.

Something like:

redis://user:[email protected]:6379

or

redis://[email protected]:6379

We are using the symfony cache component, so here is a documentation for the DSN configuration.

Please let me know it it works for you,

Thanks