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