Thibault "bui" Koechlin
GitHub
parent
57aa1c6b24
commit
d431fe9f21
10 changed files with 42 additions and 42 deletions
|
|
@ -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
|
|||
<img src="https://github.com/crowdsecurity/crowdsec/blob/master/docs/assets/images/out-of-the-box-protection.gif">
|
||||
</details>
|
||||
|
||||
### Easy blocker deployment
|
||||
### Easy bouncer deployment
|
||||
|
||||
<details>
|
||||
<summary>It's trivial to add blockers to enforce decisions of crowdsec (click to expand)</summary>
|
||||
<summary>It's trivial to add bouncers to enforce decisions of crowdsec (click to expand)</summary>
|
||||
<img src="https://github.com/crowdsecurity/crowdsec/blob/master/docs/assets/images/blocker-installation.gif">
|
||||
</details>
|
||||
|
||||
|
|
|
|||
|
|
@ -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}}.
|
||||
|
||||
12
docs/bouncers/index.md
Normal file
12
docs/bouncers/index.md
Normal file
|
|
@ -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}}.
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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"_ :
|
||||
|
||||
|
|
|
|||
|
|
@ -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 :
|
||||
|
|
|
|||
|
|
@ -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: <profile_name>
|
||||
filter: "<filter_expression>"
|
||||
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: <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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
22
mkdocs.yml
22
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
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue