Package: crowdsec Version: 1.4.2-1 Severity: important Forwarded: https://github.com/crowdsecurity/crowdsec/issues/2128
Hi, The upstream bug report has all the details, but let's sum them up for the Debian BTS, adding some context about Debian 11 and Debian 12 specifically: an existing 1.0.9 crowdsec would usually get decisions from the Central API (CAPI), listing things to block based on the enabled collections (they are all enabled with the default install). While there are no bouncers to be found in Debian 11, upgrading crowdsec from Debian 11 to Debian 12, and installing the firewall bouncer right away seems like a reasonable use case. Unfortunately, that would lead to absolutely no protection for a while: - crowdsec believes it has contacted the CAPI recently enough (which is true), so wouldn't refresh its decisions immediately; - bouncers contact crowdsec via the Local API (LAPI), and get no decisions (at least from CAPI; manually-added decisions might still be returned); - several hours pass; - crowdsec contacts the CAPI and fetches decisions (in passing, that might be around 15k instead of a mere 500 initially, since the crowdsec version is an important factor regarding what is returned by the CAPI); - bouncers would finally get those decisions via the LAPI. Various approaches have been proposed during the joint debugging session with upstream: - Do nothing, it's going to fix itself eventually. → Not something that seems suitable. - Delete all decisions, restart the daemon. → Heavy hammer, losing any manually-added decisions. Was mainly to confirm what was happening. - Fixing the case in the database when upgrading. → Unfortunately, since crowdsec supports several backends, that would mean having to write dedicated code just for that, reading at least the db_config part of the main config file, etc. If that was only about SQLite, we could add sqlite3 to Depends and run a “migration” script, but MariaDB and PostgreSQL support wouldn't be that easy. Therefore, I'm considering doing the following, when an upgrade from pre-1.4.x versions is spotted: - list all alerts; - spot the “Community blocklist” one(s); - use `cscli alerts delete --id` on it(them); - restart `crowdsec.service` if there was such an alert. Of course, it would be even better to do that in advance, to avoid the restart. Unfortunately, crowdsec 1.0.9 doesn't seem to feature anything that would let us delete the “Community blocklist” one: trying to build a filter for it didn't, and deletion via --id didn't exist in that version. Also, since cscli is merely a wrapper that builds requests for the API, cscli 1.4.x does support `cscli alerts delete --id`, but would get an error from the endpoint published by crowdsec 1.0.9, which doesn't support this kind of deletion. That's why the above steps are to be performed after restarting into the 1.4.x version. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/