Drupal currently only reports a bad signal for a specific IP address together with the timestamp and the scenario, which is either drupal/core-ban, or drupal/auth-bruteforce, or drupal/4xx-scan. 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.
Some extra info from CrowdSec:
$property["context"] when you use Watcher::buildSignal"context":[{"key":"exampleKey1","value":"exampleValue1"}]context":[{"key":"target_uri","value":"adminroot.php"},{"key":"target_uri","value":"user/edit.php"}]Here are the context keys that would be very good to have in signals:
target_uri: the HTTP path of the requests that were part of the scan alert. Ideally all the ones involved in the alertuser_agent: User agent of the attackermethod: the HTTP verb used GET, POST...status: the HTTP status returned or that would have been returnedtarget_user: in case of bruteforce, the user(s) on which the attempts were made by the attackerTBD
Active
1.2
Code
Issue #3524329 by jurgenhaas: Signal context
Issue #3524329 by jurgenhaas: Signal context