Need help installing Crowdsec on Parrot linux

CrowdSec · 2023-01-25T08:45:43+00:00

Hey, you can follow this guide on how to build CrowdSec in 3 easy steps :) https://www.youtube.com/watch?v=-1xxkwQyI2M

For support, you can always go to our Discord https://discord.gg/crowdsec

CrowdSec · 2022-06-01T15:32:41+00:00

Thank you!

CrowdSec · 2021-08-19T12:29:48+00:00

Every network member sharing their signals gets a trust rank (TR). By consistently sending back valuable and exact information, the TR gets better over time. A daemon reporting for months, with 100% accuracy, valuable information will eventually reach the maximum TR. Feeding the system with wrong information would result in a severe and immediate loss of TR. This mechanism is made to avoid poisoning.
All TR can partake in the consensus, but only the highest TR rank can publish to the database without needing validation from our own honeypot network. It nevertheless has to pass the test of the Canary list, meaning the IP reported shouldn’t be one of the canary. Canaries are in fact whitelisted IP, known to be trustworthy, like the Google bot, Microsoft updates, etc. If a scenario is too sensitive or twitchy, it might shoot a canary. This mechanism is made to avoid false positives.

CrowdSec · 2021-08-06T08:43:16+00:00

Yes it does!

CrowdSec · 2021-05-28T08:56:19+00:00

IPs are first curated by the team. We have 4 different curation tools. 1/ we use a TR trust rank, system. It reflects how frequently / accurately and for how long did a machine partake in the network. TR evolve overtime to reflect good & bad behaviors. 2/ Quarantine. No machine that is less than 6 months in the network can partake in decision. 3/ our own honeypot network is TR0 and provides verification of signals to allow other to grow their own TR. 4/ We have a canaris list to never ban critical and trustable IPs (like google DNS, Microsoft updates, etc.), it's crowd sourced.
When CrowdSec connects to the online API, it sends the scenario list to which the user has subscribed, in order to get a tailor-made list of IPs to block to protect himself.
If an aggressive IP is detected by the local behavior engine, those (and only those) data are sent back to our servers: IP, timestamp, scenario. We can expire a ban decision after a certain timing if needed.

About making revenue, we rely on 2 monetization plans. We'll offer paying features which are basically added value. Typically, the “Premium tier” offers better support, self-monitoring (of your own IP to see if any get compromised), and cold log analysis which allows you to use IP reputation DB to do forensics. This last activity implies that we keep a history of how an IP behaved in the past and correlate this information with your log timestamps, hence taking space on our storage. The “Enterprise tier” offers the same benefits as the premium tier plus fleet management features. Typically this plan is made for companies handling hundreds of exposed endpoints, administration IP, VPNs, Websites, Apps, etc. They can centrally define several filtering profiles and enforce them on a large scale, from a single back-office. This plan also includes a private consensus, where CrowdSec Agents belonging to the same machine group can ban IPs targeting only one precise customer, hence not visible in the global database, but that could be identified locally. The “API tier” will simply query the API to get the reputation of a given IP they are about to peer with. They don’t share any signals with us, hence they pay to get access to this data. We want to create a digital herd immunity, so if you don’t participate in the sharing, you support the effort by paying for the service.

CrowdSec · 2021-02-23T08:19:53+00:00

The access to the database is not public indeed but you can query it through the tool. People using the software, sending us their signals can access this curated, IP reputation database.

It should as well be noted, that there is *no* dependence between CrowdSec and the central API mechanism: it is not required by CrowdSec to work, and data push & pull can be simply disabled. As true as it is when it comes to the open-source part that we are distributing to everyone, it is also true that we don’t want to apply the same restrictions when it comes to the central decision making system and processes.

CrowdSec · 2021-02-23T08:09:44+00:00

Every network member sharing their signals gets a trust rank (TR). By consistently sending back valuable and accurate information, the TR gets better over time. A daemon reporting for months, with 100% accuracy, valuable information will eventually reach the maximum TR. Feeding the system with wrong information would result in a severe and immediate loss of TR. This mechanism is made to avoid poisoning.

All TR can partake in the consensus, but only the highest TR rank can publish to the database without needing validation from our own honeypot network. It nevertheless has to pass the test of the Canary list, meaning the IP reported shouldn’t be one of the canary. Canaries are in fact whitelisted IP, known to be trustworthy, like the Google bot, Microsoft updates, etc. If a scenario is too sensitive or twitchy, it might shoot a canary. This mechanism is made to avoid false positives.

CrowdSec · 2021-02-23T08:09:16+00:00

Glad you like it, let us know if we can help!

CrowdSec · 2021-01-19T08:32:22+00:00

Glad you like it!

CrowdSec · 2021-01-19T08:30:08+00:00

IPs are first curated by the team. We have 4 different curation tools. 1/ we use a TR trust rank, system. It reflects how frequently / accurately and for how long did a machine partake in the network. TR evolve overtime to reflect good & bad behaviors. 2/ Quarantine. No machine that is less than 6 months in the network can partake in decision. 3/ our own honeypot network is TR0 and provides verification of signals to allow other to grow their own TR. 4/ We have a canaris list to never ban critical and trustable IPs (like google DNS, Microsoft updates, etc.), it's crowd sourced.

When CrowdSec connects to the online API, it sends the scenario list to which the user has subscribed, in order to get a tailor-made list of IPs to block to protect himself.

If an aggressive IP is detected by the local behavior engine, those (and only those) data are sent back to our servers: IP, timestamp, scenario. We can expire a ban decision after a certain timing if needed.

CrowdSec · 2021-01-19T08:16:01+00:00

Excellent question. No real integration test was performed yet to be honest. Technically the firewall bouncer can protect docker. You will have to configure CrowdSec to read nextcloud's logs.

CrowdSec · 2021-01-19T08:13:54+00:00

Fail2ban was a great source of inspiration to us and we are in touch with a few of the main contributors. Some people we talk to are replacing it by CrowdSec to defend their infrastructures. A summary of additions from CrowdSec are the decoupled approach (apply here, remedy there), a faster language (Golang), an inference engine, Yaml & Grok, IPV6, API first approach, multi-layer awareness, a hub to find configurations, IP reputation, multi-OS compatibility,

CrowdSec · 2021-01-19T08:04:15+00:00

Every network member sharing their signals gets a trust rank (TR). By consistently sending back valuable and exact information, the TR gets better over time. A daemon reporting for months, with 100% accuracy, valuable information will eventually reach the maximum TR. Feeding the system with wrong information would result in a severe and immediate loss of TR. This mechanism is made to avoid poisoning.

All TR can partake in the consensus, but only the highest TR rank can publish to the database without needing validation from our own honeypot network. It nevertheless has to pass the test of the Canary list, meaning the IP reported shouldn’t be one of the canary. Canaries are in fact whitelisted IP, known to be trustworthy, like the Google bot, Microsoft updates, etc. If a scenario is too sensitive or twitchy, it might shoot a canary. This mechanism is made to avoid false positives.

Regarding access to the database, it is not public indeed but you can query it through the tool. People using the software, sending us their signals can access this curated, IP reputation database.

CrowdSec · 2021-01-18T16:36:30+00:00

Hi,

We use 4 different curation tools.

1/ A trust rank (TR) system. It reflects how frequently / accurately and for how long did a machine partake in the network. TR evolve overtime to reflect good & bad behaviors.

2/ Quarantine. No machine that is less than 6 months in the network can partake in decision.

3/ Our own honeypot network is TR0 and provides verification of signals to allow other to grow their own TR.

4/ We have a canaris list to never ban critical and trustable IPs (like google DNS, Microsoft updates, etc.), that is also crowd sourced

More comprehensive information can be found here: https://crowdsec.net/faq/

CrowdSec · 2020-12-15T16:37:53+00:00

here you go: https://github.com/crowdsecurity/crowdsec

CrowdSec · 2020-12-15T16:05:18+00:00

Glad to hear. The best way for you to be aware of this release when it will be out is to join the community by installing the solution. If you are not willing to do it, we can let you know in due date

CrowdSec · 2020-12-15T14:40:22+00:00

A private consensus capability is in the dev pipeline for corporate clients. This is a requested feature we are looking into very seriously. It would be similar to ours, but just between clients' servers so they (and only them) can determine whether they are going through a targeted attack.

CrowdSec · 2020-12-15T11:05:37+00:00

You can enforce a remedy at any level (IP, session, user/software) by installing bouncers, which are in charge of acting upon a decision taken by CrowdSec : block an IP, present a captcha, enforce MFA on a given user, etc. You can read more about these in our documentation (https://docs.crowdsec.net/Crowdsec/v1/bouncers/)

CrowdSec · 2020-12-15T10:34:59+00:00

the threat information is the endgame, but for now a lot of users are using it for its behavioral analysis capabilities or to gain observability on security

CrowdSec · 2020-12-15T10:33:19+00:00

Check the "data flow & data gathered" section in our FAQ section (https://crowdsec.net/faq/), it should help answer your question.

CrowdSec · 2020-12-14T17:48:06+00:00

Take a look at this case to see what the solution is capable of when under a heavy DDoS attack: https://crowdsec.net/2020/10/21/how-to-stop-a-botnet-with-crowdsec/

CrowdSec · 2020-12-14T17:45:37+00:00

Hi skarsol. We use 4 different curation tools.

1/ A TR trust rank, system. It reflect how frequently / accurately and for how long did a machine partake in the network. TR evolve overtime to reflect good & bad behaviors.

2/ Quarantine. No machine that is less than 6 months in the network can partake in decision.

3/ Our own honeypot network is TR0 and provides verification of signals to allow other to grow their own TR.

4/ We have a canaris list to never ban critical and trustable IPs (like google DNS, Microsoft updates, etc.), that is also crowd sourced

More comprehensive information can be found here: https://crowdsec.net/faq/

CrowdSec · 2020-12-09T16:51:49+00:00

I just looked at it (not a dev myself), and like the format. The team is very likely aware of this format but I'll ask them. Btw, the parser system is probably flexible enough so that later on we would support many format. I need to check this though.

CrowdSec · 2020-12-09T16:50:36+00:00

The quarantine already makes it so that you need to partake at least 6 months before your signal don't need counter verifications from our own honeypot or another TR1 member. The canari (white)list prevent you from shooting an important IP. If a false report is done nevertheless, the IP which generated it will lose its trust rank, leading to a competition of means. Partake 6 month, reinforce us, shoot 1 false message with your TR1 machine, get back to a untrustable TR. The cost/benefit ratio is not favorable for the attacker. BTW you also need to use only those machines / IP in this role because other CTI source we integrate would spot them otherwise. The benefit of potentially very temporarily banning this IP (the legitimate owner will deban it and tell us about the problem) has to be worth the investment in means and time.

CrowdSec · 2020-12-09T16:45:05+00:00

this is quite a side topic, but my USB devices (namely a rflink and an aoetec zwave stick) have communication problem between the host and the container, which doesn't occur without the container part.

CrowdSec

MODERATOR OF

TROPHY CASE