Control: retitle -1 RFP: crowdsec -- lightweight and collaborative security engine
Hi again,
Antoine Beaupre <anarcat@debian.org> (2020-10-20):
> (*) CrowdSec ships by default with scenario (brute force, port scan,
> web scan, etc.) adapted for most context, but you can easily extend it
> by picking more of them from the hub. It is also very easy to adapt an
> existing one or create one yourself.
>
> ====
>
> This is similar to fail2ban and sshguard, but with the extra touch
> that it allows for federation and distribution of blocklists. It also
> integrates with Prometheus, also packaged in Debian.
>
> I haven't tested it. I guess it could be maintained by the Go team?
>
> Source code is available here: https://github.com/crowdsecurity/crowdsec
>
> The software is free (MIT), but to get access to the crowd-sourced
> reputation data, you must also share it. The server-side of things is
> also non-free.
For completeness, here are the current descriptions:
Description: lightweight and collaborative security engine
Crowdsec is a lightweight security engine, able to detect and remedy
aggressive network behaviour. It can leverage and also enrich a
global community-wide IP reputation database, to help fight online
cybersec aggressions in a collaborative manner.
.
Crowdsec can read many log sources, parse and also enrich them, in
order to detect specific scenarios, that usually represent malevolent
behaviour. Parsers, Enrichers, and Scenarios are YAML files that can
be shared and downloaded through a specific hub, as well as be created
or adapted locally.
.
Detection results are available for crowdsec, its CLI tools and
bouncers via an HTTP API. Triggered scenarios lead to an alert, which
often results in a decision (e.g. IP banned for 4 hours) that can be
consumed by bouncers (software components enforcing a decision, such
as an iptables ban, an nginx lua script, or any custom user script).
.
The CLI allows users to deploy a metabase Docker image to provide
simple-to-deploy dashboards of ongoing activity. The crowdsec daemon
is also instrumented with prometheus to provide observability.
.
Crowdsec can be used against live logs ("a la fail2ban"), but can
also work on cold logs to help in a forensic context, to build an
analysis for past events.
.
On top of that, crowdsec aims at sharing detection signals amongst
all participants, to pre-emptively allow users to block likely
attackers. To achieve this, minimal meta-information about the attack
is shared with the CrowdSec organization for further retribution.
.
Users can also decide not to take part into the collective effort via
the central API, and to register on a local API instead.
I'm wondering what to do with the default behaviour. As discussed with
upstream, shared data is meant to be minimal (and can be sent over Tor).
The machine is “fingerprinted” through machineid + random suffix, that
acts as a username (plus a random password).
Upon a detection, this is sent:
- Machine fingerprint
- Attacker IP
- Scenario name
- Time of start/end of attack
- NOT SHARED: actual logs
Every N hours, the list of configured scenarios is sent, and a list of
possible bad IPs matching those services is received in return.
Would it seem reasonable to enable by default the automated registration
of the host when the package is installed (after all, as the name and
the description suggest, the goal is to share info with a crowd), or
would that seem to be unwelcome in Debian?
I'm all for *not* phoning back by default, but this particular package
aims at working in a collaborative manner, and the incentive to share if
you want to benefit from the collective efforts doesn't seem entirely
crazy to me.
Thanks for your input!
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Attachment:
signature.asc
Description: PGP signature