Allow custom "metadata" in decisions

[blotus]

Currently, the only way to influence the behaviour of a bouncer when applying a decision is to use the type attribute of the decision, but this is not very generic, and bouncers need to explicitly handles them.

We could introduce the notion of metadata in decisions to allow for a more generic runtime control of bouncers. For example, let's say we have a scenario called rate-limiting whose goal is to detect users abusing a specific endpoint, and we want to return a 429 status code for a short time, using the nginx bouncer. There's no easy way to achieve this at the moment:

• The bouncer only knows about ban and captcha remediation
• While you can configure the default return code at the bouncer level, it will apply to all decisions, which is not very elegant.

It would be very useful to be able to set arbitrary metadata in a decision when it is created:

filters: 
 - alert.GetScenario() == "rate-limiting"
decisions:
- type: ban
  duration: 10m
  metadata:
    - status_code: 429

or with cscli:

cscli decisions add -i 1.2.3.4 -t ban --metadata '{"status_code": 429}'

When the bouncer fetches the decisions, if there is metadata associated with a specific decision, it would appear in the stream:

{
 "new": [
    {
      "duration": "10m",
      "id": 42,
      "origin": "crowdsec",
      "scenario": "rate-limiting",
      "scope": "Ip",
      "type": "ban",
      "value": "1.2.3.4",
      "metadata":
       {
         "status_code": 429
       }
    },
  ]
 }

Each bouncer would know about specific metadata (for example, all bouncers operating at the HTTP could be aware of the status_code attribute), and could change their configuration at runtime for a specific decision based on what they received. In this example, only 1.2.3.4 would receive a 429 return code, while all other decisions would use the default specified in the bouncer configuration.

[github-actions[bot]]

@blotus: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[github-actions[bot]]

@blotus: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.

• /kind feature
• /kind enhancement
• /kind bug
• /kind packaging

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[blotus]

/area lapi /kind feature

[victoredvardsson]

Would be awesome to see this in upcoming release, as a hosting company we need more metadata to track bans done by appsec.

Especially the http_host header, since we have thousands of domains that are protected by appsec 👍

[W1zzardTPU]

+1. Great suggestion, would definitely use. This could also be used to customize the message that people see on their error page.

[victoredvardsson]

@LaurenceJJones Will this be in the pipeline for 1.6.4?