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/
