Crowdsec greylisting?

1

Crowdsec looks very promising, but I was wondering if anyone else has thought about doing it in reverse? When Crowdsec gets a login request, the IP can be in one of two states today, good (allowed to proceed) or known to be bad (bouncced). But there is a third state – unknown. The IP might be new, and thus not trusted, but not untrusted.

In this grey state, the scanners and parsers would ask the hub “This IP and its associated meta-data are not determined. Please request additional verification” For example, the hub might receive the following json

{ 
    ip: 199.200.201.15
    login: mrfoo
    pass: 19214!8@@xZ
    time: 12:41 PDT-8
    service: sshd
   host-urit: sshd://myserver.mydomain.com:2222
}

If this were a known bad IP, the bouncer would be activated. If it were whitelisted, it would be allowed, but configurations could also be invoked if “unknown” was returned such as:

{
    action-uri: ciscoduo://duoserver-21.cisco.com?user=mrfoo
}

or

{ 
     action-uri: msactivedirectory://myserver.mydomain.com?user=mrfoo
}

There do not run in the crowd sourced section --we only need to known that the authenticity of the source is uncertain. The local server must now reach out to the action-uri and see if it gets and OK from there.

So the flow is now:

We can a login a login attempt at server-a
Server-a asks Crowdsec about the attempt
If the attempt is a known attack, reject and bounce
If the source is a trusted IP (no known issues) allow
If the source is untrusted, an unknown reputation, indicate unknown
Back at the server, if unknown, use the configuration to query the verifying uri