Making a community blacklist

[Vain05]

Maybe adding an options for privates instances to push/pull their malicious ip on a public blacklist ?

[BlessedRebuS]

@Vain0304 This is a cool idea.

We could use something like a central Krawl instance to maintain blacklists organized by scope.
For example, if a user runs Krawl on a server with server_header: apache2, they could contribute to or subscribe to a blacklist specifically targeting Apache2-related attacks.
This would allow us to both prevent attacks proactively (for example by distributing attack signatures) and preemptively ban known malicious actors targeting that specific server version, providing protection before an attack even reaches the host.

@carnivuth @ptarrant @Lore09 we could brainstorm on this

[Vain05]

Well i have some ideas if you takes them:

-Having a settings page to select which blacklist to suscribe to (like you said multiple blacklists for differents attacks types) so that people can select what they needs depending on what they host.

-Maybe having a option to select the server to subscribe to, so that if the 'main' one have problems or if you one day stop maintaining it, it can still be used.

-A way to whitelist some ips on our own instances (if your own ip get onto the blacklist for a reason like dynamic ip)

[BlessedRebuS]

Ideally, during the deployment process we could allow spawning a Krawl instance as a master instance (using env or config.yaml), responsible for ingesting and distributing blocklists.
Other Krawl instances, as you suggested, could include a configuration field to subscribe to one or more master instances.

-A way to whitelist some ips on our own instances (if your own ip get onto the blacklist for a reason like dynamic ip)

Yes, this is a crucial point to ensure you don’t lock yourself

[Vain05]

And while you add the option for the master instance you could add an option to send infos too, like attacks type/numbers and others...

Because i think i read on reddit you wanted yo do something like that (get attacks infos) ?

[BlessedRebuS]

Yes the idea on the long terms is to build a "shared web attack database" to have something as a references for web attacks.
That could be nice and useful for analysts.

[carnivuth]

A big concern for me is authentication:

in a master slave scenario, where slave constantly send data to a master instance

flowchart TD
A[master]
B[slave 1]
C[slave 2]
D[slave 3]
B & C & D -- connect to --> A

Loading

• If slaves are not authenticated how can we avoid malicious slaves that push fake data?
• how we authenticate self hosted slave krawl instances against the main instance?

I was thinking about some api token that the master could generate by manually acting on the instance with some configuration editing? something like

valid tokens:
  - asdasdasd
  - fooo
  - bar

[Vain05]

If slaves are not authenticated how can we avoid malicious slaves that push fake data?

Having a trust rating ? i mean if a lot of people say an ip is good and a certain say it's bad we can assume it send bad info

how we authenticate self hosted slave krawl instances against the main instance?

Either a token generated by a mail request to the main instance or just an unique id based on the environement or something