Description

Some good practice on sending signals : https://doc.crowdsec.net/docs/next/getting_started/install_softagent#you...

  • The module should allow to push/addSignals easily
  • Signal should come from security modules or plugins listening to security events and generating signals form them
  • A helper is available in CrowdSec's SDK to generate signals
  • The Module could already embed signal generation from existing core security modules like "flood"
  • When Pushing a new kind of signal we should add it to the list of subscribed ones
  • Signals should be buffered before pushed for an optimal usage of the API: every 10 secondes for example by batches of 1 to 250signals

It's important to validate with CrowdSec the scenario names for those signals in order for them to be validated by CrowdSec's expert system

Comments

rr404 created an issue. See original summary.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Assigned: rr404 » Unassigned
Related issues: +#3329780: Signal buffering

Created a separate task at #3329780: Signal buffering to implement the buffering of signals.

The signals we can implement into a first release of this module should be these:

  • Flood control: when a number of failed login attempts failed from either an IP or a user account, Drupal blocks that IP for a period of time. Number of attempts and period of time are configurable by the admin of the Drupal site. Proposed scenario name: drupal/flood_control
  • Ban: Drupal site administrators can manually ban IP addresses for unlimited period of time. Proposed scenario name: drupal/ban
  • Whisper: this feature doesn't exist yet, but could be implemented as part of CrowdSec such that a number of requests that lead to 4xx responses in a period of time would lead to a block. Proposed scenario name: drupal/whisper
  • others could be added later

All of the above scenarios will already lead to a block of the IP by local measures. But we make it configurable, which of those scenarios should send signals upstream.

Also, all 3 scenarios will be added to the list for subscription.

@rr404 could you please review the proposed scenario names so that we can start implementing them?

  • jurgenhaas committed 412e6954 on 1.0.x 
    Issue #3329681 by jurgenhaas: Allow configuration which scenarios should...

  • jurgenhaas committed 9a954c22 on 1.0.x 
    Issue #3329681 by jurgenhaas: Allow configuration which scenarios should...

  • jurgenhaas committed 00962acd on 1.0.x 
    Issue #3329681 by jurgenhaas: Implement the whisper listener
jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Status: Active » Needs review

All 3 scenarios are now fully implemented and can be reviewed.

rr404’s picture

rr404 commented

I'll add those scenarios tomorrow.
We might rename them to be more explicite

* flood : if i'm not mistaken this is authentication flood, and this would trigger when attempts threshold is reached
** If so we could call it drupal/auth-bruteforce

* ban : Could be named drupal/manual-ban

* whisper : could be split in 4xx signal and 5xx signals. drupal/4xx-error drupal/5xx-error

I'll confirm the names tomorrow once added

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Status: Needs review » Needs work

* flood : if i'm not mistaken this is authentication flood, and this would trigger when attempts threshold is reached
** If so we could call it drupal/auth-bruteforce

Good call.

* ban : Could be named drupal/manual-ban

That's correct by default. But I just discovered the Perimeter module as @madclu pointed out in #3330098: Integration with Perimeter module which automatically bans IP addresses if they detect suspicious behaviour. Their banning will be recognized by this module as well, although it's then not manual banning anymore.

* whisper : could be split in 4xx signal and 5xx signals. drupal/4xx-error drupal/5xx-error

I'm fine with drupal/4xx-error but I'm not sure we should deal with any 5xx errors here. The 4xx errors are clearly bad behaviour by a client, but 5xx is bad server behaviour and should not lead to a potential ban.

rr404’s picture

rr404 commented

if the ban event can be triggered by other security modules we could call it drupal/generic-ban
If a security plugin want a specific signal trigger mechanics they'll have to to their own implementation.

Writting this I'm wondering if we should skip listening to the ban and contact Perimeter developer to create specific signals in order to better identify the various bad behavior in different signals.
What do you think ?

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

That wouldn't help much because the Ban module is part of Drupal core and their API doesn't allow more than "just" ban or unban of an IP address. So, while any module (e.g. Perimeter or others) use that Ban API, that's all we can get - and I think that's OK as it falls under the drupal/generic-ban scenario.

If modules later wanted to become more sophisticated, that's fine. But then it needs integration without using the Ban API from Drupal core. I'm sure, we'll see a lot of requests for that once the community recognizes the CrowdSec integration. For our first release, I don't think we need to encourage that.

Please let me know when the scenario names got finalized, because then it is time for the first beta release, I guess.

rr404’s picture

rr404 commented

We can go with drupal/generic-ban or core-ban
I think this would be the most transparent way to name it.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

Shall we go for these 3 then?

  • drupal/auth-bruteforce
  • drupal/core-ban
  • drupal/4xx-scan (I'd rather use "4xx-scan" or "4xx-response" instead of "4xx-error")

Do you have to create them at your end before we can use them, or can we just use these, and they will then be present automatically?

rr404’s picture

rr404 commented

We can go with those scenario names they are fine.
You can use them directly they'll be accepted

  • jurgenhaas committed fb3b83eb on 1.0.x 
    Issue #3329681 by rr404, jurgenhaas: Signals features for Module

  • jurgenhaas committed bf4d9160 on 1.0.x 
    Issue #3329681 by rr404, jurgenhaas: Signals features for Module
jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Status: Needs work » Fixed

Updated the scenario names and marked the issue as fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.