From d431fe9f216729abeb59a9636ac5e6a3f2175e97 Mon Sep 17 00:00:00 2001 From: "Thibault \"bui\" Koechlin" Date: Thu, 10 Sep 2020 15:06:34 +0200 Subject: [PATCH] Taxonomy update (#213) * rename --- README.md | 6 +++--- docs/blockers/index.md | 12 ------------ docs/bouncers/index.md | 12 ++++++++++++ docs/cscli/cscli_api.md | 2 +- docs/getting_started/FAQ.md | 8 ++++---- docs/guide/crowdsec/overview.md | 6 +++--- docs/guide/crowdsec/simulation.md | 2 +- docs/index.md | 6 +++--- docs/references/output.md | 8 ++++---- mkdocs.yml | 22 +++++++++++----------- 10 files changed, 42 insertions(+), 42 deletions(-) delete mode 100644 docs/blockers/index.md create mode 100644 docs/bouncers/index.md diff --git a/README.md b/README.md index 09497712b..bd3f4aa24 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ To achieve this, Crowdsec reads logs from different sources (files, streams ...) Crowdsec is a modular and plug-able framework, it ships a large variety of well known popular scenarios; users can choose what scenarios they want to be protected from as well as easily add new custom ones to better fit their environment. -Detected malevolent peers can then be prevented from accessing your resources by deploying [blockers](https://hub.crowdsec.net/browse/#blockers) at various levels (applicative, system, infrastructural) of your stack. +Detected malevolent peers can then be prevented from accessing your resources by deploying [bouncers](https://hub.crowdsec.net/browse/#blockers) at various levels (applicative, system, infrastructural) of your stack. One of the advantages of Crowdsec when compared to other solutions is its crowded aspect : Meta information about detected attacks (source IP, time and triggered scenario) are sent to a central API and then shared amongst all users. @@ -83,10 +83,10 @@ sudo ./wizard.sh -i -### Easy blocker deployment +### Easy bouncer deployment
- It's trivial to add blockers to enforce decisions of crowdsec (click to expand) + It's trivial to add bouncers to enforce decisions of crowdsec (click to expand)
diff --git a/docs/blockers/index.md b/docs/blockers/index.md deleted file mode 100644 index a6e8053f0..000000000 --- a/docs/blockers/index.md +++ /dev/null @@ -1,12 +0,0 @@ -# Blockers - - -{{blockers.Name}} are standalone software pieces in charge of acting upon blocked IPs. - -They can either within the applicative stack, or work out of band : - -[nginx blocker](https://github.com/crowdsecurity/cs-nginx-blocker) will check every unknown IP against the database before letting go through or serving a *403* to the user, while a [netfilter blocker](https://github.com/crowdsecurity/cs-netfilter-blocker) will simply "add" malevolent IPs to nftables/ipset set of blacklisted IPs. - - -You can explore [available {{blockers.name}} on the hub]({{hub.plugins_url}}), and find below a few of the "main" {{blockers.name}}. - diff --git a/docs/bouncers/index.md b/docs/bouncers/index.md new file mode 100644 index 000000000..55d3618fa --- /dev/null +++ b/docs/bouncers/index.md @@ -0,0 +1,12 @@ +# bouncers + + +{{bouncers.Name}} are standalone software pieces in charge of acting upon blocked IPs. + +They can either be within the applicative stack, or work out of band : + +[nginx bouncer](https://github.com/crowdsecurity/cs-nginx-bouncer) will check every unknown IP against the database before letting go through or serving a *403* to the user, while a [netfilter bouncer](https://github.com/crowdsecurity/cs-netfilter-bouncer) will simply "add" malevolent IPs to nftables/ipset set of blacklisted IPs. + + +You can explore [available {{bouncers.name}} on the hub]({{hub.plugins_url}}), and find below a few of the "main" {{bouncers.name}}. + diff --git a/docs/cscli/cscli_api.md b/docs/cscli/cscli_api.md index e8b0843ed..3ef59263e 100644 --- a/docs/cscli/cscli_api.md +++ b/docs/cscli/cscli_api.md @@ -5,7 +5,7 @@ Crowdsec API interaction ### Synopsis -Allow to register your machine into crowdsec API to send and receive signal. +Allow to register your machine into crowdsec API to send and receive alert. ### Examples diff --git a/docs/getting_started/FAQ.md b/docs/getting_started/FAQ.md index e9cfd171d..7dbd3be2a 100644 --- a/docs/getting_started/FAQ.md +++ b/docs/getting_started/FAQ.md @@ -17,7 +17,7 @@ Our aim is to build a strong community that can share malevolent attackers IPs, for that we need to collect the bans triggered locally by each user. -The signal sent by your {{crowdsec.name}} to the central API only contains only meta-data about the attack : +The alert sent by your {{crowdsec.name}} to the central API only contains only meta-data about the attack : - Attacker IP - Scenario name @@ -28,7 +28,7 @@ Your logs are not sent to our central API, only meta-data about blocked attacks ## What is the performance impact ? As {{crowdsec.name}} only works on logs, it shouldn't impact your production. -When it comes to {{blockers.name}}, it should perform **one** request to the database when a **new** IP is discovered thus have minimal performance impact. +When it comes to {{bouncers.name}}, it should perform **one** request to the database when a **new** IP is discovered thus have minimal performance impact. ## How fast is it ? @@ -42,7 +42,7 @@ Currently (0.3.0), {{crowdsec.name}} supports SQLite (default) and MySQL databas See [backend configuration](/references/output/#switching-backend-database) for relevant configuration. SQLite is the default backend as it's suitable for standalone/single-machine setups. -On the other hand, MySQL is more suitable for distributed architectures where blockers across the applicative stack need to access a centralized ban database. +On the other hand, MySQL is more suitable for distributed architectures where bouncers across the applicative stack need to access a centralized ban database. ## How to control granularity of actions ? (whitelists, learning etc.) @@ -96,7 +96,7 @@ Feel free to ask for some help to the {{doc.community}}. ### On Configurations (Parsers, scenarios) -### On Blockers +### On bouncers diff --git a/docs/guide/crowdsec/overview.md b/docs/guide/crowdsec/overview.md index 7c009f988..814a61107 100644 --- a/docs/guide/crowdsec/overview.md +++ b/docs/guide/crowdsec/overview.md @@ -65,7 +65,7 @@ To specify the logging level, available levels: To enable or disable the profiling in {{crowdsec.Name}}. #### `apimode:` -To enable or disable signals sending to the {{api.htmlname}}. +To enable or disable alerts sending to the {{api.htmlname}}. #### `daemon:` To enable or disable {{crowdsec.Name}} daemon mode. @@ -116,8 +116,8 @@ Or if you loose your credentials: The profiles is what allows you to decide how do you react when a scenario is triggered : - do you notify yourself on mattermost/slack ? - - do you push the signal to a database so that your blockers can stop the IP from continuing its attack ? - - do you want to avoid pushing this signal to the API ? + - do you push the alert to a database so that your bouncers can stop the IP from continuing its attack ? + - do you want to avoid pushing this alert to the API ? Behind the scenes, the "profiles" system actually allows you to dispatch an event/overflow to various output plugins. diff --git a/docs/guide/crowdsec/simulation.md b/docs/guide/crowdsec/simulation.md index 6cfaf702e..0b05ddab2 100644 --- a/docs/guide/crowdsec/simulation.md +++ b/docs/guide/crowdsec/simulation.md @@ -9,7 +9,7 @@ You can tag some (or all) scenarios as being in **simulation mode**, which is es Simulation and [Whitelists](/write_configurations/whitelist/) are not to be mixed. [Whitelists](/write_configurations/whitelist/) allows you to purely discard an overflow or a log, while simulation will only "cancel" the action against a peer, while keeping track of events and overflows. -When this happens, the scenarios are still triggered, but the action is prefixed with `simulation:`, which means that blockers won't take action against the peer(s) that triggered the scenario. +When this happens, the scenarios are still triggered, but the action is prefixed with `simulation:`, which means that bouncers won't take action against the peer(s) that triggered the scenario. Simulation can be managed with [cscli simulation](/cscli/cscli_simulation/) command, and allows you to have settings such as _"all in simulation except scenarios X,Y,Z"_ or _"only scenarios X,Y,Z in simulation mode"_ : diff --git a/docs/index.md b/docs/index.md index 4171ce114..02f703005 100644 --- a/docs/index.md +++ b/docs/index.md @@ -8,7 +8,7 @@ To achieve this, {{crowdsec.Name}} reads logs from different sources (files, str {{crowdsec.Name}} is a modular and plug-able framework, it ships a large variety of [well known popular scenarios](https://hub.crowdsec.net/browse/#configurations); users can choose what scenarios they want to be protected from as well as easily adding new custom ones to better fit their environment. -Detected malevolent peers can then be prevented from accessing your resources by deploying [blockers]({{hub.plugins_url}}) at various levels (applicative, system, infrastructural) of your stack. +Detected malevolent peers can then be prevented from accessing your resources by deploying [bouncers]({{hub.plugins_url}}) at various levels (applicative, system, infrastructural) of your stack. One of the advantages of Crowdsec when compared to other solutions is its crowd-sourced aspect : Meta information about detected attacks (source IP, time and triggered scenario) are sent to a central API and then shared amongst all users. @@ -21,7 +21,7 @@ Thanks to this, besides detecting and stopping attacks in real time based on you - [{{crowdsec.Name}}]({{crowdsec.url}}) is the lightweight service that processes logs and keeps track of attacks. - [{{cli.name}}]({{cli.main_doc}}) is the command line interface for humans, it allows you to view, add, or remove bans as well as to install, find, or update scenarios and parsers - - [{{blockers.name}}]({{hub.plugins_url}}) are the components that block malevolent traffic, and can be deployed anywhere in your stack + - [{{bouncers.name}}]({{hub.plugins_url}}) are the components that block malevolent traffic, and can be deployed anywhere in your stack ## Architecture @@ -54,7 +54,7 @@ To learn more about {{crowdsec.name}} and give it a try, please see : - [Take a quick tour of {{crowdsec.name}} and {{cli.name}} features](/getting_started/crowdsec-tour/) - [Observability of {{crowdsec.name}}](/observability/overview/) - [Understand {{crowdsec.name}} configuration](/getting_started/concepts/) - - [Deploy {{blockers.name}} to stop malevolent peers](/blockers/) + - [Deploy {{bouncers.name}} to stop malevolent peers](/bouncers/) - [FAQ](getting_started/FAQ/) Don't hesitate to reach out if you're facing issues : diff --git a/docs/references/output.md b/docs/references/output.md index bb7e750e4..d033d8aef 100644 --- a/docs/references/output.md +++ b/docs/references/output.md @@ -1,11 +1,11 @@ # Output -The output mechanism is composed of plugins. In order to store the bans for {{blockers.htmlname}}, at least one backend plugin must be loaded. Else, bans will not be stored and decisions cannot be applied. +The output mechanism is composed of plugins. In order to store the bans for {{bouncers.htmlname}}, at least one backend plugin must be loaded. Else, bans will not be stored and decisions cannot be applied. Currently the supported backends are SQLite (default) and MySQL. -In order to filter which signals will be sent to which plugin, {{crowdsec.name}} use a system of `profile` that can allow to granularly process your bans and signals. +In order to filter which alerts will be sent to which plugin, {{crowdsec.name}} use a system of `profile` that can allow to granularly process your bans and alerts. ## Profile @@ -14,7 +14,7 @@ Here is a sample of a profile configuration: ```yaml profile: filter: "" -api: true # default true : send signal to crowdsec API +api: true # default true : send alert to crowdsec API outputs: # here choose your output plugins for this profile - plugin: plugin1 custom_config: @@ -44,7 +44,7 @@ outputs: store: false ``` -Here we can use {{filter.htmlname}} like in parsers and scenarios with the {{signal.htmlname}} object to choose which signal will be process by which plugin. +Here we can use {{filter.htmlname}} like in parsers and scenarios with the {{signal.htmlname}} object to choose which alert will be process by which plugin. diff --git a/mkdocs.yml b/mkdocs.yml index 0c83b64d2..8d5dce2ba 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -37,8 +37,8 @@ nav: - Scenarios: write_configurations/scenarios.md - Whitelists: write_configurations/whitelist.md - Expressions: write_configurations/expressions.md - - Blockers: - - Overview : blockers/index.md + - Bouncers: + - Overview : bouncers/index.md - Nginx: - Installation : "https://github.com/crowdsecurity/cs-nginx-blocker#installation" - Configuration : "https://github.com/crowdsecurity/cs-nginx-blocker#configuration" @@ -141,12 +141,12 @@ extra: cli_dir: /etc/crowdsec/cscli/ crowdsec_dir: "/etc/crowdsec/config/" acquis_path: "/etc/crowdsec/config/acquis.yaml" - blockers: - name: blockers - Name: Blockers + bouncers: + name: bouncers + Name: Bouncers url: "https://hub.crowdsec.net/browse/#blockers" - htmlname: "[blockers](/blockers/)" - Htmlname: "[blockers](/blockers/)" + htmlname: "[bouncers](/bouncers/)" + Htmlname: "[Bouncers](/bouncers/)" plugins: name: backend plugins configpath: "/etc/crowdsec/plugins/backend/" @@ -225,10 +225,10 @@ extra: htmlname: "[whitelists](/write_configurations/whitelist/)" Htmlname: "[Whitelists](/write_configurations/whitelist/)" signal: - name: signal - Name: Signal - htmlname: "[signal](/getting_started/concepts/#overflow-or-signaloccurence)" - Htmlname: "[Signal](/getting_started/concepts/#overflow-or-signaloccurence)" + name: alert + Name: Alert + htmlname: "[alert](/getting_started/concepts/#overflow-or-signaloccurence)" + Htmlname: "[Alert](/getting_started/concepts/#overflow-or-signaloccurence)" #scenario stuff stage: name: stage