>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3520753. --> Reported by: [jurgenhaas](https://www.drupal.org/user/168924) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>This issue collects child issues with details about new features that should go into the next major update of the CrowdSec module. This is following some great discussions we've had at DrupalDevDays in Leuven and together with the brains behind CrowdSec. There is so much more potential in that platform that we should certainly leverage.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ol> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/crowdsec/issues/3524326" title="Status: Closed (fixed)">#3524326: More signals: encourage other modules to integrate with crowdsec</a></span><br><br> Version 1 sends signals about bad IPs to CrowdSec on 2 different scenarios: when a crawler causes too many 4xx responses in a short period of time, and when Drupal core bans an IP because of flood control, i.e. too many failed logins from the same IP or for the same user account. Additional signals should easily be possible, if we manage to get other modules to integrate with this CrowdSec module. Examples are: <ol> <li>Spammers</li> <li>Failed captchas</li> <li>Security safeguards</li> </ol> <p>Let's find as many modules possible and motivate them to integrate with us here. The benefit would then also be, that CrowdSec would start a Drupal-specific block list if there are significant more signals received. In return, all Drupal users could benefit from this extra list by getting banned IPs sooner. </p></li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/crowdsec/issues/3524329" title="Status: Closed (fixed)">#3524329: Signal context</a></span><br><br> Drupal currently only reports a bad signal for a specific IP address together with the timestamp and the scenario, which is either <code>drupal/core-ban</code>, or <code>drupal/auth-bruteforce</code>, or <code>drupal/4xx-scan</code>. The latest SDK from CrowdSec also supports context to be sent together with the signal. That will help a lot to better justify the severity of the signal and if enough trusted signals are received, the Drupal-specific block list will then start protecting Drupal sites sooner again.<br><br> CrowdSec will provide us with the specification of what and how context can be signalled. </li> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-16"><a href="https://www.drupal.org/project/crowdsec/issues/3524330" title="Status: Postponed (maintainer needs more info)">#3524330: Reporting: show crowdsec statistics</a></span><br><br> CrowdSec is about to provide reports for each "engine", i.e. Drupal site in our case. This will tell the site owner details about the numbers and the nature of blocked site requests. </li> <li><strong>Documentation and Promotion</strong><br><br> Much more documentation about how CrowdSec works is required, as well as how to set it up and how to create free or paid accounts on the CrowdSec platform. We then need to also promote this module much more, because it can help Drupal DevOps so much, i.e. nowadays also to block AI/LLM bots, that more and more cause real trouble and cost for site owners. The more Drupal signals we send back to CrowdSec to better Drupal-specific attacks can be identified and mitigated. </li> </ol>