CrowdSec - lightweight and collaborative security engine
Forum Replies Created
-
Forum: Plugins
In reply to: [CrowdSec] Fatal errors due to Symfony componentsHi @brndnl0 , thanks for creating this issue.
I was able to install the MainWP plugin (v6), but, unfortunately, the Google Analytics plugin is a paid add-on.As you’ve mentioned, there is probably a class conflict between the 2 plugins because both of them don’t have namespace isolation.
CrowdSec plugin bundles:- psr/cache v1.0 — where CacheItemInterface::get() has no PHP return type (public function get();)
- symfony/cache v5.4.40 — where CacheItem::get() also has no return type (public function get()) — this is compatible with psr/cache v1.0
The MainWP Google Analytics Extension v6.0 likely bundles:
- psr/cache v3.0 — where the interface declares public function get(): mixed; (with an actual PHP 8.0+ return type)
This could happen with any plugin that bundles some Symfony components with a different version.
(Just a note: If we update our component to psr/cache v3.0, it will drop our support for PHP 7.X and this is not something our users are ready for)
That’s why the best way to solve this , as you’ve already mentioned too, would be to use PHP-Scoper to prefix all vendor namespaces.
As it is a decent amount of work, I’m not sure we’ll be able to work on this soon.
I’ve created an issue in the GitHub repository so that we can track this issue (Pull Requests are welcome).
Thanks again- This reply was modified 3 months ago by CrowdSec - lightweight and collaborative security engine. Reason: remove broken images
Forum: Plugins
In reply to: [CrowdSec] This is free.@mverte , thanks for your message.
For a basic usage, you can use this plugin for free.
For more details about this plugin, please have a look to the documentation: https://docs.crowdsec.net/u/bouncers/wordpress
And for more details about CrowdSec itself, you can also read the documentation: https://doc.crowdsec.net/
Thanks againForum: Plugins
In reply to: [CrowdSec] CrowdSec on server – Advantage of plugin?The WordPress bouncer is a good bouncer in its own right, as it has AppSec and Remediation Metrics capabilities, and it can (as all bouncers) also be used standalone to block IPs from subscribed lists. It’s a good bouncer to have if you can’t install a bouncer linked to your NGINX, OpenResty or Traefik bouncer (soon HAProxy will also have AppSec capabilities). We do recommend those latter bouncers as they will run more efficiently. The WordPress bouncer has the advantage of being in the hands of the user via the setting, which in some cases could be an advantage (for hosters, MSP…).
Also note that if you have an exposed SSH on the server it’s important to also have the firewall bouncer (for you iptables/nftables)
The WP, NGINX,.. bouncers cover HTTP traffic only and are good to have for their AppSec capability in tandem with the firewall bouncer in that case.
Some links:- CrowdSec WAF (thanks to AppSec enabled Bouncers) https://doc.crowdsec.net/docs/next/appsec/intro
- Remediation Metrics: https://doc.crowdsec.net/u/console/remediation_metrics
- Blocklist as a Service integration with a bouncer: https://doc.crowdsec.net/u/integrations/remediationcomponent
Thanks
Forum: Plugins
In reply to: [CrowdSec] CrowdSec on server – Advantage of plugin?Hi @cruiseshipholiday , thanks for your message.
Are you already using a bouncer (nginx or others) so that we can compare the WordPress plugin to it ?
Or is your question more about the general benefits of using a bouncer?
Thanks againForum: Plugins
In reply to: [CrowdSec] Import text – Theme customizationThanks for your message.
I think it can be done using WP-CLI tool.
Please refer to the related doc to see how you could update each setting: https://github.com/crowdsecurity/cs-wordpress-bouncer/blob/main/docs/USER_GUIDE.md#settings-update-with-wp-cli-tool
For example, you may have some sh script that will run a list of command like:echo -n "Cette page est protégée." | wp option set crowdsec_theme_text_ban_wall_subtitle
I hope it helps.
Thanks again.Forum: Plugins
In reply to: [CrowdSec] 2.8.0 update breaks Redis user config?Thanks for the update.
We’ve also added automated tests to make sure this specific bug doesn’t reappear.
We hope this will prevent us from encountering this problem again, and thank you for bringing it to our attention!Forum: Plugins
In reply to: [CrowdSec] 2.8.0 update breaks Redis user config?Forum: Plugins
In reply to: [CrowdSec] 2.8.0 update breaks Redis user config?Forum: Plugins
In reply to: [CrowdSec] config.api_urlHi, I’m closing this issue. I assume that completing the missing configuration solved the problem.
Happy to continue the conversation here or elsewhere.
Thanks
Forum: Plugins
In reply to: [CrowdSec] config.api_url@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
Forum: Plugins
In reply to: [CrowdSec] Impact on performance/speed?Hi, I’m closing this issue. Happy to continue the conversation here or elsewhere.
Forum: Plugins
In reply to: [CrowdSec] Impact on performance/speed?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 calledsafelyBounceCurrentIp
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 thesafelyBounceCurrentIpfunction 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 thegetDatabaseConfigsfunction: 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 theCrowdSecWordPressBouncer\Bouncer::__constructfunction: between 3500 and 4000 µs
– bouncing: retrieve decision (from cache here) and acts accordingly (do nothing here as we test a clean IP) with theCrowdSecBouncer\AbstractBouncer::runfunction: between 600 and 800 µs
ConclusionI’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
Forum: Plugins
In reply to: [CrowdSec] Impact on performance/speed?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
Forum: Plugins
In reply to: [CrowdSec] Impact on performance/speed?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.
ThanksForum: Plugins
In reply to: [CrowdSec] Impact on performance/speed?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.