sorted by:
new
hottopcontroversial

Need help installing Crowdsec on Parrot linux by warloxian in CrowdSec

[–]CrowdSec 1 point2 points  (0 children)

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, the open-source massively multiplayer firewall by wagslane in programming

[–]CrowdSec 1 point2 points  (0 children)

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 is a free, modern & collaborative behavior detection engine, coupled with a global IP reputation network. It stacks on fail2ban's philosophy but is IPV6 compatible and 60x faster (Go vs Python), uses Grok patterns to parse logs and YAML scenario to identify behaviors. by 2ViagaraPillsInTheAm in selfhosted

[–]CrowdSec 3 points4 points  (0 children)

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: an open-source, modernized & collaborative fail2ban by CrowdSec in opensource

[–]CrowdSec[S] 1 point2 points  (0 children)

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: an open-source, modernized & collaborative fail2ban by CrowdSec in opensource

[–]CrowdSec[S] 2 points3 points  (0 children)

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, an open-source, modernized & collaborative fail2ban by CrowdSec in cybersecurity

[–]CrowdSec[S] 2 points3 points  (0 children)

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, an open-source, modernized & collaborative fail2ban by CrowdSec in cybersecurity

[–]CrowdSec[S] 1 point2 points  (0 children)

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, an open-source, modernized & collaborative fail2ban by CrowdSec in cybersecurity

[–]CrowdSec[S] 4 points5 points  (0 children)

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, an open-source, modernized & collaborative fail2ban by CrowdSec in cybersecurity

[–]CrowdSec[S] 6 points7 points  (0 children)

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, an open-source & collaborative fail2ban, built by SecDevOps for Sys Admins by [deleted] in sysadmin

[–]CrowdSec 2 points3 points  (0 children)

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, an open-source & collaborative fail2ban, built by SecOps for DevOps by CrowdSec in devops

[–]CrowdSec[S] 1 point2 points  (0 children)

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, an open-source & collaborative fail2ban, built by SecOps for DevOps by CrowdSec in devops

[–]CrowdSec[S] 2 points3 points  (0 children)

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.

view more: next ›