Add the documentation into crowdsec repo (#3)

Add the documentation into crowdsec repo
This commit is contained in:
erenJag 2020-05-15 16:58:24 +02:00 committed by GitHub
parent d542966f13
commit 4f9d252a15
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
100 changed files with 5949 additions and 0 deletions

3
docs/about.md Normal file
View file

@ -0,0 +1,3 @@
# Crowdsec
{{ macros_info() }}

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.4 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

12
docs/blockers/index.md Normal file
View file

@ -0,0 +1,12 @@
# Blockers
Blockers are part of the {{crowdsec.name}} full stack integration. They allow you to block an IP at any level of your infra/stack.
You can explore [available {{plugins.name}} on the hub]({{hub.plugins_url}}).
Some core {{plugins.name}} are documented here :
- [nginx lua helper](/blockers/nginx/installation/)
- [netfilter a-la-fail2ban](/blockers/netfilter/installation/)
- [wordpress plugin](/blockers/wordpress/installation/)

View file

@ -0,0 +1,18 @@
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css">
<center><a href="https://github.com/crowdsecurity/cs-netfilter-blocker/"><i class="fa fa-github" style="font-size:36px"></i>Netfilter {{plugins.name}}</a></center>
The configuration file is located in `/etc/crowdsec/netfilter-blocker/netfilter-blocker.yaml` :
```
mode: ipset # The mode you want : ipset or TC
dbpath: /var/lib/crowdsec/data/crowdsec.db # Path to the crowdsec database
piddir: /var/run/ # PID file, don't touch
update_frequency: 10s #
daemonize: true # Run as a service if true
log_mode: file # Output log to file or stdout
log_dir: /var/log/ # Folder to write log
```
The log file created by `netfilter-blocker` is called `netfilter-blocker.log`.

View file

@ -0,0 +1,25 @@
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css">
<center><a href="https://github.com/crowdsecurity/cs-netfilter-blocker/"><i class="fa fa-github" style="font-size:36px"></i>Netfilter {{plugins.name}}</a></center>
First, please [download the latest release](https://github.com/crowdsecurity/cs-netfilter-blocker/releases/latest) of our netfilter {{plugins.name}}.
Then run the following commands:
```bash
tar xzvf cs-netfilter-blocker.tgz
```
```bash
cd cs-netfilter-blocker/
```
```bash
sudo ./install.sh
```
When an IP is referenced in the SQLite database, it will be put in an ipset blacklist to ban that IP.
&#9432; IPv4 and IPv6 are supported.

View file

@ -0,0 +1,10 @@
The blocker configuration is in `/usr/local/lua/crowdsec/crowdsec.conf` :
```
DB_PATH=/var/lib/crowdsec/data/crowdsec.db # The path of the crowdsec SQlite3 database.
LOG_FILE=/tmp/lua_mod.log # Path to file to log
CACHE_EXPIRATION=1 # Cache expiration in seconds
CACHE_SIZE=1000 # Max cache size
```
The nginx configuration file used by nginx to run the module is `/etc/nginx/conf.d/crowdsec_nginx.conf`.

View file

@ -0,0 +1,22 @@
<center>[nginx {{plugins.name}} github](https://github.com/crowdsecurity/cs-nginx-plugin/)</center>
First, please [download the latest version](https://github.com/crowdsecurity/cs-nginx-plugin/releases/latest) of our nginx blocker.
And run the following commands:
```bash
tar xzvf cs-nginx-plugin-release.tgz
```
```bash
cd cs-nginx-plugin-vX.Y.Z/
```
```bash
sudo ./install.sh
```
```bash
sudo systemctl restart nginx
```
When an IP is referenced in the SQLite database, any request from this IP will lead to a `403` reply.

View file

@ -0,0 +1,15 @@
The {{crowdsec.name}} wordress plugins configuration is located under "Crowdsec" => "Settings".
### {{crowdsec.name}} configuration
- `Activate Crowdsec PULL` : Ban IP addresses from crowdsec API
- `Crowdsec API Token` : Crowdsec API Token from crowdsec backoffice subscription
### {{crowdsec.name}} configuration
- `Activate {{crowdsec.name}} decision pull` : Ban IP addresses from {{crowdsec.name}} decision
- `{{crowdsec.name}} db file` : Path to {{crowdsec.name}} database file
## General configuration
- `Activate on backend` : Activate the plugin on the wordpress backend or not

View file

@ -0,0 +1,6 @@
First, please [download the latest release](https://github.com/crowdsecurity/cs-wordpress-plugin/releases/latest) of our wordpress blocker.
Then upload the zip file into your Wordpress backoffice in "Plugins" => "Add new" => "Upload Plugin"
When the plugin is installed, activate it.

View file

@ -0,0 +1,72 @@
!!! info
Please see your local `{{cli.bin}} help ban` for up-to-date documentation.
## List bans
```bash
{{cli.bin}} ban list
```
<details>
<summary>example</summary>
```bash
bui@sd:~$ cli ban list
4 local decisions:
+--------+----------------+----------------------+------+--------+---------+--------------------------------+--------+------------+
| SOURCE | IP | REASON | BANS | ACTION | COUNTRY | AS | EVENTS | EXPIRATION |
+--------+----------------+----------------------+------+--------+---------+--------------------------------+--------+------------+
| cli | 1.1.1.1 | spammer | 1 | ban | | | 0 | 23h59m58s |
| local | 2.2.2.2 | crowdsecurity/ssh-bf | 1 | ban | FR | 3215 Orange | 6 | 3h7m30s |
| local | 3.3.3.3 | crowdsecurity/ssh-bf | 1 | ban | US | 3266 Joao Carlos de Almeida | 6 | 57m17s |
| | | | | | | Silveira trading as Bitcanal | | |
| local | 4.4.4.4 | crowdsecurity/ssh-bf | 1 | ban | FR | 15557 SFR SA | 6 | 5m11s |
+--------+----------------+----------------------+------+--------+---------+--------------------------------+--------+------------+
And 64 records from API, 32 distinct AS, 19 distinct countries
```
</details>
- `SOURCE` is the source of the decision :
- "local" : the decision has been taken by {{crowdsec.name}}
- "cli" : the decision has been made with {{cli.name}} (ie. `{{cli.name}} ban ip 1.2.3.4 24h "because"`)
- "api" : the decision has been pushed to you by the API (because there is a consensus about this ip)
- `IP` is the IP or the IP range impacted by the decision
- `REASON` is the scenario that was triggered (or human-supplied reason)
- `BANS` is the number of "active" remediation against this IP
- `COUNTRY` and `AS` are provided by GeoIP enrichment if present
- `EXPIRATION` is the time left on remediation
## Remove a ban
> delete the ban on IP `1.2.3.4`
```bash
{{cli.bin}} ban del ip 1.2.3.4
```
> delete the ban on range 1.2.3.0/24
```bash
{{cli.bin}} ban del range 1.2.3.0/24
```
## Add a ban manually
> Add a ban on IP `1.2.3.4` for 24 hours, with reason 'web bruteforce'
```bash
{{cli.bin}} ban add ip 1.2.3.4 24h "web bruteforce"
```
> Add a ban on range `1.2.3.0/24` for 24 hours, with reason 'web bruteforce'
```bash
{{cli.bin}} ban add range 1.2.3.0/24 "web bruteforce"
```

View file

@ -0,0 +1,112 @@
{{cli.bin}} allows you install, list, update/upgrade and remove configurations : parsers, enrichment, scenarios.
The various parsers, enrichers and scenarios installed on your machine makes a coherent ensemble to provide detection capabilities.
_Parsers, Scenarios and Enrichers are often bundled together in "collections" to facilitate configuration._
Parsers, scenarios, enrichers and collections all follow the same principle :
- `{{cli.bin}} install parser crowdsec/nginx-logs`
- `{{cli.bin}} update collection crowdsec/base-http-scenarios`
- `{{cli.bin}} remove scenario crowdsec/mysql-bf`
> Please see your local `{{cli.bin}} help` for up-to-date documentation
## List configurations
```
{{cli.bin}} list
```
**note** `-a` allows for listing of uninstalled configurations as well
<details>
<summary>{{cli.name}} list example</summary>
```bash
$ {{cli.bin}} list
INFO[0000] Loaded 9 collecs, 14 parsers, 12 scenarios, 1 post-overflow parsers
INFO[0000] PARSERS:
--------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
--------------------------------------------------------------------------------------------------------------------
crowdsec/nginx-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/nginx-logs.yaml
crowdsec/geoip-enrich ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/geoip-enrich.yaml
crowdsec/syslog-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s00-raw/syslog-logs.yaml
crowdsec/whitelists ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/whitelists.yaml
crowdsec/http-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/http-logs.yaml
crowdsec/dateparse-enrich ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/dateparse-enrich.yaml
--------------------------------------------------------------------------------------------------------------------
INFO[0000] SCENARIOS:
-----------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
-----------------------------------------------------------------------------------------------------------------------
crowdsec/http-scan-uniques_404 ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/http-scan-uniques_404.yaml
crowdsec/http-crawl-non_statics ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/http-crawl-non_statics.yaml
-----------------------------------------------------------------------------------------------------------------------
INFO[0000] COLLECTIONS:
-------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
-------------------------------------------------------------------------------------------------------------------
crowdsec/linux ✔️ enabled 0.2 /etc/crowdsec/config/collections/linux.yaml
crowdsec/nginx ✔️ enabled 0.2 /etc/crowdsec/config/collections/nginx.yaml
crowdsec/base-http-scenarios ✔️ enabled 0.1 /etc/crowdsec/config/collections/base-http-scenarios.yaml
-------------------------------------------------------------------------------------------------------------------
INFO[0000] POSTOVERFLOWS:
--------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
--------------------------------------
--------------------------------------
```
</details>
For {{parsers.htmlname}}, {{scenarios.htmlname}}, {{collections.htmlname}} the outputs include, beside the version, the path and the name, a `STATUS` column :
- `✔️ enabled` : configuration is up-to-date
- `⚠️ enabled,outdated` : a newer version is available
- `🚫 enabled,local` : configuration is not managed by {{cli.name}}
- `⚠️ enabled,tainted` : configuration has been locally modified
(see `{{cli.name}} upgrade` to upgrade/sync your configurations with {{hub.htmlname}})
## Install new configurations
`{{cli.bin}} install parser|scenario|postoverflow <name> [--force]`
- `{{cli.bin}} install parser crowdsec/nginx-logs`
- `{{cli.bin}} install scenario crowdsec/http-scan-uniques_404`
## Remove configurations
`{{cli.bin}} remove parser|scenario|postoverflow <name> [--force]`
## Upgrade configurations
> upgrade a specific scenario
```
{{cli.bin}} upgrade scenario crowdsec/http-scan-uniques_404
```
> upgrade **all** scenarios
```
{{cli.bin}} upgrade scenario --all
```
> upgrade **all** configurations (parsers, scenarios, collections, postoverflows)
```
{{cli.bin}} upgrade --all
```

View file

30
docs/contributing.md Normal file
View file

@ -0,0 +1,30 @@
# Contributing
You have an idea, a suggestion or you spotted a mistake ?
Help us improve the software and the user experience, to make the internet a safer place together !
## Contributing to the documentation
If you spotted some mistakes in the documentation or have improvement suggestions, you can :
- open a {{doc.new_issue}} if you are comfortable with github
- let us know on {{doc.discourse}} if you want to discuss about it
Let us as well know if you have some improvement suggestions !
## Contributing to the code
- If you want to report a bug, you can use [the github bugtracker]({{crowdsec.bugreport}})
- If you want to suggest an improvement you can use either [the github bugtracker]({{crowdsec.bugreport}}) or the {{doc.discourse}} if you want to discuss
## Contributing to the parsers/scenarios
If you want to contribute your parser or scenario to the community and have them appear on the {{hub.htmlname}}, you should [open a merge request](https://github.com/crowdsecurity/hub/pulls) on the hub.
We are currently working on a proper [CI](https://en.wikipedia.org/wiki/Continuous_integration) for the {{hub.htmlname}}, so for now all contribution are subject to peer-review, please bear with us !

57
docs/cscli/cscli.md Normal file
View file

@ -0,0 +1,57 @@
## cscli
cscli allows you to manage crowdsec
### Synopsis
cscli is the main command to interact with your crowdsec service, scenarios & db.
It is meant to allow you to manage bans, parsers/scenarios/etc, api and generally manage you crowdsec setup.
### Examples
```
View/Add/Remove bans:
- cscli ban list
- cscli ban add ip 1.2.3.4 24h 'go away'
- cscli ban del 1.2.3.4
View/Add/Upgrade/Remove scenarios and parsers:
- cscli list
- cscli install collection crowdsec/linux-web
- cscli remove scenario crowdsec/ssh_enum
- cscli upgrade --all
API interaction:
- cscli api pull
- cscli api register
```
### Options
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
-o, --output string Output format : human, json, raw. (default "human")
--debug Set logging to debug.
--info Set logging to info.
--warning Set logging to warning.
--error Set logging to error.
-h, --help help for cscli
```
### SEE ALSO
* [cscli api](cscli_api.md) - Crowdsec API interaction
* [cscli backup](cscli_backup.md) - Backup or restore configuration (api, parsers, scenarios etc.) to/from directory
* [cscli ban](cscli_ban.md) - Manage bans/mitigations
* [cscli config](cscli_config.md) - Allows to view/edit cscli config
* [cscli dashboard](cscli_dashboard.md) - Start a dashboard (metabase) container.
* [cscli inspect](cscli_inspect.md) - Inspect configuration(s)
* [cscli install](cscli_install.md) - Install configuration(s) from hub
* [cscli list](cscli_list.md) - List enabled configs
* [cscli metrics](cscli_metrics.md) - Display crowdsec prometheus metrics.
* [cscli remove](cscli_remove.md) - Remove/disable configuration(s)
* [cscli update](cscli_update.md) - Fetch available configs from hub
* [cscli upgrade](cscli_upgrade.md) - Upgrade configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

49
docs/cscli/cscli_api.md Normal file
View file

@ -0,0 +1,49 @@
## cscli api
Crowdsec API interaction
### Synopsis
Allow to register your machine into crowdsec API to send and receive signal.
### Examples
```
cscli api register # Register to Crowdsec API
cscli api pull # Pull malevolant IPs from Crowdsec API
cscli api reset # Reset your machines credentials
cscli api enroll # Enroll your machine to the user account you created on Crowdsec backend
cscli api credentials # Display your API credentials
```
### Options
```
-h, --help help for api
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli api credentials](cscli_api_credentials.md) - Display api credentials
* [cscli api enroll](cscli_api_enroll.md) - Associate your machine to an existing crowdsec user
* [cscli api pull](cscli_api_pull.md) - Pull crowdsec API TopX
* [cscli api register](cscli_api_register.md) - Register on Crowdsec API
* [cscli api reset](cscli_api_reset.md) - Reset password on CrowdSec API
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli api credentials
Display api credentials
### Synopsis
Display api credentials
```
cscli api credentials [flags]
```
### Examples
```
cscli api credentials
```
### Options
```
-h, --help help for credentials
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli api](cscli_api.md) - Crowdsec API interaction
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,41 @@
## cscli api enroll
Associate your machine to an existing crowdsec user
### Synopsis
Enrolling your machine into your user account will allow for more accurate lists and threat detection. See website to create user account.
```
cscli api enroll [flags]
```
### Examples
```
cscli api enroll -u 1234567890ffff
```
### Options
```
-h, --help help for enroll
-u, --user string User ID (required)
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli api](cscli_api.md) - Crowdsec API interaction
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli api pull
Pull crowdsec API TopX
### Synopsis
Pulls a list of malveolent IPs relevant to your situation and add them into the local ban database.
```
cscli api pull [flags]
```
### Examples
```
cscli api pull
```
### Options
```
-h, --help help for pull
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli api](cscli_api.md) - Crowdsec API interaction
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,41 @@
## cscli api register
Register on Crowdsec API
### Synopsis
This command will register your machine to crowdsec API to allow you to receive list of malveolent IPs.
The printed machine_id and password should be added to your api.yaml file.
```
cscli api register [flags]
```
### Examples
```
cscli api register
```
### Options
```
-h, --help help for register
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli api](cscli_api.md) - Crowdsec API interaction
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli api reset
Reset password on CrowdSec API
### Synopsis
Attempts to reset your credentials to the API.
```
cscli api reset [flags]
```
### Examples
```
cscli api reset
```
### Options
```
-h, --help help for reset
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli api](cscli_api.md) - Crowdsec API interaction
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,39 @@
## cscli backup
Backup or restore configuration (api, parsers, scenarios etc.) to/from directory
### Synopsis
This command is here to help you save and/or restore crowdsec configurations to simple replication
### Examples
```
cscli backup save ./my-backup
cscli backup restore ./my-backup
```
### Options
```
-h, --help help for backup
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli backup restore](cscli_backup_restore.md) - Restore configuration (api, parsers, scenarios etc.) from directory
* [cscli backup save](cscli_backup_save.md) - Backup configuration (api, parsers, scenarios etc.) to directory
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,49 @@
## cscli backup restore
Restore configuration (api, parsers, scenarios etc.) from directory
### Synopsis
restore command will try to restore all saved information from <directory> to yor local setup, including :
- Installation of up-to-date scenarios/parsers/... via cscli
- Restauration of tainted/local/out-of-date scenarios/parsers/... file
- Restauration of API credentials (if the existing ones aren't working)
- Restauration of acqusition configuration
```
cscli backup restore <directory> [flags]
```
### Examples
```
cscli backup restore ./my-backup
```
### Options
```
-h, --help help for restore
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli backup](cscli_backup.md) - Backup or restore configuration (api, parsers, scenarios etc.) to/from directory
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,50 @@
## cscli backup save
Backup configuration (api, parsers, scenarios etc.) to directory
### Synopsis
backup command will try to save all relevant informations to crowdsec config, including :
- List of scenarios, parsers, postoverflows and collections that are up-to-date
- Actual backup of tainted/local/out-of-date scenarios, parsers, postoverflows and collections
- Backup of API credentials
- Backup of acqusition configuration
```
cscli backup save <directory> [flags]
```
### Examples
```
cscli backup save ./my-backup
```
### Options
```
-h, --help help for save
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli backup](cscli_backup.md) - Backup or restore configuration (api, parsers, scenarios etc.) to/from directory
###### Auto generated by spf13/cobra on 15-May-2020

38
docs/cscli/cscli_ban.md Normal file
View file

@ -0,0 +1,38 @@
## cscli ban
Manage bans/mitigations
### Synopsis
This is the main interaction point with local ban database for humans.
You can add/delete/list or flush current bans in your local ban DB.
### Options
```
--db string Set path to SQLite DB.
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
-h, --help help for ban
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli ban add](cscli_ban_add.md) - Adds a ban against a given ip/range for the provided duration
* [cscli ban del](cscli_ban_del.md) - Delete bans from db
* [cscli ban flush](cscli_ban_flush.md) - Fush ban DB
* [cscli ban list](cscli_ban_list.md) - List local or api bans/remediations
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,46 @@
## cscli ban add
Adds a ban against a given ip/range for the provided duration
### Synopsis
Allows to add a ban against a specific ip or range target for a specific duration.
The duration argument can be expressed in seconds(s), minutes(m) or hours (h).
See [time.ParseDuration](https://golang.org/pkg/time/#ParseDuration) for more informations.
### Examples
```
cscli ban add ip 1.2.3.4 24h "scan"
cscli ban add range 1.2.3.0/24 24h "the whole range"
```
### Options
```
-h, --help help for add
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban](cscli_ban.md) - Manage bans/mitigations
* [cscli ban add ip](cscli_ban_add_ip.md) - Adds the specific ip to the ban db
* [cscli ban add range](cscli_ban_add_range.md) - Adds the specific ip to the ban db
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli ban add ip
Adds the specific ip to the ban db
### Synopsis
Duration must be [time.ParseDuration](https://golang.org/pkg/time/#ParseDuration), expressed in s/m/h.
```
cscli ban add ip <target> <duration> <reason> [flags]
```
### Examples
```
cscli ban add ip 1.2.3.4 12h "the scan"
```
### Options
```
-h, --help help for ip
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban add](cscli_ban_add.md) - Adds a ban against a given ip/range for the provided duration
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli ban add range
Adds the specific ip to the ban db
### Synopsis
Duration must be [time.ParseDuration](https://golang.org/pkg/time/#ParseDuration) compatible, expressed in s/m/h.
```
cscli ban add range <target> <duration> <reason> [flags]
```
### Examples
```
cscli ban add range 1.2.3.0/24 12h "the whole range"
```
### Options
```
-h, --help help for range
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban add](cscli_ban_add.md) - Adds a ban against a given ip/range for the provided duration
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,41 @@
## cscli ban del
Delete bans from db
### Synopsis
The removal of the bans can be applied on a single IP address or directly on a IP range.
### Examples
```
cscli ban del ip 1.2.3.4
cscli ban del range 1.2.3.0/24
```
### Options
```
-h, --help help for del
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban](cscli_ban.md) - Manage bans/mitigations
* [cscli ban del ip](cscli_ban_del_ip.md) - Delete bans for given ip from db
* [cscli ban del range](cscli_ban_del_range.md) - Delete bans for given ip from db
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli ban del ip
Delete bans for given ip from db
### Synopsis
Delete bans for given ip from db
```
cscli ban del ip <target> [flags]
```
### Examples
```
cscli ban del ip 1.2.3.4
```
### Options
```
-h, --help help for ip
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban del](cscli_ban_del.md) - Delete bans from db
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli ban del range
Delete bans for given ip from db
### Synopsis
Delete bans for given ip from db
```
cscli ban del range <target> [flags]
```
### Examples
```
cscli ban del range 1.2.3.0/24
```
### Options
```
-h, --help help for range
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban del](cscli_ban_del.md) - Delete bans from db
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli ban flush
Fush ban DB
### Synopsis
Fush ban DB
```
cscli ban flush [flags]
```
### Examples
```
cscli ban flush
```
### Options
```
-h, --help help for flush
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban](cscli_ban.md) - Manage bans/mitigations
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,50 @@
## cscli ban list
List local or api bans/remediations
### Synopsis
List the bans, by default only local decisions.
If --all/-a is specified, api-provided bans will be displayed too.
Time can be specified with --at and support a variety of date formats:
- Jan 2 15:04:05
- Mon Jan 02 15:04:05.000000 2006
- 2006-01-02T15:04:05Z07:00
- 2006/01/02
- 2006/01/02 15:04
- 2006-01-02
- 2006-01-02 15:04
```
cscli ban list [flags]
```
### Options
```
-a, --all List as well bans received from API
--at string List bans at given time
-h, --help help for list
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--db string Set path to SQLite DB.
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--remediation string Set specific remediation type : ban|slow|captcha (default "ban")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli ban](cscli_ban.md) - Manage bans/mitigations
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli config
Allows to view/edit cscli config
### Synopsis
Allow to configure sqlite path and installation directory.
If no commands are specified, config is in interactive mode.
### Examples
```
- cscli config show
- cscli config prompt
```
### Options
```
-h, --help help for config
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli config backend](cscli_config_backend.md) - Configure installation directory
* [cscli config installdir](cscli_config_installdir.md) - Configure installation directory
* [cscli config prompt](cscli_config_prompt.md) - Prompt for configuration values in an interactive fashion
* [cscli config show](cscli_config_show.md) - Displays current config
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,34 @@
## cscli config backend
Configure installation directory
### Synopsis
Configure the backend plugin directory of crowdsec, such as /etc/crowdsec/plugins/backend
```
cscli config backend [value] [flags]
```
### Options
```
-h, --help help for backend
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli config](cscli_config.md) - Allows to view/edit cscli config
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,34 @@
## cscli config installdir
Configure installation directory
### Synopsis
Configure the installation directory of crowdsec, such as /etc/crowdsec/config/
```
cscli config installdir [value] [flags]
```
### Options
```
-h, --help help for installdir
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli config](cscli_config.md) - Allows to view/edit cscli config
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,34 @@
## cscli config prompt
Prompt for configuration values in an interactive fashion
### Synopsis
Start interactive configuration of cli. It will successively ask for install dir, db path.
```
cscli config prompt [flags]
```
### Options
```
-h, --help help for prompt
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli config](cscli_config.md) - Allows to view/edit cscli config
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,34 @@
## cscli config show
Displays current config
### Synopsis
Displays the current cli configuration.
```
cscli config show [flags]
```
### Options
```
-h, --help help for show
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli config](cscli_config.md) - Allows to view/edit cscli config
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli dashboard
Start a dashboard (metabase) container.
### Synopsis
Start a metabase container exposing dashboards and metrics.
### Examples
```
cscli dashboard setup
cscli dashboard start
cscli dashboard stop
cscli dashboard setup --force
```
### Options
```
-h, --help help for dashboard
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli dashboard setup](cscli_dashboard_setup.md) - Setup a metabase container.
* [cscli dashboard start](cscli_dashboard_start.md) - Start the metabase container.
* [cscli dashboard stop](cscli_dashboard_stop.md) - Stops the metabase container.
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,47 @@
## cscli dashboard setup
Setup a metabase container.
### Synopsis
Perform a metabase docker setup, download standard dashboards, create a fresh user and start the container
```
cscli dashboard setup [flags]
```
### Examples
```
cscli dashboard setup
cscli dashboard setup --force
cscli dashboard setup -l 0.0.0.0 -p 443
```
### Options
```
-d, --dir string Shared directory with metabase container. (default "/var/lib/crowdsec/data")
-f, --force Force setup : override existing files.
-h, --help help for setup
-l, --listen string Listen address of container (default "127.0.0.1")
-p, --port string Listen port of container (default "3000")
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli dashboard](cscli_dashboard.md) - Start a dashboard (metabase) container.
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,34 @@
## cscli dashboard start
Start the metabase container.
### Synopsis
Stats the metabase container using docker.
```
cscli dashboard start [flags]
```
### Options
```
-h, --help help for start
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli dashboard](cscli_dashboard.md) - Start a dashboard (metabase) container.
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,35 @@
## cscli dashboard stop
Stops the metabase container.
### Synopsis
Stops the metabase container using docker.
```
cscli dashboard stop [flags]
```
### Options
```
-h, --help help for stop
-r, --remove remove (docker rm) container as well.
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli dashboard](cscli_dashboard.md) - Start a dashboard (metabase) container.
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,47 @@
## cscli inspect
Inspect configuration(s)
### Synopsis
Inspect give you full detail about local installed configuration.
[type] must be parser, scenario, postoverflow, collection.
[config_name] must be a valid config name from [Crowdsec Hub](https://hub.crowdsec.net) or locally installed.
### Examples
```
cscli inspect parser crowdsec/xxx
cscli inspect collection crowdsec/xxx
```
### Options
```
-h, --help help for inspect
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli inspect collection](cscli_inspect_collection.md) - Inspect given collection
* [cscli inspect parser](cscli_inspect_parser.md) - Inspect given log parser
* [cscli inspect postoverflow](cscli_inspect_postoverflow.md) - Inspect given postoverflow parser
* [cscli inspect scenario](cscli_inspect_scenario.md) - Inspect given scenario
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli inspect collection
Inspect given collection
### Synopsis
Inspect given collection from hub
```
cscli inspect collection [config] [flags]
```
### Examples
```
cscli inspect collection crowdsec/xxx
```
### Options
```
-h, --help help for collection
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli inspect](cscli_inspect.md) - Inspect configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli inspect parser
Inspect given log parser
### Synopsis
Inspect given parser from hub
```
cscli inspect parser [config] [flags]
```
### Examples
```
cscli inspect parser crowdsec/xxx
```
### Options
```
-h, --help help for parser
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli inspect](cscli_inspect.md) - Inspect configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli inspect postoverflow
Inspect given postoverflow parser
### Synopsis
Inspect given postoverflow from hub.
```
cscli inspect postoverflow [config] [flags]
```
### Examples
```
cscli inspect postoverflow crowdsec/xxx
```
### Options
```
-h, --help help for postoverflow
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli inspect](cscli_inspect.md) - Inspect configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,40 @@
## cscli inspect scenario
Inspect given scenario
### Synopsis
Inspect given scenario from hub
```
cscli inspect scenario [config] [flags]
```
### Examples
```
cscli inspect scenario crowdsec/xxx
```
### Options
```
-h, --help help for scenario
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli inspect](cscli_inspect.md) - Inspect configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,51 @@
## cscli install
Install configuration(s) from hub
### Synopsis
Install configuration from the CrowdSec Hub.
In order to download latest versions of configuration,
you should [update cscli](./cscli_update.md).
[type] must be parser, scenario, postoverflow, collection.
[config_name] must be a valid config name from [Crowdsec Hub](https://hub.crowdsec.net).
### Examples
```
cscli install [type] [config_name]
```
### Options
```
-d, --download-only Only download packages, don't enable
--force Force install : Overwrite tainted and outdated files
-h, --help help for install
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli install collection](cscli_install_collection.md) - Install given collection
* [cscli install parser](cscli_install_parser.md) - Install given log parser
* [cscli install postoverflow](cscli_install_postoverflow.md) - Install given postoverflow parser
* [cscli install scenario](cscli_install_scenario.md) - Install given scenario
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli install collection
Install given collection
### Synopsis
Fetch and install given collection from hub
```
cscli install collection [config] [flags]
```
### Examples
```
cscli install collection crowdsec/xxx
```
### Options
```
-h, --help help for collection
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
-d, --download-only Only download packages, don't enable
--error Set logging to error.
--force Force install : Overwrite tainted and outdated files
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli install](cscli_install.md) - Install configuration(s) from hub
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli install parser
Install given log parser
### Synopsis
Fetch and install given parser from hub
```
cscli install parser [config] [flags]
```
### Examples
```
cscli install parser crowdsec/xxx
```
### Options
```
-h, --help help for parser
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
-d, --download-only Only download packages, don't enable
--error Set logging to error.
--force Force install : Overwrite tainted and outdated files
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli install](cscli_install.md) - Install configuration(s) from hub
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,43 @@
## cscli install postoverflow
Install given postoverflow parser
### Synopsis
Fetch and install given postoverflow from hub.
As a reminder, postoverflows are parsing configuration that will occur after the overflow (before a decision is applied).
```
cscli install postoverflow [config] [flags]
```
### Examples
```
cscli install collection crowdsec/xxx
```
### Options
```
-h, --help help for postoverflow
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
-d, --download-only Only download packages, don't enable
--error Set logging to error.
--force Force install : Overwrite tainted and outdated files
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli install](cscli_install.md) - Install configuration(s) from hub
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,42 @@
## cscli install scenario
Install given scenario
### Synopsis
Fetch and install given scenario from hub
```
cscli install scenario [config] [flags]
```
### Examples
```
cscli install scenario crowdsec/xxx
```
### Options
```
-h, --help help for scenario
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
-d, --download-only Only download packages, don't enable
--error Set logging to error.
--force Force install : Overwrite tainted and outdated files
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli install](cscli_install.md) - Install configuration(s) from hub
###### Auto generated by spf13/cobra on 15-May-2020

54
docs/cscli/cscli_list.md Normal file
View file

@ -0,0 +1,54 @@
## cscli list
List enabled configs
### Synopsis
List enabled configurations (parser/scenarios/collections) on your host.
It is possible to list also configuration from [Crowdsec Hub](https://hub.crowdsec.net) with the '-a' options.
[type] must be parsers, scenarios, postoverflows, collections
```
cscli list [-a] [flags]
```
### Examples
```
cscli list # List all local configurations
cscli list [type] # List all local configuration of type [type]
cscli list -a # List all local and remote configurations
```
### Options
```
-a, --all List as well disabled items
-h, --help help for list
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli list collections](cscli_list_collections.md) - List enabled collections
* [cscli list parsers](cscli_list_parsers.md) - List enabled parsers
* [cscli list postoverflows](cscli_list_postoverflows.md) - List enabled postoverflow parsers
* [cscli list scenarios](cscli_list_scenarios.md) - List enabled scenarios
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,35 @@
## cscli list collections
List enabled collections
### Synopsis
List enabled collections
```
cscli list collections [-a] [flags]
```
### Options
```
-h, --help help for collections
```
### Options inherited from parent commands
```
-a, --all List as well disabled items
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli list](cscli_list.md) - List enabled configs
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,35 @@
## cscli list parsers
List enabled parsers
### Synopsis
List enabled parsers
```
cscli list parsers [-a] [flags]
```
### Options
```
-h, --help help for parsers
```
### Options inherited from parent commands
```
-a, --all List as well disabled items
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli list](cscli_list.md) - List enabled configs
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,35 @@
## cscli list postoverflows
List enabled postoverflow parsers
### Synopsis
List enabled postoverflow parsers
```
cscli list postoverflows [-a] [flags]
```
### Options
```
-h, --help help for postoverflows
```
### Options inherited from parent commands
```
-a, --all List as well disabled items
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli list](cscli_list.md) - List enabled configs
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,35 @@
## cscli list scenarios
List enabled scenarios
### Synopsis
List enabled scenarios
```
cscli list scenarios [-a] [flags]
```
### Options
```
-h, --help help for scenarios
```
### Options inherited from parent commands
```
-a, --all List as well disabled items
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli list](cscli_list.md) - List enabled configs
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,35 @@
## cscli metrics
Display crowdsec prometheus metrics.
### Synopsis
Fetch metrics from the prometheus server and display them in a human-friendly way
```
cscli metrics [flags]
```
### Options
```
-h, --help help for metrics
-u, --url string Prometheus url (default "http://127.0.0.1:6060/metrics")
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,48 @@
## cscli remove
Remove/disable configuration(s)
### Synopsis
Remove local configuration.
[type] must be parser, scenario, postoverflow, collection
[config_name] must be a valid config name from [Crowdsec Hub](https://hub.crowdsec.net) or locally installed.
### Examples
```
cscli remove [type] [config_name]
```
### Options
```
--all Delete all the files in selected scope
-h, --help help for remove
--purge Delete source file in ~/.cscli/hub/ too
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli remove collection](cscli_remove_collection.md) - Remove/disable collection
* [cscli remove parser](cscli_remove_parser.md) - Remove/disable parser
* [cscli remove postoverflow](cscli_remove_postoverflow.md) - Remove/disable postoverflow parser
* [cscli remove scenario](cscli_remove_scenario.md) - Remove/disable scenario
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,36 @@
## cscli remove collection
Remove/disable collection
### Synopsis
<config> must be a valid collection.
```
cscli remove collection [config] [flags]
```
### Options
```
-h, --help help for collection
```
### Options inherited from parent commands
```
--all Delete all the files in selected scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--purge Delete source file in ~/.cscli/hub/ too
--warning Set logging to warning.
```
### SEE ALSO
* [cscli remove](cscli_remove.md) - Remove/disable configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,36 @@
## cscli remove parser
Remove/disable parser
### Synopsis
<config> must be a valid parser.
```
cscli remove parser <config> [flags]
```
### Options
```
-h, --help help for parser
```
### Options inherited from parent commands
```
--all Delete all the files in selected scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--purge Delete source file in ~/.cscli/hub/ too
--warning Set logging to warning.
```
### SEE ALSO
* [cscli remove](cscli_remove.md) - Remove/disable configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,36 @@
## cscli remove postoverflow
Remove/disable postoverflow parser
### Synopsis
<config> must be a valid collection.
```
cscli remove postoverflow [config] [flags]
```
### Options
```
-h, --help help for postoverflow
```
### Options inherited from parent commands
```
--all Delete all the files in selected scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--purge Delete source file in ~/.cscli/hub/ too
--warning Set logging to warning.
```
### SEE ALSO
* [cscli remove](cscli_remove.md) - Remove/disable configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,36 @@
## cscli remove scenario
Remove/disable scenario
### Synopsis
<config> must be a valid scenario.
```
cscli remove scenario [config] [flags]
```
### Options
```
-h, --help help for scenario
```
### Options inherited from parent commands
```
--all Delete all the files in selected scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--purge Delete source file in ~/.cscli/hub/ too
--warning Set logging to warning.
```
### SEE ALSO
* [cscli remove](cscli_remove.md) - Remove/disable configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,36 @@
## cscli update
Fetch available configs from hub
### Synopsis
Fetches the [.index.json](https://github.com/crowdsecurity/hub/blob/master/.index.json) file from hub, containing the list of available configs.
```
cscli update [flags]
```
### Options
```
-h, --help help for update
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,62 @@
## cscli upgrade
Upgrade configuration(s)
### Synopsis
Upgrade configuration from the CrowdSec Hub.
In order to upgrade latest versions of configuration,
the Hub cache should be [updated](./cscli_update.md).
Tainted configuration will not be updated (use --force to update them).
[type] must be parser, scenario, postoverflow, collection.
[config_name] must be a valid config name from [Crowdsec Hub](https://hub.crowdsec.net).
```
cscli upgrade [type] [config] [flags]
```
### Examples
```
cscli upgrade [type] [config_name]
cscli upgrade --all # Upgrade all configurations types
cscli upgrade --force # Overwrite tainted configuration
```
### Options
```
--all Upgrade all configuration in scope
--force Overwrite existing files, even if tainted
-h, --help help for upgrade
```
### Options inherited from parent commands
```
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli](cscli.md) - cscli allows you to manage crowdsec
* [cscli upgrade collection](cscli_upgrade_collection.md) - Upgrade collection configuration(s)
* [cscli upgrade parser](cscli_upgrade_parser.md) - Upgrade parser configuration(s)
* [cscli upgrade postoverflow](cscli_upgrade_postoverflow.md) - Upgrade postoverflow parser configuration(s)
* [cscli upgrade scenario](cscli_upgrade_scenario.md) - Upgrade scenario configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,44 @@
## cscli upgrade collection
Upgrade collection configuration(s)
### Synopsis
Upgrade one or more collection configurations
```
cscli upgrade collection [config] [flags]
```
### Examples
```
- cscli upgrade collection crowdsec/apache-lamp
- cscli upgrade collection -all
- cscli upgrade collection crowdsec/apache-lamp --force
```
### Options
```
-h, --help help for collection
```
### Options inherited from parent commands
```
--all Upgrade all configuration in scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--force Overwrite existing files, even if tainted
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli upgrade](cscli_upgrade.md) - Upgrade configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,44 @@
## cscli upgrade parser
Upgrade parser configuration(s)
### Synopsis
Upgrade one or more parser configurations
```
cscli upgrade parser [config] [flags]
```
### Examples
```
- cscli upgrade parser crowdsec/apache-logs
- cscli upgrade parser -all
- cscli upgrade parser crowdsec/apache-logs --force
```
### Options
```
-h, --help help for parser
```
### Options inherited from parent commands
```
--all Upgrade all configuration in scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--force Overwrite existing files, even if tainted
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli upgrade](cscli_upgrade.md) - Upgrade configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,44 @@
## cscli upgrade postoverflow
Upgrade postoverflow parser configuration(s)
### Synopsis
Upgrade one or more postoverflow parser configurations
```
cscli upgrade postoverflow [config] [flags]
```
### Examples
```
- cscli upgrade postoverflow crowdsec/enrich-rdns
- cscli upgrade postoverflow -all
- cscli upgrade postoverflow crowdsec/enrich-rdns --force
```
### Options
```
-h, --help help for postoverflow
```
### Options inherited from parent commands
```
--all Upgrade all configuration in scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--force Overwrite existing files, even if tainted
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli upgrade](cscli_upgrade.md) - Upgrade configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

View file

@ -0,0 +1,43 @@
## cscli upgrade scenario
Upgrade scenario configuration(s)
### Synopsis
Upgrade one or more scenario configurations
```
cscli upgrade scenario [config] [flags]
```
### Examples
```
- cscli upgrade scenario -all
- cscli upgrade scenario crowdsec/http-404 --force
```
### Options
```
-h, --help help for scenario
```
### Options inherited from parent commands
```
--all Upgrade all configuration in scope
-c, --config-dir string Configuration directory to use. (default "/etc/crowdsec/cscli/")
--debug Set logging to debug.
--error Set logging to error.
--force Overwrite existing files, even if tainted
--info Set logging to info.
-o, --output string Output format : human, json, raw. (default "human")
--warning Set logging to warning.
```
### SEE ALSO
* [cscli upgrade](cscli_upgrade.md) - Upgrade configuration(s)
###### Auto generated by spf13/cobra on 15-May-2020

100
docs/getting_started/FAQ.md Normal file
View file

@ -0,0 +1,100 @@
# FREQUENTLY ASKED QUESTIONS
## What is {{crowdsec.name}} ?
{{crowdsec.Name}} is a security open-source software. See the [overview](/#what-is-crowdsec)
## What language is it written in ?
{{crowdsec.Name}} is written in [Golang](https://golang.org/)
## What licence is {{crowdsec.name}} released under ?
{{crowdsec.Name}} is under [MIT license]({{crowdsec.url}}/blob/master/LICENSE)
## How fast is it ?
{{crowdsec.name}} can easily handle 5k+ EP/s on a rich pipeline (multiple parsers, geoip enrichment, scenarios and so on). Logs are a good fit for sharding by default, so it is definitely the way to go if you need to handle higher throughput.
If you need help for large scale deployment, please get in touch with us on the {{doc.discourse}}, we love challenges ;)
## Is there any performance impact ?
As {{crowdsec.name}} only works on logs, it shouldn't impact your production.
When it comes to {{plugins.name}}, it should perform **one** request to the database when a **new** IP is discovered thus have minimal performance impact.
## Which information is shared from my logs ?
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 meta-data about the attack, including :
- Attacker IP
- Scenario name
- Time of start/end of attack
You can find the specific list [here]({{crowdsec.url}}/blob/master/pkg/types/signal_occurence.go)
## How to add whitelists ?
You can follow this [guide](/write_configurations/whitelist/)
## How to set up proxy ?
Setting up a proxy works out of the box, the [net/http golang library](https://golang.org/src/net/http/transport.go) can handle those environment variables:
* `HTTP_PROXY`
* `HTTPS_PROXY`
* `NO_PROXY`
Since {{cli.name}} uses `sudo`, you just this line in `visudo` after setting up the previous environment variables:
```
Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY"
```
## How to report a bug ?
To report a bug, please open an issue on the [repository]({{crowdsec.bugreport}})
## I need some help
Feel free to ask for some help to the {{doc.community}}.
## Who's stronger : elephant or hippopotamus ?
[The answer](https://www.quora.com/Which-animal-is-stronger-the-elephant-or-the-hippopotamus)
<!--
## How to contribute ?
### On {{crowdsec.Name}}
### On Configurations (Parsers, scenarios)
### On Blockers
## What are common use-cases ?
**TBD**
## What about false positives ?
**TBD**
## How to test if it works ?
**TBD**
## Who are you ?
**TBD**
-->

View file

@ -0,0 +1,48 @@
{{crowdsec.Name}}'s main goal is to crunch logs to detect things (duh).
You will find below an introduction to the concepts that are frequently used within the documentation.
## Acquisition
[Acquistion configuration](/guide/crowdsec/acquisition/) defines which streams of information {{crowdsec.name}} is going to process.
At the time of writing, it's mostly files, but it should be more or less any kind of stream, such as a kafka topic or a cloudtrail.
Acquisition configuration always contains a stream (ie. a file to tail) and a tag (ie. "these are in syslog format" "these are non-syslog nginx logs").
## Parsers
For logs to be able to be exploited and analyzed, they need to be parsed and normalized, and this is where parsers are used. In most cases, you should be able to find the relevant parsers on our {{hub.htmlname}}.
A parser usually has a specific scope. For example, if you are using [nginx](https://nginx.org), you will probably want to use the `crowdsecurity/nginx-logs` which allows your {{crowdsec.name}} setup to parse nginx's access and error logs.
You can as well [write your own](/write_configurations/parsers/) !
## Enrichers
Enrichment is the action of adding extra context to an event based on the information we already have, so that better decision can later be taken. In most cases, you should be able to find the relevant enrichers on our {{hub.htmlname}}.
The most common/simple type of enrichment would be geoip-enrichment of an event (adding information such as : origin country, origin AS and origin IP range to an event).
Once again, you should be able to find the ones you're looking for on the {{hub.htmlname}} !
## Scenarios
Scenarios is the expression of a heuristic that allows you to qualify a specific event (usually an attack). In most cases, you should be able to find the relevant scenarios on our {{hub.htmlname}}.
While not going [into details](/references/scenarios/), a scenario often evolves around several central things.
(Let's take "we want to detect ssh bruteforce" as an example!)
- A filter : to know which events are elligible ("I'm looking for failed authentication")
- A grouping key : how are we going to "group" events together to give them a meaning ("We are going to group by source IP performing said failed authentication")
- A rate-limit configuration including burst capacity : to qualify an attack and limit the false positives, we are characterizing the speed at which events need to happen (For a ssh bruteforce, it could be "at least 10 failed authentication within 1 minute")
You can as well [write your own](/write_configurations/scenarios/) !
## Collections
To make user's life easier, "collections" are available, which are just a bundle of parsers and scenarios.
In this way, if you want to cover basic use-cases of let's say "nginx", you can just install the `crowdsecurity/nginx` collection that is composed of `crowdsecurity/nginx-logs` parser, as well as generic http scenarios such as `crowdsecurity/base-http-scenarios`.
As usual, those can be found on the {{hub.htmlname}} !

View file

@ -0,0 +1,194 @@
## Finding configurations
As stated, {{crowdsec.name}} efficiency is dictated by installed parsers and scenarios.
[Please take a look at the {{hub.name}}]({{hub.url}}) to find the appropriated ones !
## List installed configurations
> List installed parsers/scenarios/collections/enricher
```bash
{{cli.bin}} list
```
On the machine where you deployed {{crowdsec.name}}, type `{{cli.bin}} list` to see deployed configurations.
This list represents the parsers, scenarios and/or collections that you deployed. They represent what your {{crowdsec.name}} setup can read (logs) and detect (scenarios).
Check [{{cli.name}} configuration](/guide/cscli/) management for more !
<details>
<summary>output example</summary>
```bash
bui@sd:~$ {{cli.bin}} list
INFO[0000] Loaded 9 collecs, 14 parsers, 12 scenarios, 1 post-overflow parsers
INFO[0000] PARSERS:
--------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
--------------------------------------------------------------------------------------------------------------------
crowdsec/nginx-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/nginx-logs.yaml
crowdsec/sshd-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/sshd-logs.yaml
crowdsec/syslog-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s00-raw/syslog-logs.yaml
crowdsec/whitelists ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/whitelists.yaml
crowdsec/dateparse-enrich ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/dateparse-enrich.yaml
crowdsec/iptables-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/iptables-logs.yaml
crowdsec/naxsi-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/naxsi-logs.yaml
crowdsec/http-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/http-logs.yaml
crowdsec/geoip-enrich ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/geoip-enrich.yaml
--------------------------------------------------------------------------------------------------------------------
INFO[0000] SCENARIOS:
-----------------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
-----------------------------------------------------------------------------------------------------------------------------
crowdsec/http-crawl-non_statics ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/http-crawl-non_statics.yaml
crowdsec/iptables-scan-multi_ports ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/iptables-scan-multi_ports.yaml
crowdsec/http-scan-uniques_404 ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/http-scan-uniques_404.yaml
crowdsec/ssh-bf ✔️ enabled 0.8 /etc/crowdsec/config/scenarios/ssh-bf.yaml
-----------------------------------------------------------------------------------------------------------------------------
INFO[0000] COLLECTIONS:
-------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
-------------------------------------------------------------------------------------------------------------------
crowdsec/base-http-scenarios ✔️ enabled 0.1 /etc/crowdsec/config/collections/base-http-scenarios.yaml
crowdsec/iptables ✔️ enabled 0.2 /etc/crowdsec/config/collections/iptables.yaml
crowdsec/nginx ✔️ enabled 0.2 /etc/crowdsec/config/collections/nginx.yaml
crowdsec/sshd ✔️ enabled 0.2 /etc/crowdsec/config/collections/sshd.yaml
crowdsec/linux ✔️ enabled 0.2 /etc/crowdsec/config/collections/linux.yaml
-------------------------------------------------------------------------------------------------------------------
INFO[0000] POSTOVERFLOWS:
--------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
--------------------------------------
--------------------------------------
```
</details>
## List existing bans
> List current bans
```bash
{{cli.bin}} ban list
```
On the machine where you deployed {{crowdsec.name}}, type `{{cli.bin}} ban list` to see existing bans.
If you just deployed {{crowdsec.name}}, the list might be empty, but don't worry, it simply means you haven't yet been attacked, congrats!
Check [{{cli.name}} ban](/cheat_sheets/ban-mgmt/) management for more !
<details>
<summary>output example</summary>
```bash
bui@sd:~$ {{cli.bin}} ban list
7 local decisions:
+--------+----------------+--------------------------------+------+--------+---------+--------------------------------+--------+------------+
| SOURCE | IP | REASON | BANS | ACTION | COUNTRY | AS | EVENTS | EXPIRATION |
+--------+----------------+--------------------------------+------+--------+---------+--------------------------------+--------+------------+
| local | 103.218.xxx.xx | crowdsecurity/ssh-bf | 4 | ban | HK | 59077 Shanghai UCloud | 24 | 3h28m24s |
| | | | | | | Information Technology Company | | |
| | | | | | | Limited | | |
| local | 176.174.x.xx | crowdsecurity/ssh-bf | 11 | ban | FR | 5410 Bouygues Telecom SA | 66 | 2h48m6s |
| local | 37.49.xxx.xxx | crowdsecurity/ssh-bf | 4 | ban | NL | 0 | 37 | 2h16m35s |
| local | 37.49.xxx.xx | crowdsecurity/ssh-bf_user-enum | 5 | ban | NL | 0 | 59 | 2h16m21s |
| local | 92.246.xx.xxx | crowdsecurity/ssh-bf_user-enum | 2 | ban | | 0 | 12 | 1h42m2s |
| local | 23.237.x.xx | crowdsecurity/ssh-bf | 8 | ban | US | 174 Cogent Communications | 48 | 1h7m48s |
| local | 185.153.xxx.xx | crowdsecurity/ssh-bf_user-enum | 59 | ban | MD | 49877 RM Engineering LLC | 449 | 12m54s |
+--------+----------------+--------------------------------+------+--------+---------+--------------------------------+--------+------------+
And 64 records from API, 32 distinct AS, 19 distinct countries
```
</details>
There are different bans sources:
- local : bans triggered locally
- api : bans fetched from the API as part of the global consensus
- cli : bans added via `{{cli.bin}} ban add`
## Monitor on-going activity (prometheus)
> List metrics
```bash
{{cli.bin}} metrics
```
The metrics displayed are extracted from {{crowdsec.name}} prometheus.
The indicators are grouped by scope :
- Buckets : Know which buckets are created and/or overflew (scenario efficiency)
- Acquisition : Know which file produce logs and if thy are parsed (or end up in bucket)
- Parser : Know how frequently the individual parsers are triggered and their success rate
<details>
<summary>output example</summary>
```bash
bui@sd:~$ {{cli.bin}} metrics
INFO[0000] Buckets Metrics:
+---------------------------------+-----------+--------------+--------+---------+
| BUCKET | OVERFLOWS | INSTANTIATED | POURED | EXPIRED |
+---------------------------------+-----------+--------------+--------+---------+
| crowdsec/http-scan-uniques_404 | 69 | 77 | 424 | 8 |
| crowdsec/ssh-bf | 4 | 23 | 53 | 18 |
| crowdsec/ssh-bf_user-enum | - | 21 | 23 | 20 |
| crowdsec/http-crawl-non_statics | 9 | 14 | 425 | 5 |
+---------------------------------+-----------+--------------+--------+---------+
INFO[0000] Acquisition Metrics:
+------------------------------------------+------------+--------------+----------------+------------------------+
| SOURCE | LINES READ | LINES PARSED | LINES UNPARSED | LINES POURED TO BUCKET |
+------------------------------------------+------------+--------------+----------------+------------------------+
| /var/log/nginx/error.log | 496 | 496 | - | - |
| /var/log/nginx/http.access.log | 472 | 465 | 7 | 847 |
| /var/log/nginx/https.access.log | 1 | 1 | - | 2 |
| /var/log/auth.log | 357 | 53 | 304 | 76 |
| /var/log/kern.log | 2292 | - | 2292 | - |
| /var/log/syslog | 2358 | - | 2358 | - |
+------------------------------------------+------------+--------------+----------------+------------------------+
INFO[0000] Parser Metrics:
+---------------------------+------+--------+----------+
| PARSERS | HITS | PARSED | UNPARSED |
+---------------------------+------+--------+----------+
| crowdsec/syslog-logs | 5007 | 5007 | 0 |
| crowdsec/whitelists | 1015 | 1015 | 0 |
| crowdsec/dateparse-enrich | 1015 | 1015 | 0 |
| crowdsec/geoip-enrich | 519 | 519 | 0 |
| crowdsec/http-logs | 962 | 427 | 535 |
| crowdsec/nginx-logs | 973 | 962 | 11 |
| crowdsec/non-syslog | 969 | 969 | 0 |
| crowdsec/sshd-logs | 350 | 53 | 297 |
+---------------------------+------+--------+----------+
```
</details>
## Monitor on-going activity (log files)
The {{crowdsec.main_log}} file will tell you what is going on and when an IP is blocked.
Check [{{crowdsec.name}} monitoring](/observability/overview/) for more !
<details>
<summary>output example</summary>
```bash
bui@sd:~$ tail -f /var/log/crowdsec-agent.log
time="14-04-2020 16:06:21" level=warning msg="40 existing LeakyRoutine"
time="14-04-2020 16:14:07" level=warning msg="1.2.3.4 triggered a 4h0m0s ip ban remediation for [crowdsec/ssh-bf]" bucket_id=throbbing-forest event_time="2020-04-14 16:14:07.215101505 +0200 CEST m=+359659.646220115" scenario=crowdsec/ssh-bf source_ip=1.2.3.4
time="14-04-2020 16:15:52" level=info msg="api push signal: token renewed. Pushing signals"
time="14-04-2020 16:15:53" level=info msg="api push signal: pushed 1 signals successfully"
time="14-04-2020 16:21:10" level=warning msg="18 existing LeakyRoutine"
time="14-04-2020 16:30:01" level=info msg="Flushed 1 expired entries from Ban Application"
time="14-04-2020 16:33:23" level=warning msg="33 existing LeakyRoutine"
time="14-04-2020 16:35:58" level=info msg="Flushed 1 expired entries from Ban Application"
```
</details>

View file

@ -0,0 +1,123 @@
### **Event**
The objects that are processed within {{crowdsec.name}} are named "Events".
An Event can be a log line, or an overflow result. This object layout evolves around a few important items :
- `Parsed` is an associative array that will be used during parsing to store temporary variables or processing results.
- `Enriched`, very similar to `Parsed`, is an associative array but is intended to be used for enrichment process.
- `Overflow` is a `SignalOccurence` structure that represents information about a triggered scenario, when applicable.
- `Meta` is an associative array that will be used to keep track of meta information about the event.
_Other fields omitted for clarity, see [`pkg/types/event.go`](https://github.com/crowdsecurity/crowdsec/blob/master/pkg/types/event.go) for detailed definition_
### **Overflow or SignalOccurence**
This object holds the relevant information about a scenario that happened : who / when / where / what etc.
Its most relevant fields are :
- `Scenario` : name of the scenario
- `Alert_message` : a humanly readable message about what happened
- `Events_count` : the number of individual events that lead to said overflow
- `Start_at` + `Stop_at` : timestamp of the first and last events that triggered the scenario
- `Source` : a binary representation of the source of the attack
- `Source_[ip,range,AutonomousSystemNumber,AutonomousSystemOrganization,Country]` : string representation of source information
- `Labels` : an associative array representing the scenario "labels" (see scenario definition)
_Other fields omitted for clarity, see [`pkg/types/signal_occurence.go`](https://github.com/crowdsecurity/crowdsec/blob/master/pkg/types/signal_occurence.go) for detailed definition_
### **Acquisition**
Acquisition and its config (`acquis.yaml`) specify a list of files/ streams to read from (at the time of writing, files are the only input stream supported).
On common setups, {{wizard.name}} interactive installation will take care of it.
File acquisition configuration is defined as :
```yaml
filenames: #a list of file or regexp to read from (supports regular expressions)
- /var/log/nginx/http_access.log
- /var/log/nginx/https_access.log
- /var/log/nginx/error.log
labels:
prog_name: nginx
---
filenames:
- /var/log/auth.log
labels:
type: syslog
```
The `labels` part is here to tag the incoming logs with a type. `labels.prog_name` and `labels.type` are used by the parsers to know which logs to process.
### **Parser**
A parser is a YAML configuration file that describes how a string is being parsed. Said string can be a log line, or a field extracted from a previous parser. While a lot of parsers rely on the **GROK** approach (a.k.a regular expression named capture groups), parsers can as well reference enrichment modules to allow specific data processing.
Parsers are organized into stages to allow pipelines and branching in parsing.
See the [{{hub.name}}]({{hub.url}}) to explore parsers, or see below some examples :
- [apache2 access/error log parser](https://github.com/crowdsecurity/hub/blob/master/parsers/s01-parse/crowdsecurity/apache2-logs.yaml)
- [iptables logs parser](https://github.com/crowdsecurity/hub/blob/master/parsers/s01-parse/crowdsecurity/iptables-logs.yaml)
- [http logs post-processing](https://github.com/crowdsecurity/hub/blob/master/parsers/s02-enrich/crowdsecurity/http-logs.yaml)
### **Parser node**
A node is an individual parsing description.
Several nodes might be presented in a single parser file.
### **Node success or failure**
When an {{event.htmlname}} enters a node (because the filter returned true), it can be considered as a success or a failure.
The node will be successful if a grok pattern is present and successfully returned data.
A node is considered to have failed if a grok pattern is present but didn't return data.
If no grok pattern is present, the node will be considered successful.
It ensures that once an event has been parsed, it won't attempt to be processed by other nodes.
### **Stages**
Parsers are organized into "stages" to allow pipelines and branching in parsing.
Each parser belongs to a stage, and can trigger next stage when successful.
At the time of writing, the parsers are organized around 3 stages :
- `s00-raw` : low level parser, such as syslog
- `s01-parse` : most of the services parsers (ssh, nginx etc.)
- `s02-enrich` : enrichment that requires parsed events (ie. geoip-enrichment) or generic parsers that apply on parsed logs (ie. second stage http parser)
The number and structure of stages can be altered by the user, the directory structure and their alphabetical order dictates in which order stages and parsers are processed.
### **Enricher**
An enricher is a parser that will call external code to process the data instead of processing data based on a regular expression.
See the [geoip-enrich](https://github.com/crowdsecurity/hub/blob/master/parsers/s02-enrich/crowdsecurity/geoip-enrich.yaml) as an example.
### **Scenario**
A scenario is a YAML configuration file that describes a set of events characterizing a scenario.
Scenarios in {{crowdsec.name}} gravitate around the [leaky bucket](https://en.wikipedia.org/wiki/Leaky_bucket) principle.
A scenario description includes at least :
- Event eligibility rules. (For example if we're writing a ssh bruteforce detection we only focus on logs of type `ssh_failed_auth`)
- Bucket configuration such as the leak speed or its capacity (in our same ssh bruteforce example, we might allow 1 failed auth per 10s and no more than 5 in a short amount of time: `leakspeed: 10s` `capacity: 5`)
- Aggregation rules : per source ip or per other criterias (in our ssh bruteforce example, we will group per source ip)
The description allows for many other rules to be specified (blackhole, distinct filters etc.), to allow rather complex scenarios.
See the [{{hub.name}}]({{hub.url}}) to explore scenarios and their capabilities, or see below some examples :
- [ssh bruteforce detection](https://github.com/crowdsecurity/hub/blob/master/scenarios/crowdsecurity/ssh-bf.yaml)
- [distinct http-404 scan](https://github.com/crowdsecurity/hub/blob/master/scenarios/crowdsecurity/http-scan-uniques_404.yaml)
- [iptables port scan](https://github.com/crowdsecurity/hub/blob/master/scenarios/crowdsecurity/iptables-scan-multi_ports.yaml)
### **PostOverflow**
A postoverflow is a parser that will be applied on overflows (scenario results) before the decision is written to local DB or pushed to API. Parsers in postoverflows are meant to be used for "expensive" enrichment/parsing process that you do not want to perform on all incoming events, but rather on decision that are about to be taken.
An example could be slack/mattermost enrichment plugin that requires human confirmation before applying the decision or reverse-dns lookup operations.

View file

@ -0,0 +1,64 @@
# Installation
Fetch {{crowdsec.name}}'s latest version [here]({{crowdsec.download_url}}).
```bash
tar xvzf crowdsec-release.tgz
```
```bash
cd crowdsec-v0.X.X
```
A {{wizard.name}} is provided to help you deploy {{crowdsec.name}} and {{cli.name}}.
## Using the interactive wizard
```
sudo {{wizard.bin}} -i
```
![crowdsec](../assets/images/crowdsec_install.gif)
The {{wizard.name}} is going to guide you through the following steps :
- detect services that are present on your machine
- detect selected services logs
- suggest collections (parsers and scenarios) to deploy
- deploy & configure {{crowdsec.name}} in order to watch selected logs for selected scenarios
The process should take less than a minute, [please report if there are any issues]({{wizard.bugreport}}).
You are then ready to [take a tour](/getting_started/crowdsec-tour/) of your freshly deployed {{crowdsec.name}} !
## Using unattended mode
> you of little faith
```
sudo {{wizard.bin}} --bininstall
```
This will deploy a valid/empty {{crowdsec.name}} configuration files and binaries.
Beware, in this state, {{crowdsec.name}} won't monitor/detect anything unless configured.
## From source
!!! warning "Requirements"
* [Go](https://golang.org/doc/install) v1.13+
* `git clone {{crowdsec.url}}`
Go in {{crowdsec.name}} folder and build the binaries :
```bash
cd crowdsec
```
```bash
make build
```
{{crowdsec.name}} bin will be located in `./cmd/crowdsec/crowdsec` and {{cli.name}} bin in `cmd/crowdsec-cli/{{cli.bin}}`
Now, you can install either with [interactive wizard](#using-the-interactive-wizard) or the [unattended mode](#using-unattended-mode).

View file

@ -0,0 +1,83 @@
!!! info
Please note that the `{{config.acquis_path}}` should be auto generated by the {{wizard.name}} in most case.
The acquisition configuration specifies lists of files to monitor and associated "labels".
The `type` label is mandatory as it's later used in the process to determine which parser(s) can handle lines coming from this source.
Acquisition can be found in `{{config.acquis_path}}`, for example :
<details>
<summary>Acquisition example</summary>
```yaml
filenames:
- /var/log/nginx/access-*.log
- /var/log/nginx/error.log
labels:
type: nginx
---
filenames:
- /var/log/auth.log
labels:
type: syslog
```
</details>
## Testing and viewing acquisition
### At startup
At startup, you will see the monitored files in `{{crowdsec.main_log}}` :
```
...
time="30-04-2020 08:57:25" level=info msg="Opening file '/var/log/nginx/http.access.log' (pattern:/var/log/nginx/http.access.log)"
time="30-04-2020 08:57:25" level=info msg="Opening file '/var/log/nginx/https.access.log' (pattern:/var/log/nginx/https.access.log)"
time="30-04-2020 08:57:25" level=info msg="Opening file '/var/log/nginx/error.log' (pattern:/var/log/nginx/error.log)"
time="30-04-2020 08:57:25" level=info msg="Opening file '/var/log/auth.log' (pattern:/var/log/auth.log)"
time="30-04-2020 08:57:25" level=info msg="Opening file '/var/log/syslog' (pattern:/var/log/syslog)"
time="30-04-2020 08:57:25" level=info msg="Opening file '/var/log/kern.log' (pattern:/var/log/kern.log)"
...
```
### At runtime
{{cli.name}} allows you to view {{crowdsec.name}} metrics info via the `metrics` command.
This allows you to see how many lines are coming from each source, and if they are parsed correctly.
You can see those metrics with the following command:
```
{{cli.bin}} metrics
```
<details>
<summary>{{cli.name}} metrics example</summary>
```bash
## {{cli.bin}} metrics
...
INFO[0000] Acquisition Metrics:
+------------------------------------------+------------+--------------+----------------+------------------------+
| SOURCE | LINES READ | LINES PARSED | LINES UNPARSED | LINES POURED TO BUCKET |
+------------------------------------------+------------+--------------+----------------+------------------------+
| /var/log/nginx/http.access.log | 47 | 46 | 1 | 10 |
| /var/log/nginx/https.access.log | 25 | 25 | - | 18 |
| /var/log/kern.log | 297948 | 297948 | - | 69421 |
| /var/log/syslog | 303868 | 297947 | 5921 | 71539 |
| /var/log/auth.log | 63419 | 12896 | 50523 | 20463 |
| /var/log/nginx/error.log | 65 | 65 | - | - |
+------------------------------------------+------------+--------------+----------------+------------------------+
...
```
</details>
!!! info
All these metrics are actually coming from {{crowdsec.name}}'s prometheus agent. See [prometheus](/observability/metrics/) directly for more insights.

View file

@ -0,0 +1,21 @@
Enrichers are basically {{parsers.htmlname}} that can rely on external methods to provide extra contextual information to the event. The enrichers are usually in the `s02-enrich` {{stages.htmlname}} (after most of the parsing happened).
Enrichers functions should all accept a string as a parameter, and return an associative string array, that will be automatically merged into the `Enriched` map of the {{event.htmlname}}.
!!! warning
At the time of writing, enrichers plugin mechanism implementation is still ongoing (read: the list of available is currently hardcoded).
As an example let's look into the geoip-enrich parser/enricher :
It relies on [the geolite2 data created by maxmind](https://www.maxmind.com) and the [geoip2 golang module](https://github.com/oschwald/geoip2-golang) to provide the actual data.
It exposes three methods : `GeoIpCity` `GeoIpASN` and `IpToRange` that are used by the `crowdsecurity/geoip-enrich`.
Enrichers can be installed as any other parsers with the following command:
```
{{cli.bin}} install parser crowdsecurity/geoip-enrich
```
Take a tour at the {{hub.htmlname}} to find them !

View file

@ -0,0 +1,139 @@
{{crowdsec.name}} configuration lives under `{{config.crowdsec_dir}}` and should be as :
## default.yaml
This is the 'main' configuration file, it allows to specify parameters such as :
- logging (level and media)
- directories (config, data, runtime)
- API flag (on/off)
- prometheus (on/off)
- etc.
<details>
<summary>Default configuration</summary>
```yaml
working_dir: /tmp/
data_dir: /var/lib/crowdsec/data
config_dir: /etc/crowdsec/config
pid_dir: /var/run
log_dir: /var/log/
log_mode: file
log_level: info
profiling: false
apimode: true
daemon: true
prometheus: true
#for prometheus agent / golang debugging
http_listen: 127.0.0.1:6060
plugin:
backend: "/etc/crowdsec/plugins/backend"
```
</details>
#### `working_dir:`
The working directory where Prometheus will write metrics in text file.
#### `data_dir:`
Directory where {{crowdsec.Name}} will install its data ({{crowdsec.Name}} database for example).
#### `pid_dir:`
To specify where {{crowdsec.Name}} PID file will be stored.
#### `config_dir:`
To specify where {{crowdsec.Name}} configuration will be stored.
#### `log_dir:`
To specify where the logs should be stored.
#### `log_mode:`
To specify your selected logging mode, available modes are :
* `file` : to write logs in a file
* `stdout` : to write logs in STDOUT
#### `log_level:`
To specify the logging level, available levels:
* `debug`
* `info`
* `warning`
* `error`
#### `profiling:`
To enable or disable the profiling in {{crowdsec.Name}}.
#### `apimode:`
To enable or disable signals sending to the {{api.htmlname}}.
#### `daemon:`
To enable or disable {{crowdsec.Name}} daemon mode.
#### `prometheus:`
To enable or disable Prometheus metrics.
#### `http_listen:`
To configure the Prometheus service listening `address:port` or {{crowdsec.Name}} profiling
#### `plugin:`
To specify the directories where {{ref.output}} plugins will be stored :
* `backend:` : the path where all {{crowdsec.Name}} backend plugins (database output, ...) will be located.
## acquis.yaml
This is the file that tells which streams (or files) {{crowdsec.name}} is reading, and their types (so that it knows how to parse them). If you're lucky, this file should be auto-generated by the wizard.
You can find details on the configuration file format [here](/guide/crowdsec/acquisition/).
## api.yaml
Name is self-explanatory : it holds API configuration.
This file should never be edited by a human : the wizard will deploy safe default for it, and {{cli.name}} will alter it on your behalf when you register or enroll your machine.
You can look into it, and you should see :
- url endpoints
- login and password (auto-generated by your machine upon registration)
To get new credentials :
```bash
{{cli.name}} api register
```
Or if you loose your credentials:
```bash
{{cli.name}} api reset
```
## profiles.yaml
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 ?
Behind the scenes, the "profiles" system actually allows you to dispatch an event/overflow to various output plugins.
You can find details on the configuration file format of {{ref.output}}.
## parsers/
This directory holds all the {{parsers.htmlname}} that are enabled on your system.
The parsers are organized in {{stages.htmlname}} (which are just folders) and the {{parsers.htmlname}} themselves are yaml files.
## scenarios/
This directory holds all the {{scenarios.htmlname}} that are enabled on your system.
The {{scenarios.htmlname}} are yaml files.

View file

@ -0,0 +1,101 @@
## Listing installed parsers
{{parsers.Htmlname}} are yaml files in `{{config.crowdsec_dir}}parsers/<STAGE>/parser.yaml`.
!!! info
Alphabetical file order dictates the order of {{stages.htmlname}} and the orders of parsers within stage.
You can use the following command to view installed parsers:
```
{{cli.bin}} list parsers
```
<details>
<summary>{{cli.name}} list example</summary>
```bash
# {{cli.name}} list parsers
INFO[0000] Loaded 9 collecs, 14 parsers, 12 scenarios, 1 post-overflow parsers
--------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
--------------------------------------------------------------------------------------------------------------------
crowdsec/iptables-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/iptables-logs.yaml
crowdsec/dateparse-enrich ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/dateparse-enrich.yaml
crowdsec/sshd-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/sshd-logs.yaml
crowdsec/whitelists ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/whitelists.yaml
crowdsec/http-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/http-logs.yaml
crowdsec/nginx-logs ✔️ enabled 0.3 /etc/crowdsec/config/parsers/s01-parse/nginx-logs.yaml
crowdsec/syslog-logs ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s00-raw/syslog-logs.yaml
crowdsec/geoip-enrich ✔️ enabled 0.4 /etc/crowdsec/config/parsers/s02-enrich/geoip-enrich.yaml
--------------------------------------------------------------------------------------------------------------------
```
</details>
## Installing parsers
### From the hub
[{{hub.name}}]({{hub.parsers_url}}) allows you to find needed scenarios, just paste the command on your machine :
![Hub Screenshot](/assets/images/hub_parser.png)
```bash
# {{cli.name}} install parser crowdsec/nginx-logs
INFO[0000] Loaded 9 collecs, 14 parsers, 12 scenarios, 1 post-overflow parsers
INFO[0000] crowdsec/nginx-logs : OK
INFO[0000] Enabled parsers : crowdsec/nginx-logs
INFO[0000] Enabled crowdsec/nginx-logs
# systemctl restart crowdsec
```
### Your own parsers
[Write your parser configuration](/write_configurations/parsers/) and deploy yaml file in `{{config.crowdsec_dir}}parsers/<STAGE>/`.
## Monitoring parsers behavior
{{cli.name}} allows you to view {{crowdsec.name}} metrics info via the `metrics` command.
This allows you to see how many logs were ingested and then parsed or unparsed by said parser.
You can see those metrics with the following command:
```
cscli metrics
```
<details>
<summary>{{cli.name}} metrics example</summary>
```bash
# {{cli.name}} metrics
...
INFO[0000] Parser Metrics:
+---------------------------+--------+--------+----------+
| PARSERS | HITS | PARSED | UNPARSED |
+---------------------------+--------+--------+----------+
| crowdsec/sshd-logs | 62424 | 12922 | 49502 |
| crowdsec/syslog-logs | 667417 | 667417 | 0 |
| crowdsec/whitelists | 610901 | 610901 | 0 |
| crowdsec/http-logs | 136 | 21 | 115 |
| crowdsec/iptables-logs | 597843 | 597843 | 0 |
| crowdsec/nginx-logs | 137 | 136 | 1 |
| crowdsec/dateparse-enrich | 610901 | 610901 | 0 |
| crowdsec/geoip-enrich | 610836 | 610836 | 0 |
| crowdsec/non-syslog | 137 | 137 | 0 |
+---------------------------+--------+--------+----------+
```
</details>
## Going further
If you're interested into [understanding how parsers are made](/references/parsers/) or writing your own, please have a look at [this page](/write_configurations/parsers/).

View file

@ -0,0 +1,92 @@
Scenarios are yaml files that define "buckets".
Most of the scenarios currently rely on the [leaky bucket](https://en.wikipedia.org/wiki/Leaky_bucket) concept.
Scenarios lead to the instantiation, and sometime the overflow, of buckets.
When a bucket "overflows", the scenario is considered as having been realized.
This event leads to the creation of a new {{event.htmlname}} that describes the scenario that just happened (via a {{signal.htmlname}}).
## Listing installed scenarios
scenarios are yaml files in `{{config.crowdsec_dir}}scenarios/<scenario>.yaml`.
You can view installed scenarios with the following command:
```
{{cli.bin}} list scenarios
```
<details>
<summary>{{cli.name}} list example</summary>
```bash
# {{cli.name}} list scenarios
INFO[0000] Loaded 9 collecs, 14 parsers, 12 scenarios, 1 post-overflow parsers
-----------------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
-----------------------------------------------------------------------------------------------------------------------------
crowdsec/http-scan-uniques_404 ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/http-scan-uniques_404.yaml
crowdsec/ssh-bf ✔️ enabled 0.8 /etc/crowdsec/config/scenarios/ssh-bf.yaml
crowdsec/http-crawl-non_statics ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/http-crawl-non_statics.yaml
crowdsec/iptables-scan-multi_ports ✔️ enabled 0.4 /etc/crowdsec/config/scenarios/iptables-scan-multi_ports.yaml
-----------------------------------------------------------------------------------------------------------------------------
```
</details>
## Installing scenarios
### From the hub
[{{hub.name}}]({{hub.scenarios_url}}) allows you to find needed scenarios, just paste the command on your machine :
![Hub Screenshot](/assets/images/hub_scenario.png)
```bash
# {{cli.name}} install scenario crowdsec/ssh-bf
INFO[0000] Loaded 9 collecs, 14 parsers, 12 scenarios, 1 post-overflow parsers
INFO[0000] crowdsec/ssh-bf : OK
INFO[0000] Enabled scenarios : crowdsec/ssh-bf
INFO[0000] Enabled crowdsec/ssh-bf
# systemctl restart crowdsec
```
### Your own scenarios
[Write your scenario configuration](/write_configurations/scenarios/) and deploy yaml file in `{{config.crowdsec_dir}}scenarios/<scenario.yaml>`.
## Monitoring scenarios behavior
{{cli.name}} allows you to view {{crowdsec.name}} metrics info via the `metrics` command.
This allows you to see how many "buckets" associated to each scenario have been created (an event eligible from said scenario has arrived), poured (how many subsequent events have been pushed to said bucket), overflowed (the scenario happened) or underflow (there was not enough event to make the bucket overflow, and it thus expired after a while).
You can see those metrics with the following command:
```
{{cli.bin}} metrics
```
<details>
<summary>{{cli.name}} metrics example</summary>
```bash
# {{cli.name}} metrics
INFO[0000] Buckets Metrics:
+------------------------------------+-----------+--------------+--------+---------+
| BUCKET | OVERFLOWS | INSTANTIATED | POURED | EXPIRED |
+------------------------------------+-----------+--------------+--------+---------+
| crowdsec/http-crawl-non_statics | - | 9 | 14 | 9 |
| crowdsec/http-scan-uniques_404 | - | 11 | 14 | 11 |
| crowdsec/iptables-scan-multi_ports | 13 | 125681 | 141601 | 125650 |
| crowdsec/ssh-bf | 669 | 3721 | 12925 | 3046 |
| crowdsec/ssh-bf_user-enum | 136 | 4093 | 7587 | 3956 |
+------------------------------------+-----------+--------------+--------+---------+
```
</details>

36
docs/guide/cscli.md Normal file
View file

@ -0,0 +1,36 @@
`{{cli.bin}}` is the utility that will help you to manage {{crowdsec.name}}. This tools has the following functionalities:
- [manage bans]({{ cli.ban_doc }}) : list, add, remove ...
- [backup and restore]({{ cli.backup_doc }}) configuration
- [display metrics]({{ cli.metrics_doc }})
- [install]({{ cli.install_doc }}) parsers/scenarios/collections
- [remove]({{ cli.remove_doc }}) parsers/scenarios/collections
- [update]({{ cli.update_doc }}) the hub cache
- [upgrade]({{ cli.upgrade_doc }}) parsers/scenarios/collections
- [list]({{ cli.list_doc }}) parsers/scenarios/collections
- [interact with CrowdSec API]({{ cli.api_doc }})
## Overview
{{cli.name}} configuration location is `/etc/crowdsec/cscli/`.
In this folder, we store the {{cli.name}} configuration and the hub cache files.
## Config
The {{cli.name}} configuration is light for now, stored in `/etc/crowdsec/cscli/config`.
```yaml
installdir: /etc/crowdsec/config # {{crowdsec.name}} configuration location
backend: /etc/crowdsec/plugins/backend # path to the backend plugin used
```
For {{cli.name}} to be able to pull the {{api.topX.htmlname}}, you need a valid API configuration in [api.yaml](/guide/crowdsec/overview/#apiyaml).
## Hub cache
- `.index.json`: The file containing the metadata of all the existing {{collections.htmlname}}, {{parsers.htmlname}} and {{scenarios.htmlname}} stored in the {{hub.htmlname}}.
- `hub/*`: Folder containing all the {{collections.htmlname}}, {{parsers.htmlname}} and {{scenarios.htmlname}} stored in the {{hub.htmlname}}.
This is used to manage configurations from the {{cli.name}}

10
docs/guide/overview.md Normal file
View file

@ -0,0 +1,10 @@
When talking about {{crowdsec.name}} or {{cli.name}} configurations, most of things are going to gravitate around {{parsers.htmlname}}, {{scenarios.htmlname}} and {{collections.htmlname}}.
In most common setup, all these configurations should be found on the {{hub.htmlname}} and installed with {{cli.name}}.
It is important to keep those configurations up-to-date via the `{{cli.name}} upgrade` command.
See the [{{cli.name}} list](/cheat_sheets/cscli-collections-tour/) command to view the state of your deployed configurations.

39
docs/index.md Normal file
View file

@ -0,0 +1,39 @@
<center>[[Hub]]({{hub.url}}) [[Releases]]({{crowdsec.download_url}})</center>
# What is {{crowdsec.Name}} ?
{{crowdsec.Name}} is an open-source and lightweight software, that reads logs from different sources (files, streams ...) to parse, normalize and enrich them before comparing them to scenarios.
Scenarios describe more or less specific attacks, ultimately allowing to report malevolent actors and take further action, such as blocking, reporting, throttling etc.
One of the advantages of {{crowdsec.name}} 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.
Besides detecting and stopping attacks in real time based on your logs, it allows you to preemptively block known malevolent actors from accessing your information system.
## Components
{{crowdsec.name}} ecosystem is based on the following tools :
- {{crowdsec.name}} is the "service" that runs in the background, 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
- [{{plugins.name}}]({{hub.plugins_url}}) are the components that block malevolent traffic, and can be deployed anywhere in your stack
## Architecture
![Architecture](assets/images/crowdsec_architecture.png)
## Moving forward
To learn more about {{crowdsec.name}} and give it a try, please see :
- [How to install {{crowdsec.name}}](/getting_started/installation/)
- [Take a quick tour of {{crowdsec.name}} and {{cli.name}} features](/getting_started/crowdsec-tour/)
- [Deploy {{plugins.name}} to stop malevolent peers](/blockers/)
- [Observability of {{crowdsec.name}}](/observability/overview/)
- [Understand {{crowdsec.name}} configuration](/getting_started/concepts/)
- [FAQ](getting_started/FAQ/)
If you have a functional {{crowdsec.name}} setup, you might want to find the right [{{plugins.name}}](/blockers/).
Don't hesitate to look at the [glossary](/getting_started/glossary/) for clarification !

View file

@ -0,0 +1,48 @@
As the default database is sqlite, we use [metabase](https://www.metabase.com/) to visualize the data stored in it.
The {{cli.name}} command `{{cli.bin}} dashboard setup` will use docker to install [metabase docker image](https://hub.docker.com/r/metabase/metabase/) and fetch our metabase template to have a configured and ready dashboard.
!!! warning "Dependencies"
* [Docker](https://docs.docker.com/)
Once the dashboard is setup, an URL and credentials are provided to connect to the dashboard.
!!! note
Depending on your machine ressource, `{{cli.bin}} dashboard setup` might take a few minutes to finish.
```bash
{{cli.bin}} dashboard setup
```
```bash
INFO[0000] /var/lib/crowdsec/data/metabase.db exists, skip.
INFO[0000] Downloaded metabase DB
INFO[0000] Pulling docker image metabase/metabase
...
INFO[0001] Creating container
INFO[0001] Starting container
INFO[0002] Started metabase
INFO[0002] Waiting for metabase API to be up (can take up to a minute)
...........
INFO[0034] Metabase API is up
INFO[0034] Successfully authenticated
INFO[0034] Changed password !
INFO[0034] Setup finished
INFO[0034] url : http://127.0.0.1:3000
INFO[0034] username: metabase@crowdsec.net
INFO[0034] password: W1XJb8iw1A02U5nW7xxxxXXXxxXXXxXXxxXXXxxxXxXxXxXPdbvQdLlshqqPg8pf
```
!!! tip "Protip"
Don't forget to save your credentials !!
Now you can connect to your dashboard, sign-in with your saved credentials then click on {{crowdsec.Name}} Dashboard to get this:
![Dashboard_view](../assets/images/dashboard_view.png)
Dashboard docker image can be managed by {{cli.name}} and docker cli also. Look at the {{cli.name}} help command using
```bash
{{cli.bin}} dashboard -h
```

View file

@ -0,0 +1,30 @@
Logs concern everything that happens to {{crowdsec.Name}} itself (startup, configuration, events like IP ban or an alert, shutdown, and so on).
By default, logs are written to `{{crowdsec.main_log}}`, in text format.
<details>
<summary>Logs example</summary>
```bash
time="12-05-2020 15:34:21" level=info msg="setting loglevel to info"
time="12-05-2020 15:34:21" level=info msg="Crowdsec v0.0.19-9ae496aa9cfd008513976a096accc7cfc43f2d9b"
time="12-05-2020 15:34:21" level=warning msg="Loading prometheus collectors"
time="12-05-2020 15:34:23" level=warning msg="no version in /etc/crowdsec/config/parsers/s00-raw/syslog-logs.yaml, assuming '1.0'"
time="12-05-2020 15:34:23" level=warning msg="Starting profiling and http server"
time="12-05-2020 15:34:24" level=warning msg="no version in /etc/crowdsec/config/parsers/s00-raw/syslog-logs.yaml, assuming '1.0'"
time="12-05-2020 15:34:24" level=info msg="Node has no name,author or description. Skipping."
time="12-05-2020 15:34:24" level=info msg="Loading 2 parser nodes" file=/etc/crowdsec/config/parsers/s00-raw/syslog-logs.yaml
time="12-05-2020 15:34:24" level=warning msg="no version in /etc/crowdsec/config/parsers/s01-parse/nginx-logs.yaml, assuming '1.0'"
time="12-05-2020 15:34:24" level=info msg="Loading 3 parser nodes" file=/etc/crowdsec/config/parsers/s01-parse/nginx-logs.yaml
time="12-05-2020 15:34:24" level=warning msg="no version in /etc/crowdsec/config/parsers/s01-parse/sshd-logs.yaml, assuming '1.0'"
time="13-05-2020 17:42:53" level=warning msg="24 existing LeakyRoutine"
time="13-05-2020 18:02:51" level=info msg="Flushed 1 expired entries from Ban Application"
time="13-05-2020 18:12:46" level=info msg="Flushed 1 expired entries from Ban Application"
time="13-05-2020 18:20:29" level=warning msg="11.11.11.11 triggered a 4h0m0s ip ban remediation for [crowdsecurity/ssh-bf]" bucket_id=winter-shadow event_time="2020-05-13 18:20:29.855776892 +0200 CEST m=+96112.558589990" scenario=crowdsecurity/ssh-bf source_ip=11.11.11.11
time="13-05-2020 18:31:26" level=warning msg="22.22.22.22 triggered a 4h0m0s ip ban remediation for [crowdsecurity/ssh-bf]" bucket_id=dry-mountain event_time="2020-05-13 18:31:26.989769738 +0200 CEST m=+96769.692582872" scenario=crowdsecurity/ssh-bf source_ip=22.22.22.22
time="13-05-2020 18:41:10" level=warning msg="16 existing LeakyRoutine"
time="13-05-2020 18:46:19" level=warning msg="33.33.33.33 triggered a 4h0m0s ip ban remediation for [crowdsecurity/iptables-scan-multi_ports]" bucket_id=holy-paper event_time="2020-05-13 18:46:19.825693323 +0200 CEST m=+97662.528506421" scenario=crowdsecurity/iptables-scan-multi_ports source_ip=33.33.33.33
```
</details>

View file

@ -0,0 +1,118 @@
## metrics via {{cli.name}}
```bash
{{cli.name}} metrics
```
This command provides an overview of {{crowdsec.name}} statistics. By default it assumes that the {{crowdsec.name}} is installed on the same machine.
The metrics are split in 3 main sections :
- Acquisition metrics : How many lines were read from which sources, how many were successfully or unsuccessfully parsed, and how many of those lines ultimately ended up being poured to a bucket.
- Parser metrics : How many lines were fed (eligible) to each parser, and how many of those were successfully or unsuccessfully parsed.
- Bucket metrics : How many time each scenario lead to a bucket instantiation, and for each of those :
- how many times it overflowed
- how many times it expired (underflows)
- how many subsequent events were poured to said bucket
!!! hint
These metrics should help you identify potential configuration errors.
For example, if you have a source that has mostly unparsed logs, you know you might be missing some parsers.
As well, if you have scenarios that are never instantiated, it might be a hint that they are not relevant to your configuration.
<details>
<summary>{{cli.name}} metrics example</summary>
```bash
INFO[0000] Buckets Metrics:
+-----------------------------------------+-----------+--------------+--------+---------+
| BUCKET | OVERFLOWS | INSTANTIATED | POURED | EXPIRED |
+-----------------------------------------+-----------+--------------+--------+---------+
| crowdsecurity/http-scan-uniques_404 | - | 8 | 9 | 8 |
| crowdsecurity/iptables-scan-multi_ports | 1 | 8306 | 9097 | 8288 |
| crowdsecurity/ssh-bf | 42 | 281 | 1434 | 238 |
| crowdsecurity/ssh-bf_user-enum | 13 | 659 | 777 | 646 |
| crowdsecurity/http-crawl-non_statics | - | 10 | 12 | 10 |
+-----------------------------------------+-----------+--------------+--------+---------+
INFO[0000] Acquisition Metrics:
+------------------------------------------+------------+--------------+----------------+------------------------+
| SOURCE | LINES READ | LINES PARSED | LINES UNPARSED | LINES POURED TO BUCKET |
+------------------------------------------+------------+--------------+----------------+------------------------+
| /var/log/nginx/https.access.log | 25 | 25 | - | 7 |
| /var/log/kern.log | 18078 | 18078 | - | 4066 |
| /var/log/syslog | 18499 | 18078 | 421 | 5031 |
| /var/log/auth.log | 6086 | 1434 | 4652 | 2211 |
| /var/log/nginx/error.log | 170243 | 169632 | 611 | - |
| /var/log/nginx/http.access.log | 44 | 44 | - | 14 |
+------------------------------------------+------------+--------------+----------------+------------------------+
INFO[0000] Parser Metrics:
+--------------------------------+--------+--------+----------+
| PARSERS | HITS | PARSED | UNPARSED |
+--------------------------------+--------+--------+----------+
| crowdsecurity/geoip-enrich | 37659 | 37659 | 0 |
| crowdsecurity/http-logs | 169701 | 27 | 169674 |
| crowdsecurity/iptables-logs | 36156 | 36156 | 0 |
| crowdsecurity/nginx-logs | 170316 | 169701 | 615 |
| crowdsecurity/non-syslog | 170312 | 170312 | 0 |
| crowdsecurity/sshd-logs | 6053 | 1434 | 4619 |
| crowdsecurity/syslog-logs | 42663 | 42663 | 0 |
| crowdsecurity/dateparse-enrich | 207291 | 207291 | 0 |
+--------------------------------+--------+--------+----------+
```
</details>
## metrics via {{crowdsec.name}} prometheus
{{crowdsec.name}} can expose a prometheus endpoint for collection (on `http://127.0.0.1:6060/metrics` by default).
The goal of this endpoint, besides the usual resources consumption monitoring, aims at offering a view of {{crowdsec.name}} "applicative" behavior :
- is it processing a lot of logs ? is it parsing them successfully ?
- are a lot of scenarios being triggered ?
- are a lot of IPs banned ?
- etc.
All the counters are "since {{crowdsec.name}} start".
### Scenarios
- `cs_bucket_create` : number of instantiation of each scenario
- `cs_bucket_overflow` : number of overflow of each scenario
- `cs_bucket_underflow` : number of underflow of each scenario (bucket was created but expired because of lack of events)
- `cs_bucket_pour` : number of event poured to each scenario with source as complementary key :
```
#2030 lines from `/var/log/nginx/access.log` were poured to `crowdsecurity/http-scan-uniques_404` scenario
cs_bucket_pour{name="crowdsecurity/http-scan-uniques_404",source="/var/log/nginx/access.log"} 2030
```
### Parsers
- `cs_node_hits` : how many time an event from a specific source was processed by a parser node :
```
# 235 lines from `auth.log` were processed by the `crowdsecurity/dateparse-enrich` parser
cs_node_hits{name="crowdsecurity/dateparse-enrich",source="/var/log/auth.log"} 235
```
- `cs_node_hits_ko` : how many times an event from a specific was unsuccessfully parsed by a specific parser
```
# 2112 lines from `error.log` failed to be parsed by `crowdsecurity/http-logs`
cs_node_hits_ko{name="crowdsecurity/http-logs",source="/var/log/nginx/error.log"} 2112
```
- `cs_node_hits_ok` : how many times an event from a specific source was successfully parsed by a specific parser
- `cs_parser_hits` : how many times an event from a source has hit the parser
- `cs_parser_hits_ok` : how many times an event from a source was successfully parsed
- `cs_parser_hits_ko` : how many times an event from a source was unsuccessfully parsed
### Acquisition
- `cs_reader_hits` : how many events were read from a specific source

View file

@ -0,0 +1,13 @@
# Observability Overview
Observability in security software is crucial, especially when this software might take important decision such as blocking IP addresses.
We attempt to provide good observability of {{crowdsec.name}}'s behavior :
- {{crowdsec.name}} itself exposes a prometheus instrumentation
- {{cli.Name}} allows you to view part of prometheus metrics in cli (`{{cli.bin}} metrics`)
- {{crowdsec.name}} logging is contextualized for easy processing
- for **humans**, {{cli.name}} allows you to trivially start a service exposing dashboards (using [metabase](https://www.metabase.com/))
Furthermore, most of {{crowdsec.name}} configuration should allow you to enable partial debug (ie. per-scenario, per-parser etc.)

70
docs/references/output.md Normal file
View file

@ -0,0 +1,70 @@
# 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.
Please see [here](https://github.com/crowdsecurity/crowdsec/tree/master/plugins/backend) for the available backend plugin.
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.
## Profile
Here is a sample of a profile configuration:
```yaml
profile: <profile_name>
filter: "<filter_expression>"
api: true # default true : send signal to crowdsec API
outputs: # here choose your output plugins for this profile
- plugin: plugin1
custom_config: <config>
- plugin: plugin2
```
The default configuration that is deployed with {{crowdsec.name}} is the following one:
```yaml
profile: default_remediation
filter: "sig.Labels.remediation == 'true'"
api: true # If no api: specified, will use the default config in default.yaml
remediation:
ban: true
slow: true
captcha: true
duration: 4h
outputs:
- plugin: sqlite
---
profile: default_notification
filter: "sig.Labels.remediation != 'true'"
#remediation is empty, it means non taken
api: false
outputs:
- plugin: sqlite # If we do not want to push, we can remove this line and the next one
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.
## Plugins
Plugins configuration file are stored in `{{plugins.configpath}}`. {{crowdsec.name}} will scan this folder to load all the plugins. Each configuration file should provide the path to the plugin binary. By default they are stored in `{{plugins.binpath}}`.
!!! info
If you want crowdsec to not load a plugin, `mv` or `rm` its configuration file in `{{plugins.configpath}}`
Here is a sample of a plugin configuration file stored in `{{plugins.configpath}}`:
```yaml
name: <plugin_name>
path: <path_to_plugin_binary> #
config: <plugin_config> # in a form of key(string)/value(string)
```
For the plugin sqlite, here is its configuration file:
```yaml
name: sqlite
path: /var/lib/crowdsec/plugins/backend/sqlite.so
config:
db_path: /var/lib/crowdsec/data/crowdsec.db
flush: true
```

291
docs/references/parsers.md Normal file
View file

@ -0,0 +1,291 @@
## Understanding parsers
Parsers are configurations that define a transformation on an {{event.htmlname}}.
Parsers are expressed as YAML files composed of one or more individual 'parsing' nodes.
An {{event.htmlname}} can be the representation of a log line, or an overflow.
A parser itself can be used to perform various actions, including :
- Parse a string with regular expression (grok patterns)
- Enrich an event by relying on "external" code (such as the geoip-enrichment parser)
- Process one or more fields of an {{event.name}} with {{expr.htmlname}}
A parser node might look like :
```yaml
#if 'onsuccess' is 'next_stage', the event will make it to next stage if this node succeed
onsuccess: next_stage
#a 'debug' (bool) flag allow to enable node level debug in any node to enable local debug
debug: true
#a filter to decide if the Event is elligible for this parser node
filter: "evt.Parsed.program == 'kernel'"
#a unique name to allow easy debug & logging
name: crowdsecurity/demo-iptables
#this is for humans
description: "Parse iptables drop logs"
#we can define named capture groups (a-la-grok)
pattern_syntax:
MYCAP: ".*"
#an actual grok pattern (regular expression with named capture groupe)
grok:
pattern: ^xxheader %{MYCAP:extracted_value} trailing stuff$
#we define on which field the regular expression must be applied
apply_on: evt.Parsed.some_field
#statics are transformations that are applied on the event if the node is considered "successfull"
statics:
#to which field the value will be written (here -> evt.Meta.log_type)
- meta: log_type
#and here a static value
value: parsed_testlog
#another one
- meta: source_ip
#here the value stored is the result of a dynamic expression
expression: "evt.Parsed.src_ip"
```
The parser nodes are processed sequentially based on the alphabetical order of {{stages.htmlname}} and subsequent files.
If the node is considered successful (grok is present and returned data or no grok is present) and "onsuccess" equals to `next_stage`, then the {{event.name}} is moved to the next stage.
## Parser trees
A parser node can contain sub-nodes, to provide proper branching.
It can be useful when you want to apply different parsing based on different criterias, or when you have a set of candidates parsers that you want to apply to an event :
```yaml
#This first node will capture/extract some value
filter: "evt.Line.Labels.type == 'type1'"
name: tests/base-grok-root
pattern_syntax:
MYCAP: ".*"
grok:
pattern: ^... %{MYCAP:extracted_value} ...$
apply_on: Line.Raw
statics:
- meta: state
value: root-done
- meta: state_sub
expression: evt.Parsed.extracted_value
---
#and this node will apply different patterns to it
filter: "evt.Line.Labels.type == 'type1' && evt.Meta.state == 'root-done'"
name: tests/base-grok-leafs
onsuccess: next_stage
#the sub-nodes will process the result of the master node
nodes:
- filter: "evt.Parsed.extracted_value == 'VALUE1'"
debug: true
statics:
- meta: final_state
value: leaf1
- filter: "evt.Parsed.extracted_value == 'VALUE2'"
debug: true
statics:
- meta: final_state
value: leaf2
```
The logic is that the `tests/base-grok-root` node will be processed first and will alter the event (here mostly by extracting some text from the `Line.Raw` field into `Parsed` thanks to the `grok` pattern and the `statics` directive).
The event will then continue its life and be parsed by the the following `tests/base-grok-leafs` node.
This node has `onsuccess` set to `next_stage` which means that if the node is successful, the event will be moved to the next stage.
This node consists actually of two sub-nodes that have different conditions (branching) to allow differential treatment of said event.
A real-life example can be seen when it comes to parsing HTTP logs.
HTTP ACCESS and ERROR logs often have different formats, and thus our "nginx" parser needs to handle both formats
```yaml
filter: "evt.Parsed.program == 'nginx'"
onsuccess: next_stage
name: crowdsecurity/nginx-logs
nodes:
- grok:
#this is the access log
name: NGINXACCESS
apply_on: message
statics:
- meta: log_type
value: http_access-log
- target: evt.StrTime
expression: evt.Parsed.time_local
- grok:
# and this one the error log
name: NGINXERROR
apply_on: message
statics:
- meta: log_type
value: http_error-log
- target: evt.StrTime
expression: evt.Parsed.time
# these ones apply for both grok patterns
statics:
- meta: service
value: http
- meta: source_ip
expression: "evt.Parsed.remote_addr"
- meta: http_status
expression: "evt.Parsed.status"
- meta: http_path
expression: "evt.Parsed.request"
```
## Parser directives
### debug
```yaml
debug: true|false
```
_default: false_
If set to to `true`, enabled node level debugging.
It is meant to help understanding parser node behaviour by providing contextual logging.
### filter
```yaml
filter: expression
```
`filter` must be a valid {{expr.htmlname}} expression that will be evaluated against the {{event.name}}.
If `filter` evaluation returns true or is absent, node will be processed.
If `filter` returns `false` or a non-boolean, node won't be processed.
Examples :
- `filter: "evt.Meta.foo == 'test'"`
- `filter: "evt.Meta.bar == 'test' && evt.Meta.foo == 'test2'`
### grok
```yaml
grok:
name: NAMED_EXISTING_PATTERN
apply_on: source_field
```
```yaml
grok:
pattern: ^a valid RE2 expression with %{CAPTURE:field}$
apply_on: source_field
```
The `grok` structure in a node represent a regular expression with capture group (grok pattern) that must be applied on a field of {{event.name}}.
The pattern can :
- be imported by name (if present within the core of {{crowdsec.name}})
- defined in place
In both case, the pattern must be a valid RE2 expression.
The field(s) returned by the regular expression are going to be merged into the `Parsed` associative array of the `Event`.
### name
```yaml
name: explicit_string
```
The *mandatory* name of the node. If not present, node will be skipped at runtime.
It is used for example in debug log to help you track things.
### nodes
```yaml
nodes:
- filter: ...
grok: ...
```
`nodes` is a list of parser nodes, allowing you to build trees.
Each subnode must be valid, and if any of the subnodes succeed, the whole node is considered successful.
### onsuccess
```
onsuccess: next_stage|continue
```
_default: continue_
if set to `next_stage` and the node is considered successful, the {{event.name}} will be moved directly to next stage without processing other nodes in the current stage.
### pattern_syntax
```yaml
pattern_syntax:
CAPTURE_NAME: VALID_RE2_EXPRESSION
```
`pattern_syntax` allows user to define named capture group expressions for future use in grok patterns.
Regexp must be a valid RE2 expression.
```yaml
pattern_syntax:
MYCAP: ".*"
grok:
pattern: ^xxheader %{MYCAP:extracted_value} trailing stuff$
apply_on: Line.Raw
```
### statics
```yaml
statics:
- target: evt.Meta.target_field
value: static_value
- meta: target_field
expression: evt.Meta.target_field + ' this_is' + ' a dynamic expression'
- enriched: target_field
value: static_value
```
`statics` is a list of directives that will be executed when the node is considered successful.
Each entry of the list is composed of a target (where to write) and a source (what data to write).
**Target**
The target aims at being any part of the {{event.htmlname}} object, and can be expressed in different ways :
- `meta: <target_field>`
- `parsed: <target_field>`
- `enriched: <target_field>`
- a dynamic target (please note that the **current** event is accessible via the `evt.` variable) :
- `target: evt.Meta.foobar`
- `target: Meta.foobar`
- `target: evt.StrTime`
**Source**
The source itself can be either a static value, or an {{expr.htmlname}} result :
```yaml
statics:
- meta: target_field
value: static_value
- meta: target_field
expression: evt.Meta.another_field
- meta: target_field
expression: evt.Meta.target_field + ' this_is' + ' a dynamic expression'
```
## Parser concepts
### Success and failure
A parser is considered "successful" if :
- A grok pattern was present and successfully matched
- No grok pattern was present

View file

@ -0,0 +1,345 @@
## Understanding scenarios
Scenarios are YAML files that allow to detect and qualify a specific behavior, usually an attack.
Scenarios receive one or more {{event.htmlname}} and might produce one or more {{overflow.htmlname}}.
As an {{event.htmlname}} can be the representation of a log line, or an overflow, it allows scenarios to process both logs or overflows.
The scenario is usually based on a number of factors, at least :
- the speed/frequency at which events happen (see [leaky bucket](https://en.wikipedia.org/wiki/Leaky_bucket))
- the characteristic(s) of an {{event.htmlname}} : "log type XX with field YY set to ZZ"
Behind the scenes, {{crowdsec.name}} is going to create one or several buckets when event with matching characteristic arrive to the scenario. This bucket has a capacity and leak-speed, when the bucket "overflows", the scenario has been trigger.
_Bucket partitioning_ : One scenario usually leads to many bucket creation, as each bucket is only tracking a specific subset of events. For example, if we are tracking brute-force, it makes sense that each "offending peer" get its own bucket.
A way to detect a http scanner might be to track the number of distinct non-existing pages it's requesting, and the scenario might look like this :
```yaml
#the bucket type : leaky, trigger, counter
type: leaky
#name and description for humans
name: crowdsecurity/http-scan-uniques_404
description: "Detect multiple unique 404 from a single ip"
#a filter to know which events are eligible
filter: "evt.Meta.service == 'http' && evt.Meta.http_status in ['404', '403', '400']"
#how we are going to partition buckets
groupby: "evt.Meta.source_ip"
#we are only interested into counting UNIQUE/DISTINCT requested URLs
distinct: "evt.Meta.http_path"
#we specify the bucket capacity and leak speed
capacity: 5
leakspeed: "10s"
#this will prevent the same bucket from overflowing more often than every 5 minutes
blackhole: 5m
#some labels to give context to the overflow
labels:
service: http
type: scan
#yes we want to ban people triggering this
remediation: true
```
## Scenario concepts
### TimeMachine
{{crowdsec.name}} can be used not only to process live logs, but as well to process "cold" logs (think forensics).
For this to be able to work, the date/time from the log must have been properly parsed for the scenario temporal aspect to be able to work properly. This relies on the [dateparser enrichment](https://github.com/crowdsecurity/hub/blob/master/parsers/s02-enrich/crowdsecurity/dateparse-enrich.yaml)
## Scenario directives
### type
```yaml
type: leaky|trigger|counter
```
Defines the type of the bucket. Currently three types are supported :
- `leaky` : a [leaky bucket](https://en.wikipedia.org/wiki/Leaky_bucket) that must be configured with a {{capacity.htmlname}} and a {{leakspeed.htmlname}}
- `trigger` : a bucket that overflows as soon as an event is poured (it's like a leaky bucket is a capacity of 0)
- `counter` : a bucket that only overflows every {{duration.htmlname}}. It's especially useful to count things.
### name & description
```yaml
name: my_author_name/my_scenario_name
description: A scenario that detect XXXX behavior
```
Mandatory `name` and `description` for said scenario.
The name must be unique (and will define the scenario's name in the hub), and the description must be a quick sentence describing what it detects.
### filter
```yaml
filter: evt.Meta.log_type == 'telnet_new_session'
```
an {{expr.htmlname}} that must return true if the event is eligible for the bucket.
Examples :
- `evt.Meta.log_type == 'telnet_new_session'`
- `evt.Meta.log_type in ['http_access-log', 'http_error-log'] && evt.Parsed.static_ressource == 'false'`
- `evt.Meta.log_type == 'ssh_failed-auth'`
### duration
```yaml
duration: 45s
duration: 10m
```
(applicable to `counter` buckets only)
A duration after which the bucket will overflow.
The format must be compatible with [golang ParseDuration format](https://golang.org/pkg/time/#ParseDuration)
Examples :
```yaml
type: counter
name: crowdsecurity/ban-reports-ssh_bf_report
description: "Count unique ips performing ssh bruteforce"
filter: "evt.Overflow.Scenario == 'ssh_bruteforce'"
distinct: "evt.Overflow.Source_ip"
capacity: -1
duration: 10m
labels:
service: ssh
```
### groupby
```yaml
groupby: evt.Meta.source_ip
```
an {{expr.htmlname}} that must return a string. This string will be used as to partition the buckets.
Examples :
Here, each `source_ip` will get its own bucket.
```yaml
type: leaky
...
groupby: evt.Meta.source_ip
...
```
Here, each unique combo of `source_ip` + `target_username` will get its own bucket.
```yaml
type: leaky
...
groupby: evt.Meta.source_ip + '--' + evt.Parsed.target_username
...
```
### distinct
```yaml
distinct: evt.Meta.http_path
```
an {{expr.htmlname}} that must return a string. The event will be poured **only** if the string is not already present in the bucket.
Examples :
This will ensure that events that keep triggering the same `.Meta.http_path` will be poured only once.
```yaml
type: leaky
...
distinct: "evt.Meta.http_path"
...
```
In the logs, you can see it like this (for example from the iptables-logs portscan detection) :
```bash
DEBU[2020-05-13T11:29:51+02:00] Uniq(7681) : ok buck..
DEBU[2020-05-13T11:29:51+02:00] Uniq(7681) : ko, discard event buck..
```
The first event has been poured (value `7681`) was not yet present in the events, while the second time, the event got discarded because the value was already present in the bucket.
### capacity
```yaml
capacity: 5
```
(Applies only to `leaky` buckets)
A positive integer representing the bucket capacity.
If there are more than `capacity` item in the bucket, it will overflow.
### leakspeed
```yaml
leakspeed: "10s"
```
(Applies only to `leaky` buckets)
A duration that represent how often an event will be leaking from the bucket.
Must be compatible with [golang ParseDuration format](https://golang.org/pkg/time/#ParseDuration).
Example:
Here the bucket will leak one item every 10 seconds, and can hold up to 5 items before overflowing.
```yaml
type: leaky
...
leakspeed: "10s"
capacity: 5
...
```
### labels
```yaml
labels:
service: ssh
type: bruteforce
remediation: true
```
Labels is a list of `label: values` that provide context to an overflow.
The labels are (currently) not stored in the database, nor they are sent to the API.
Special labels :
- The **remediation** label, if set to `true` indicate the the originating IP should be ban.
- The **scope** label, can be set to `ip` or `range` when **remediation** is set to true, and indicate to which scope should the decision apply. If you set a scenario with **remediation** to true and **scope** to `range` and the range of the IP could have been determined by the GeoIP library, the whole range to which the IP belongs will be banned.
Example :
The IP that triggered the overflow (`.Meta.source_ip`) will be banned.
```yaml
type: leaky
...
labels:
service: ssh
type: bruteforce
remediation: true
```
The range to which the offending IP belong (`.Meta.source_ip`) will be banned.
```yaml
type: leaky
...
labels:
type: distributed_attack
remediation: true
scope: range
```
### blackhole
```yaml
blackhole: 10m
```
A duration for which a bucket will be "silenced" after overflowing.
This is intended to limit / avoid spam of buckets that might be very rapidly triggered.
The blackhole only applies to the individual bucket rather than the whole scenario.
Must be compatible with [golang ParseDuration format](https://golang.org/pkg/time/#ParseDuration).
Example :
The same `source_ip` won't be able to trigger this overflow more than once every 10 minutes.
The potential overflows in the meanwhile will be discarded (but will still appear in logs as being blackholed).
```yaml
type: trigger
...
blackhole: 10m
groupby: evt.Meta.source_ip
```
### debug
```yaml
debug: true|false
```
_default: false_
If set to to `true`, enabled scenario level debugging.
It is meant to help understanding scenario behavior by providing contextual logging.
### reprocess
```yaml
reprocess: true|false
```
_default: false_
If set to `true`, the resulting overflow will be sent again in the scenario/parsing pipeline.
It is useful when you want to have further scenarios that will rely on past-overflows to take decisions.
### cache_size
```yaml
cache_size: 5
```
By default, a bucket holds {{capacity.htmlname}} events "in memory".
However, for a number of cases, you don't want this, as it might lead to excessive memory consumption.
By setting `cache_size` to a positive integer, we can control the maximum in-memory cache size of the bucket, without changing its capacity and such. This is especially useful when using `counter` buckets on long duration that might end up counting (and this storing in memory) an important number of events.
### overflow_filter
```yaml
overflow_filter: any(queue.Queue, { .Enriched.IsInEU == "true" })
```
`overflow_filter` is an {{expr.htmlname}} that is run when the bucket overflows.
If this expression is present and returns false, the overflow will be discarded.

24
docs/requirements.txt Normal file
View file

@ -0,0 +1,24 @@
-i https://pypi.org/simple/
click==7.1.1
future==0.18.2
jinja2==2.11.1
joblib==0.14.1
livereload==2.6.1
lunr[languages]==0.5.6
markdown==3.2.1
markupsafe==1.1.1
mkdocs-material==4.6.3
mkdocs==1.1
mkdocs-macros-plugin==0.4.6
nltk==3.5b1
prompt-toolkit==3.0.5
pygments==2.6.1
pymdown-extensions==7.0rc1
python-markdown-math==0.6
pyyaml==5.3.1
regex==2020.2.20
six==1.14.0
tornado==6.0.4
tqdm==4.43.0
wcwidth==0.1.9

View file

@ -0,0 +1,41 @@
# Write the acquisition file (optional for test)
In order for your log to be processed by the good parser, it must match the filter that you will configure in your parser file.
There is two option:
- Your logs are wrote from a syslog server, so you just have to install the [syslog parser](https://master.d3padiiorjhf1k.amplifyapp.com/author/crowdsecurity/configurations/syslog-logs)
- You're log are read from a log file. Please add this kind of configuration in your `acquis.yaml` file:
&#9432; the `prog_name` is the one that the parser in `s01-parse` filter will need to match.
```
---
filename: <PATH_TO_YOUR_LOG_FILE>
labels:
prog_name: <PROGRAM_NAME>
```
Here an example:
<details>
<summary>Nginx acquisition</summary>
```yaml
---
filename: /var/log/nginx/access.log
labels:
prog_name: nginx
```
</details>
<details>
<summary>Nginx parser filter</summary>
```yaml
---
filter: evt.Parsed.program == 'nginx'
```
</details>

View file

@ -0,0 +1,413 @@
# Writing {{crowdsec.Name}} parser
!!! info
Please ensure that you have working env or setup test environment before writing your parser.
> In the current example, we'll write a parser for the logs produced by `iptables` (netfilter) with the `-j LOG` target.
> This document aims at detailing the process of writing and testing new parsers.
## Base parser file
The most simple parser can be defined as :
```yaml
filter: 1 == 1
debug: true
onsuccess: next_stage
name: me/myparser
description: a cool parser for my service
grok:
#our grok pattern : capture .*
pattern: ^%{DATA:some_data}$
#the field to which we apply the grok pattern : the log message itself
apply_on: message
statics:
- parsed: is_my_service
value: yes
```
- a {{filter.htmlname}} : if the expression is `true`, the event will enter the parser, otherwise, it won't
- a {{onsuccess.htmlname}} : defines what happens when the {{event.htmlname}} was successfully parsed : shall we continue ? shall we move to next stage ? etc.
- a name & a description
- some {{statics.htmlname}} that will modify the {{event.htmlname}}
- a `debug` flag that allows to enable local debugging information.
We are going to use to following sample log as an example :
```bash
May 11 16:23:43 sd-126005 kernel: [47615895.771900] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=99.99.99.99 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=51006 PROTO=TCP SPT=45225 DPT=8888 WINDOW=1024 RES=0x00 SYN URGP=0
May 11 16:23:50 sd-126005 kernel: [47615902.763137] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=44.44.44.44 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=17451 DF PROTO=TCP SPT=53668 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
```
## Let's try our mock parser
!!! warning
Your yaml file must be in the `config/parsers/s01-parser/` directory (relative to your current test directory).
For example it can be `~/crowdsec-v0.0.19/tests/config/parsers/s01-parser/myparser.yaml`
The stage directory might not exist, don't forget to create it.
Setting up our new parser :
```bash
cd crowdsec-v0.X.Y/tests
```
```bash
mkdir -p config/parsers/s01-parser
```
```bash
cp myparser.yaml config/parsers/s01-parser/
```
Testing our new parser :
```bash
./crowdsec -c ./dev.yaml -file ./x.log -type foobar
```
<details>
<summary>Expected output</summary>
```bash
INFO[0000] setting loglevel to info
INFO[11-05-2020 15:48:28] Crowdsec v0.0.18-6b1281ba76819fed4b89247a5a673c592a3a9f88
...
DEBU[0000] Event entering node id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] eval(TRUE) '1 == 1' id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] no ip in event, cidr/ip whitelists not checked id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] + Grok '' returned 1 entries to merge in Parsed id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] .Parsed['some_data'] = 'May 11 16:23:41 sd-126005 kernel: [47615893.721616] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=99.99.99.99 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=54555 PROTO=TCP SPT=45225 DPT=8080 WINDOW=1024 RES=0x00 SYN URGP=0 ' id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] + Processing 1 statics id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] .Parsed[is_my_service] = 'yes' id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] Event leaving node : ok id=dark-water name=me/myparser stage=s01-parser
DEBU[0000] move Event from stage s01-parser to s02-enrich id=dark-water name=me/myparser stage=s01-parser
...
```
</details>
We can see our "mock" parser is working, let's see what happened :
- The event enter the node
- The `filter` returned true (`1 == 1`) so the {{event.htmlname}} will be processed
- Our grok pattern (just a `.*` capture) "worked" and captured data (the whole line actually)
- The grok captures (under the name "some_data") are merged into the `.Parsed` map of the {{event.htmlname}}
- The {{statics.htmlname}} section is processed, and `.Parsed[is_my_service]` is set to `yes`
- The {{event.htmlname}} leaves the parser successfully, and because "next_stage" is set, we move the event to the next "stage"
## Writing the GROK pattern
We are going to write a parser for `iptables` logs, they look like this :
```
May 11 16:23:43 sd-126005 kernel: [47615895.771900] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=99.99.99.99 DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=245 ID=51006 PROTO=TCP SPT=45225 DPT=8888 WINDOW=1024 RES=0x00 SYN URGP=0
May 11 16:23:50 sd-126005 kernel: [47615902.763137] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=44.44.44.44 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=17451 DF PROTO=TCP SPT=53668 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
```
Using an [online grok debugger](https://grokdebug.herokuapp.com/) or an [online regex debugger](https://www.debuggex.com/), we come up with the following grok pattern :
`\[%{DATA}\]+.*(%{WORD:action})? IN=%{WORD:int_eth} OUT= MAC=%{IP}:%{MAC} SRC=%{IP:src_ip} DST=%{IP:dst_ip} LEN=%{INT:length}.*PROTO=%{WORD:proto} SPT=%{INT:src_port} DPT=%{INT:dst_port}.*`
!!! warning
Check if the pattern you are looking for is not already present in [patterns configuration](https://github.com/crowdsecurity/crowdsec/tree/master/config/patterns).
## Test our new pattern
Now, let's integrate our GROK pattern within our YAML :
```yaml
#let's set onsuccess to "next_stage" : if the log is parsed, we can consider it has been dealt with
onsuccess: next_stage
#debug, for reasons (don't do this in production)
debug: true
#as seen in our sample log, those logs are processed by the system and have a progname set to 'kernel'
filter: "1 == 1"
#name and description:
name: crowdsecurity/iptables-logs
description: "Parse iptables drop logs"
grok:
#our grok pattern
pattern: \[%{DATA}\]+.*(%{WORD:action})? IN=%{WORD:int_eth} OUT= MAC=%{IP}:%{MAC} SRC=%{IP:src_ip} DST=%{IP:dst_ip} LEN=%{INT:length}.*PROTO=%{WORD:proto} SPT=%{INT:src_port} DPT=%{INT:dst_port}.*
#the field to which we apply the grok pattern : the log message itself
apply_on: message
statics:
- parsed: is_my_service
value: yes
```
```bash
./crowdsec -c ./dev.yaml -file ./x.log -type foobar
```
<details>
<summary>Expected output</summary>
```bash
INFO[0000] setting loglevel to info
INFO[11-05-2020 16:18:58] Crowdsec v0.0.18-6b1281ba76819fed4b89247a5a673c592a3a9f88
...
DEBU[0000] Event entering node id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] eval(TRUE) '1 == 1' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] no ip in event, cidr/ip whitelists not checked id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] + Grok '' returned 8 entries to merge in Parsed id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['dst_port'] = '8080' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['action'] = '' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['int_eth'] = 'enp1s0' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['src_ip'] = '99.99.99.99' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['dst_ip'] = '127.0.0.1' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['length'] = '40' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['proto'] = 'TCP' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['src_port'] = '45225' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] + Processing 1 statics id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed[is_my_service] = 'yes' id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] Event leaving node : ok id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] move Event from stage s01-parser to s02-enrich id=lingering-breeze name=crowdsecurity/iptables-logs stage=s01-parser
...
```
</details>
What changed ? We can now see that the fragment captured by the GROK pattern are merged in the `Parsed` array !
We now have parsed data, only a few more changes and we will be done :)
## Finalizing our parser
```yaml
#let's set onsuccess to "next_stage" : if the log is parsed, we can consider it has been dealt with
onsuccess: next_stage
#debug, for reasons (don't do this in production)
debug: true
#as seen in our sample log, those logs are processed by the system and have a progname set to 'kernel'
filter: "evt.Parsed.program == 'kernel'"
#name and description:
name: crowdsecurity/iptables-logs
description: "Parse iptables drop logs"
grok:
#our grok pattern
pattern: \[%{DATA}\]+.*(%{WORD:action})? IN=%{WORD:int_eth} OUT= MAC=%{IP}:%{MAC} SRC=%{IP:src_ip} DST=%{IP:dst_ip} LEN=%{INT:length}.*PROTO=%{WORD:proto} SPT=%{INT:src_port} DPT=%{INT:dst_port}.*
#the field to which we apply the grok pattern : the log message itself
apply_on: message
statics:
- meta: log_type
value: iptables_drop
- meta: service
expression: "evt.Parsed.proto == 'TCP' ? 'tcp' : 'unknown'"
- meta: source_ip
expression: "evt.Parsed.src_ip"
```
### filter
We changed the {{filter.htmlname}} to correctly filter on the program name.
In the current example, our logs are produced by the kernel (netfilter), and thus the program is `kernel` :
```bash
tail -f /var/log/kern.log
May 11 16:23:50 sd-126005 kernel: [47615902.763137] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=44.44.44.44 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=17451 DF PROTO=TCP SPT=53668 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
```
### statics
We are setting various entries to static or dynamic values to give "context" to the log :
- `.Meta.log_type` is set to `iptables_drop` (so that we later can filter events coming from this)
- `.Meta.source_ip` is set the the source ip captured `.Parsed.src_ip`
- `.Meta.service` is set the the result of an expression that relies on the GROK output (`proto` field)
Look into dedicated {{statics.htmlname}} documentation to know more about its possibilities.
### Testing our finalized parser
```bash
./crowdsec -c ./dev.yaml -file ./x.log -type kernel
```
<details>
<summary>Expected output</summary>
```bash
...
DEBU[0000] Event entering node id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] eval(TRUE) 'evt.Parsed.program == 'kernel'' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] no ip in event, cidr/ip whitelists not checked id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] + Grok '' returned 8 entries to merge in Parsed id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['src_port'] = '45225' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['dst_port'] = '8118' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['action'] = '' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['int_eth'] = 'enp1s0' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['src_ip'] = '44.44.44.44' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['dst_ip'] = '127.0.0.1' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['length'] = '40' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Parsed['proto'] = 'TCP' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] + Processing 3 statics id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Meta[log_type] = 'iptables_drop' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Meta[service] = 'tcp' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] .Meta[source_ip] = '44.44.44.44' id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] Event leaving node : ok id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
DEBU[0000] move Event from stage s01-parser to s02-enrich id=shy-forest name=crowdsecurity/iptables-logs stage=s01-parser
...
```
</details>
## Closing word
We have now a fully functional parser for {{crowdsec.name}} !
We can either deploy it to our production systems to do stuff, or even better, contribute to the {{hub.htmlname}} !
<!--
The first field that you will write is the `onsuccess` one. This one indicate what to do in case of success log parsing. Put the value `next_stage` if you want the log to be processed by the next stages in case of parsing success:
```yaml
onsuccess: next_stage
```
Then come the `filter` part.
You will mostly want to filter on the `program` of the event:
```yaml
filter: evt.Parsed.program == '<program>'
```
The `name` (please name your parser like `<github_account_name>/<parser_name>`):
```yaml
name: crowdsecurity/example
```
A small description:
```yaml
description: this parser can process X/Y/Z logs from <program>
```
The grok part:
- If you have only one type of log then you can start with the `grok` object which is defined as below:
```yaml
grok:
pattern: <your_grok_pattern_here> # can't be used with 'name'
name: <grok_name> # grok name loaded from https://github.com/crowdsecurity/crowdsec/tree/master/config/patterns. can't be used with 'pattern'
apply_on: message
statics:
- <meta|target> : <field_name>
<value|expression> : <field_value>
- <meta|target> : <field_name>
<value|expression> : <field_value>
```
The grok pattern will be applied on the `message` field of the previous success stage.
The `pattern` and `name` keyword can't be use together
- If you have more type of logs, you will have to start with the `node` keyword that is a list of grok:
```yaml
nodes:
grok:
pattern: <your_first_grok_pattern>
apply_on: message
statics:
- <meta|target> : <field_name>
<value|expression> : <field_value>
- <meta|target> : <field_name>
<value|expression> : <field_value>
grok:
pattern: <your_second_grok_pattern>
apply_on: message
statics:
- <meta|target> : <field_name>
<value|expression> : <field_value>
- <meta|target> : <field_name>
<value|expression> : <field_value>
statics:
- <meta|target> : <field_name>
<value|expression> : <field_value>
- <meta|target> : <field_name>
<value|expression> : <field_value>
```
The `statics` is a process that will set up a value for a given key in the parsed event.
For the field `name` the keyword can be either `meta` or `target`:
- `meta` : the new field will be created in the evt.Meta object to be accessible like : `evt.Meta.<new_field>`;
```yaml
meta: log_type
```
- `target`: the name of the new field:
```yaml
target: evt.source_ip
```
For the field value, it can be either `value` or `expression`:
- `value` is the value assigned, for example : `http_access_log`
```yaml
value: http_access_log
```
- `expression` the result of a parsed field, for example : `evt.Parsed.remote_addr`
```yaml
expression : evt.Parsed.remote_addr
```
The `statics` can be applied only for the grok it succeed, if it is in the `grok` object, else for whatever grok if at the root level.
Full example with NGINX:
<details>
<summary>Nginx </summary>
```yaml
filter: "evt.Parsed.program == 'nginx'"
onsuccess: next_stage
#debug: true
name: crowdsecurity/nginx-logs
description: "Parse nginx access and error logs"
nodes:
- grok:
name: NGINXACCESS
apply_on: message
statics:
- meta: log_type
value: http_access-log
- target: evt.StrTime
expression: evt.Parsed.time_local
- grok:
# and this one the error log
name: NGINXERROR
apply_on: message
statics:
- meta: log_type
value: http_error-log
- target: evt.StrTime
expression: evt.Parsed.time
# these ones apply for both grok patterns
statics:
- meta: service
value: http
- meta: source_ip
expression: "evt.Parsed.remote_addr"
- meta: http_status
expression: "evt.Parsed.status"
- meta: http_path
expression: "evt.Parsed.request"
```
</details> -->

View file

@ -0,0 +1,91 @@
# Requirements
>Some requirements are needed in order to be able to write your own end-to-end configurations.
>During all this documentation, we are going to show as an exemple how we wrote a full port scan detection scenario (from acqusition to scenario, including parser)
## Create the test environment
First of all, please [download the latest release of {{crowdsec.name}}](https://github.com/crowdsecurity/crowdsec/releases).
Then run the following commands:
```bash
tar xzvf crowdsec-release.tgz
```
```bash
cd ./crowdsec-vX.Y/
```
```bash
./test_env.sh # the -o is facultative, default is "./tests/"
```
```bash
cd ./tests/
```
The `./test_env.sh` script creates a local (non privileged) working environement for {{crowdsec.name}} and {{cli.name}}.
The deployed environment is intended to write and test parsers and scenarios easily.
<details>
<summary>Example</summary>
```bash
$ tar xzvf ./crowdsec-release.tgz
$ cd ./crowdsec-v0.0.18/
$ ./test_env.sh
[09/05/2020:20:02:19][INFO] Creating test arboresence in /tmp/crowdsec-v0.0.18/tests
[09/05/2020:20:02:19][INFO] Arboresence created
[09/05/2020:20:02:19][INFO] Copying needed files for tests environment
[09/05/2020:20:02:19][INFO] Files copied
[09/05/2020:20:02:19][INFO] Setting up configurations
INFO[0000] Failed to open config /tmp/crowdsec-v0.0.18/tests/config/crowdsec-cli/config : open /tmp/crowdsec-v0.0.18/tests/config/crowdsec-cli/config: no such file or directory
WARN[0000] creating skeleton!
INFO[0000] wrote config to /tmp/crowdsec-v0.0.18/tests/config/crowdsec-cli/config
INFO[0000] wrote config to /tmp/crowdsec-v0.0.18/tests/config/crowdsec-cli/config
INFO[0000] Wrote new 45625 bytes index to /tmp/crowdsec-v0.0.18/tests/config/crowdsec-cli/.index.json
INFO[0000] crowdsecurity/syslog-logs : OK
INFO[0000] crowdsecurity/geoip-enrich : OK
INFO[0000] crowdsecurity/dateparse-enrich : OK
INFO[0001] crowdsecurity/linux : OK
INFO[0001] /tmp/crowdsec-v0.0.18/tests/config/collections doesn\'t exist, create
INFO[0001] /tmp/crowdsec-v0.0.18/tests/config/parsers/s00-raw doesn\'t exist, create
INFO[0001] Enabled parsers : crowdsecurity/syslog-logs
INFO[0001] /tmp/crowdsec-v0.0.18/tests/config/parsers/s02-enrich doesn\'t exist, create
INFO[0001] Enabled parsers : crowdsecurity/geoip-enrich
INFO[0001] Enabled parsers : crowdsecurity/dateparse-enrich
INFO[0001] Enabled collections : crowdsecurity/linux
INFO[0001] Enabled crowdsecurity/linux
[09/05/2020:20:02:20][INFO] Environment is ready in /tmp/crowdsec-v0.0.18/tests
```
</details>
## &#9432; Reminder
Logs parsing is divided into stage. Each stage are called in the format "sXX-<stage_name>". If a log success in a stage and is configured to go in `next_stage`, then the next stage will process it. Stage process is sorted alphabetically.
Stages and parsers are being processed alphabetically, thus the expected order would be :
```
s00-raw/syslog.yaml
s01-parse/nginx.yaml
s01-parse/apache.yaml
s02-enrich/geoip.yaml
s02-enrich/rdns.yaml
```
### Basics stage
- The first stage (`s00-parse`) is mostly the one that will parsed the begining of your log to say : "This log come from this `source`" where the source can be whatever software that produce logs.
If all your logs are sent to a syslog server, there is a [parser](https://master.d3padiiorjhf1k.amplifyapp.com/author/crowdsecurity/configurations/syslog-logs) that will parse the syslog header to detect the program source.
When the log is processed, the results (ie. capture groups) will be merged in the current {{event.htmlname}} before being sent to the next stage.
- The second (`s01-parse`) is the one that will parse the logs and output parsed data and static assigned values. There is currently one parser for one type of software. To parse the logs, regexp or GROK pattern are used. If the parser is configured to go to the [`next_stage`](/references/parsers/#onsuccess), then it will be process by the `enrichment` stage.
- The enrichment `s02-enrich` stage is the one that will enrich the normalized log (we call it an event now that it is normalized) in order to get more information for the heuristic process. This stage can be composed of grok patterns and so on, but as well of plugins that can be writen by the community (geiop enrichment, rdns ...)
### Custom stage
Of course, it is possible to write custom stages. If you want some specific parsing or enrichment to be done after the `s02-enrich` stage, it is possible by creating a new folder `s03-<custom_stage>`. The configuration that will be created in this folder will process the logs configurated to go to `next_stage` in the `s02-enrich` stage. Be careful to write filter that will match incoming event in your custom stage.

View file

@ -0,0 +1,444 @@
# Writing {{crowdsec.Name}} scenarios
!!! info
Please ensure that you have working env or setup test environment before writing your scenario.
Ensure that your logs are properly parsed.
Have some sample logs at hand reach to test your scenario as you progress.
> In the current example, we'll write a scenario to detect port scans relying on the logs produced by `iptables` (netfilter) with the `-j LOG` target.
> This document aims at detailing the process of writing and testing new scenarios.
## Base scenario file
The simple scenario can be defined as :
```yaml
type: leaky
debug: true
name: me/my-cool-scenario
description: "detect cool stuff"
filter: "1 == 1"
capacity: 1
leakspeed: 1m
blackhole: 1m
labels:
type: my_test
```
- a {{filter.htmlname}} : if the expression is `true`, the event will enter the parser, otherwise, it won't
- a name & a description
- a capacity for our [Leaky Bucket](https://en.wikipedia.org/wiki/Leaky_bucket)
- a leak speed for our [Leaky Bucket](https://en.wikipedia.org/wiki/Leaky_bucket)
- a blackhole duration (it will prevent the same bucket from overflowing too often to limit spam)
- some labels to qualify the events that just happen
- a `debug` flag that allows to enable local debugging information.
We are going to use the following sample log in our example :
```bash
May 12 09:40:15 sd-126005 kernel: [47678084.929208] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=66.66.66.66 DST=127.0.0.1 LEN=40 TOS=0x08 PREC=0x20 TTL=244 ID=54321 PROTO=TCP SPT=42403 DPT=7681 WINDOW=65535 RES=0x00 SYN URGP=0
May 12 09:40:15 sd-126005 kernel: [47678084.929245] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=99.99.99.99 DST=127.0.0.1 LEN=40 TOS=0x08 PREC=0x20 TTL=244 ID=54321 PROTO=TCP SPT=42403 DPT=7681 WINDOW=65535 RES=0x00 SYN URGP=0
May 12 09:40:16 sd-126005 kernel: [47678084.929208] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=99.99.99.99 DST=127.0.0.1 LEN=40 TOS=0x08 PREC=0x20 TTL=244 ID=54321 PROTO=TCP SPT=42403 DPT=7681 WINDOW=65535 RES=0x00 SYN URGP=0
May 12 09:40:16 sd-126005 kernel: [47678084.929208] IN=enp1s0 OUT= MAC=00:08:a2:0c:1f:12:00:c8:8b:e2:d6:87:08:00 SRC=44.44.44.44 DST=127.0.0.1 LEN=40 TOS=0x08 PREC=0x20 TTL=244 ID=54321 PROTO=TCP SPT=42403 DPT=7681 WINDOW=65535 RES=0x00 SYN URGP=0
```
## Let's try our mock scenario
!!! info
This assumes that you've followed the previous tutorial and that your iptables logs are properly parsed
```bash
./crowdsec -c ./dev.yaml -file ./x.log -type syslog
```
<details>
<summary>Expected output</summary>
```bash
...
DEBU[2020-05-12T11:22:17+02:00] eval(TRUE) 1 == 1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:22:17+02:00] Instanciating TimeMachine bucket cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:22:17+02:00] Leaky routine starting, lifetime : 2m0s bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] Pouring event bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] First pour, creation timestamp : 2020-05-12 09:40:15 +0000 UTC bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] eval(TRUE) 1 == 1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:22:17+02:00] Pouring event bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] Bucket overflow at 2020-05-12 09:40:15 +0000 UTC bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] Overflow, bucket start: 2020-05-12 09:40:15 +0000 UTC, bucket end : 2020-05-12 09:40:15 +0000 UTC bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] Adding blackhole (until: 2020-05-12 09:41:15 +0000 UTC) bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] Leaky routine exit bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
DEBU[2020-05-12T11:22:17+02:00] eval(TRUE) 1 == 1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario
INFO[12-05-2020 11:22:17] node warning : no remediation bucket_id=withered-brook event_time="2020-05-12 09:40:15 +0000 UTC" scenario=me/my-cool-scenario source_ip=66.66.66.66
DEBU[2020-05-12T11:22:17+02:00] Bucket f16d5033bebe7090fb626f5feb4e4073cee206d4 dead/expired, cleanup bucket_id=withered-brook capacity=1 cfg=snowy-dawn file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=f16d5033bebe7090fb626f5feb4e4073cee206d4
INFO[12-05-2020 11:22:17] Processing Overflow with no decisions 2 IPs performed 'me/my-cool-scenario' (2 events over 0s) at 2020-05-12 09:40:15 +0000 UTC bucket_id=withered-brook event_time="2020-05-12 09:40:15 +0000 UTC" scenario=me/my-cool-scenario source_ip=66.66.66.66
...
```
</details>
We can see our "mock" scenario is working, let's see what happened :
- The first event (parsed line) is processed :
- The `filter` returned true (`1 == 1`) so the {{event.htmlname}} will be processed by our bucket
- The bucket is instantiated in {{timeMachine.htmlname}} mode, and its creation date is set to the timestamp from the first log
- The {{event.htmlname}} is poured in the actual bucket
- The second event is processed
- The `filter` is still true, and the event is poured
- As our bucket's capacity is `1`, pouring this second overflow leads to an {{overflow.htmlname}}
- Because we set a blackhole directive of `1 minute`, we remember to prevent this bucket to overflowing again for the next minute
The overflow itself is produced and we get this message :
```
INFO[12-05-2020 11:22:17] Processing Overflow with no decisions 2 IPs performed 'me/my-cool-scenario' (2 events over 0s) at 2020-05-12 09:40:15 +0000 UTC bucket_id=withered-brook event_time="2020-05-12 09:40:15 +0000 UTC" scenario=me/my-cool-scenario source_ip=66.66.66.66
```
!!! warning
While it "worked" we can see the first issue : the offending IP is reported to be `66.66.66.66` but there are actually 3 IPs involved (`66.66.66.66`, `99.99.99.99` and `44.44.44.44`). To make sense our "detect port scans" should detect events coming from a single IP !
## One step forward : peer attribution
Let's evolve our scenario to be closer to something meaningful :
```yaml
type: leaky
debug: true
name: me/my-cool-scenario
description: "detect cool stuff"
filter: "evt.Meta.log_type == 'iptables_drop' && evt.Meta.service == 'tcp'"
groupby: evt.Meta.source_ip
capacity: 1
leakspeed: 1m
blackhole: 1m
labels:
type: my_test
```
What did we change ?
- we added a meaningful filter : we are only going to look into `iptables_drop` events, and only take care of `tcp` ones (see the parser we wrote in the [previous step](/write_configurations/parsers/))
- we added a `groupby` directive : it's going to ensure that each offending peer get its own bucket
Let's try again !
```bash
./crowdsec -c ./dev.yaml -file ./x.log -type syslog
```
<details>
<summary>Expected output</summary>
```bash
...
DEBU[2020-05-12T11:25:20+02:00] eval(TRUE) evt.Meta.log_type == 'iptables_drop' && evt.Meta.service == 'tcp' cfg=holy-breeze file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:25:20+02:00] Leaky routine starting, lifetime : 2m0s bucket_id=cold-lake capacity=1 cfg=holy-breeze file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=2308799e2cc5b57331df10eb93a495aff7725922
...
DEBU[2020-05-12T11:25:20+02:00] eval(TRUE) evt.Meta.log_type == 'iptables_drop' && evt.Meta.service == 'tcp' cfg=holy-breeze file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:25:20+02:00] Instanciating TimeMachine bucket cfg=holy-breeze file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:25:20+02:00] Leaky routine starting, lifetime : 2m0s bucket_id=muddy-haze capacity=1 cfg=holy-breeze file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=6236f134d0f34d0061748c065bdcb64d8ac6dc54
...
INFO[12-05-2020 11:25:20] node warning : no remediation bucket_id=muddy-haze event_time="2020-05-12 09:40:16 +0000 UTC" scenario=me/my-cool-scenario source_ip=99.99.99.99
INFO[12-05-2020 11:25:20] Processing Overflow with no decisions 99.99.99.99 performed 'me/my-cool-scenario' (2 events over 1s) at 2020-05-12 09:40:16 +0000 UTC bucket_id=muddy-haze event_time="2020-05-12 09:40:16 +0000 UTC" scenario=me/my-cool-scenario source_ip=99.99.99.99
...
```
</details>
Let's see what happened :
- Thanks to our `groupby` key, we now see two different partition keys appearing (`partition=...`).
It means that each peer will get its own bucket, and a "unique key" is derived from the groupby field value (here : the source IP)
- We see that we only have one overflow, and it correctly concerns `99.99.99.99` (it's the one that actually triggered two events). This is again thanks to the groupby key
## One step forward : unique ports
Is it done ? not yet, but we're getting close !
To really qualify a port-scan, we want to rely on the number of unique probed ports. Let's arbitrarily decide that a port-scan is : "One peer trying to probe AT LEAST 15 different ports within a few seconds"
Our evolved scenario is now :
```yaml
type: leaky
debug: true
name: me/my-cool-scenario
description: "detect cool stuff"
filter: "evt.Meta.log_type == 'iptables_drop' && evt.Meta.service == 'tcp'"
groupby: evt.Meta.source_ip
distinct: evt.Parsed.dst_port
capacity: 15
leakspeed: 5s
blackhole: 1m
labels:
type: scan
service: tcp
```
What did we changed :
- We add a `distinct` directive on the `evt.Parsed.dst_port`. It allows the bucket to discard any event with an already seen `evt.Parsed.dst_port`. (yes, like in SQL)
- We changed `capacity` and `leakspeed` to be more relevant to our target
- We fixed the `labels` so that the event makes sense !
Let's see what it changes :
```bash
./crowdsec -c ./dev.yaml -file ./x.log -type syslog
```
<details>
<summary>Expected output</summary>
```bash
...
DEBU[2020-05-12T11:49:01+02:00] eval(TRUE) evt.Meta.log_type == 'iptables_drop' && evt.Meta.service == 'tcp' cfg=dark-pond file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:49:01+02:00] Instantiating TimeMachine bucket cfg=dark-pond file=config/scenarios/mytest.yaml name=me/my-cool-scenario
DEBU[2020-05-12T11:49:01+02:00] Leaky routine starting, lifetime : 1m20s bucket_id=nameless-feather capacity=15 cfg=dark-pond file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=2308799e2cc5b57331df10eb93a495aff7725922
DEBU[2020-05-12T11:49:01+02:00] Uniq 'evt.Parsed.dst_port' -> '7681' bucket_id=nameless-feather capacity=15 cfg=dark-pond file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=2308799e2cc5b57331df10eb93a495aff7725922
DEBU[2020-05-12T11:49:01+02:00] Uniq(7681) : false, discard bucket_id=nameless-feather capacity=15 cfg=dark-pond file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=2308799e2cc5b57331df10eb93a495aff7725922
DEBU[2020-05-12T11:49:01+02:00] Pouring event bucket_id=nameless-feather capacity=15 cfg=dark-pond file=config/scenarios/mytest.yaml name=me/my-cool-scenario partition=2308799e2cc5b57331df10eb93a495aff7725922
...
```
</details>
- We can see that the second event was discarded, because it had a destination port similar to the first one
- No overflow were produced
## Is it really working
Ok, **fingers crossed** our thing should be working.
Let's grab some real-life logs !
```bash
$ wc -l kern.log
78215 kern.log
$ head -n1 kern.log
May 11 06:25:20 sd-126005 kernel: ...
$ tail -n1 kern.log
May 12 12:09:00 sd-126005 kernel: ...
```
We have around 80k lines averaging about 24h of logs, let's try !
```bash
./crowdsec -c ./dev.yaml -file ./kern.log -type syslog
```
<details>
<summary>Expected output</summary>
```bash
INFO[0000] setting loglevel to info
INFO[12-05-2020 11:50:38] Crowdsec v0.0.18-f672dbb4aec29ca2b24080a33d4d92eb9d4441cc
...
INFO[12-05-2020 11:50:42] node warning : no remediation bucket_id=sparkling-violet event_time="2020-05-11 10:41:45 +0000 UTC" scenario=me/my-cool-scenario source_ip=xx.xx.xx.xx
INFO[12-05-2020 11:50:42] Processing Overflow with no decisions xx.xx.xx.xx performed 'me/my-cool-scenario' (16 events over 0s) at 2020-05-11 10:41:45 +0000 UTC bucket_id=sparkling-violet event_time="2020-05-11 10:41:45 +0000 UTC" scenario=me/my-cool-scenario source_ip=xx.xx.xx.xx
...
INFO[12-05-2020 11:50:43] node warning : no remediation bucket_id=quiet-leaf event_time="2020-05-11 11:34:11 +0000 UTC" scenario=me/my-cool-scenario source_ip=yy.yy.yy.yy
INFO[12-05-2020 11:50:43] Processing Overflow with no decisions yy.yy.yy.yy performed 'me/my-cool-scenario' (16 events over 2s) at 2020-05-11 11:34:11 +0000 UTC bucket_id=quiet-leaf event_time="2020-05-11 11:34:11 +0000 UTC" scenario=me/my-cool-scenario source_ip=yy.yy.yy.yy
...
WARN[12-05-2020 11:51:05] read 78215 lines file=./kern.log
...
```
It seems to work correctly !
## Hold my beer and watch this
One I have acquire confidence in my scenario and I want it to trigger some bans, we can simply add :
```yaml
type: leaky
debug: true
name: me/my-cool-scenario
description: "detect cool stuff"
filter: "evt.Meta.log_type == 'iptables_drop' && evt.Meta.service == 'tcp'"
groupby: evt.Meta.source_ip
distinct: evt.Parsed.dst_port
capacity: 15
leakspeed: 5s
blackhole: 1m
labels:
type: scan
service: tcp
remediation: true
scope: ip
```
Adding `remediation: true` into the labels tells {{crowdsec.name}} that we should write a ban for the IP when the scenario is triggered !
Let's try :
- I copied the yaml file to a production system (`/etc/crowdsec/crowdsec/scenarios/mytest.yaml`)
- I restart {{crowdsec.name}} (`systemctl restart crowdsec`)
Let's check if it seems correctly enabled :
```bash
$ {{cli.bin}} list
...
INFO[0000] SCENARIOS:
----------------------------------------------------------------------------------------------------------------------------------
NAME 📦 STATUS VERSION LOCAL PATH
----------------------------------------------------------------------------------------------------------------------------------
...
mytest.yaml 🚫 enabled,local /etc/crowdsec/config/scenarios/mytest.yaml
...
```
Let's launch (from an external machine, as {{crowdsec.name}} ignores events from private IPs by default) a real port-scan with a good old `nmap` :
```bash
sudo nmap -sS xx.xx.xx.xx
```
and on our server :
```bash
$ tail -f /var/log/crowdsec.log
...
time="12-05-2020 12:31:43" level=warning msg="xx.xx.16.6 triggered a 4h0m0s ip ban remediation for [me/my-cool-scenario]" bucket_id=wispy-breeze event_time="2020-05-12 12:31:43.953498645 +0200 CEST m=+64.533521568" scenario=me/my-cool-scenario source_ip=xx.xx.16.6
...
^C
$ {{cli.bin}} ban list
INFO[0000] backend plugin 'sqlite' loaded
8 local decisions:
+--------+-----------------+----------------------+------+--------+---------+--------------------------+--------+------------+
| SOURCE | IP | REASON | BANS | ACTION | COUNTRY | AS | EVENTS | EXPIRATION |
+--------+-----------------+----------------------+------+--------+---------+--------------------------+--------+------------+
| local | xx.xx.xx.xx | me/my-cool-scenario | 4 | ban | FR | 21502 SFR SA | 79 | 3h58m27s |
...
```
It worked !!!
<!--
# Writing Crowdsec scenario
> Please refer to []() if the parser doesn't exist
## Acquiring the logs
First step to test a scenario is to get the logs that trigger your wanted scenario.
## Write the yaml configuration file
The first configuration for a scenario is the [type]().
It can uniq, trigger or leaky. Please [see here]() for more description about scenarios type.
```yaml
type: leaky
```
Then the `name`. Please write it in the form of `<github_account_name>/<scenario_name>` .
```yaml
name: crowdsecurity/http-scan-uniques_404
```
Describe in one sentence what this scenario trigger :
```yaml
description: Detect multiple unique 404 from a single ip
```
Now come the filter, the one that will decide if the incoming log will be store in our bucket.
For the HTTP 404 scans, we want only logs from web request that return a `404`, `403` or `400` HTTP code:
```yaml
filter: "evt.Meta.service == 'http' && evt.Meta.http_status in ['404', '403', '400']"
```
Then we want to groupby this scenario for `source_ip` (ip of the attacker) :
```yaml
groupby: evt.Meta.source_ip
```
And we want only one log to be store for each HTTP URI query by the attacker (no duplicate):
```yaml
distinct: evt.Meta.http_path
```
We can say that if someone query 5 or more unknown or forbidden HTTP URI with a leakspeed of 10s, then it is probably a web scan:
```yaml
capacity: 5
leakspeed: "10s"
```
Then we want to blackhole it for 5minutes (because if the attacker crawl a lot, we don't want to be notofied for every 5 times HTTP 404/403/400):
```yaml
blackhole: 5m
```
We also want to reprocess this scenarios if it happen for more heuristic:
```yaml
reprocess: true
```
And then we give some labels to this scenario for remediation:
```yaml
service: http
type: scan
remediation: true
```
Full example scenario:
<details>
<summary>Nginx </summary>
```yaml
# 404 scan
type: leaky
#debug: true
name: crowdsecurity/http-scan-uniques_404
description: "Detect multiple unique 404 from a single ip"
filter: "evt.Meta.service == 'http' && evt.Meta.http_status in ['404', '403', '400']"
groupby: "evt.Meta.source_ip"
distinct: "evt.Meta.http_path"
capacity: 5
#debug: true
reprocess: true
leakspeed: "10s"
blackhole: 5m
labels:
service: http
type: scan
remediation: true
```
</details> -->

View file

@ -0,0 +1,122 @@
## Where are whitelists
Whitelists are, as for most configuration, YAML files, and allow you to "discard" signals based on :
- ip adress or the fact that it belongs to a specific range
- a {{expr.name}} expression
Here is an example :
```yaml
name: crowdsecurity/my-whitelists
description: "Whitelist events from my ipv4 addresses"
whitelist:
reason: "my ipv4 ranges"
ip:
- "127.0.0.1"
cidr:
- "192.168.0.0/16"
- "10.0.0.0/8"
- "172.16.0.0/12"
expression:
- "'mycorp.com' in evt.Meta.source_ip_rdns"
```
## Hands on
Let's assume we have a setup with a `crowdsecurity/base-http-scenarios` scenario enabled and no whitelists.
Thus, if I "attack" myself :
```bash
nikto -host 127.0.0.1
```
my own IP will be flagged as being an attacker :
```bash
$ tail -f /var/log/crowdsec.log
time="07-05-2020 09:23:03" level=warning msg="127.0.0.1 triggered a 4h0m0s ip ban remediation for [crowdsecurity/http-scan-uniques_404]" bucket_id=old-surf event_time="2020-05-07 09:23:03.322277347 +0200 CEST m=+57172.732939890" scenario=crowdsecurity/http-scan-uniques_404 source_ip=127.0.0.1
time="07-05-2020 09:23:03" level=warning msg="127.0.0.1 triggered a 4h0m0s ip ban remediation for [crowdsecurity/http-crawl-non_statics]" bucket_id=lingering-sun event_time="2020-05-07 09:23:03.345341864 +0200 CEST m=+57172.756004380" scenario=crowdsecurity/http-crawl-non_statics source_ip=127.0.0.1
^C
$ {{cli.bin}} ban list
1 local decisions:
+--------+-----------+-------------------------------------+------+--------+---------+----+--------+------------+
| SOURCE | IP | REASON | BANS | ACTION | COUNTRY | AS | EVENTS | EXPIRATION |
+--------+-----------+-------------------------------------+------+--------+---------+----+--------+------------+
| local | 127.0.0.1 | crowdsecurity/http-scan-uniques_404 | 2 | ban | | 0 | 47 | 3h55m57s |
+--------+-----------+-------------------------------------+------+--------+---------+----+--------+------------+
```
## Create the whitelist by IP
Let's create a `/etc/crowdsec/crowdsec/parsers/s02-enrich/whitelists.yaml` file with the following content :
```yaml
name: crowdsecurity/whitelists
description: "Whitelist events from private ipv4 addresses"
whitelist:
reason: "private ipv4 ranges"
ip:
- "127.0.0.1"
```
and restart {{crowdsec.name}} : `sudo systemctl restart {{crowdsec.name}}`
## Test the whitelist
Thus, if we restart our attack :
```bash
nikto -host 127.0.0.1
```
And we don't get bans, instead :
```bash
$ tail -f /var/log/crowdsec.log
...
time="07-05-2020 09:30:13" level=info msg="Event from [127.0.0.1] is whitelisted by Ips !" filter= name=lively-firefly stage=s02-enrich
...
^C
$ {{cli.bin}} ban list
No local decisions.
And 21 records from API, 15 distinct AS, 12 distinct countries
```
## Create whitelist by expression
Now, let's make something more tricky : let's whitelist a **specific** user-agent (of course, it's just an example, don't do this at home !).
Let's change our whitelist to :
```yaml
name: crowdsecurity/whitelists
description: "Whitelist events from private ipv4 addresses"
whitelist:
reason: "private ipv4 ranges"
expression:
- evt.Parsed.http_user_agent == 'MySecretUserAgent'
```
again, let's restart {{crowdsec.name}} !
For the record, I edited nikto's configuration to use 'MySecretUserAgent' as user-agent, and thus :
```bash
nikto -host 127.0.0.1
```
```bash
$ tail -f /var/log/crowdsec.log
...
time="07-05-2020 09:39:09" level=info msg="Event is whitelisted by Expr !" filter= name=solitary-leaf stage=s02-enrich
...
```

236
mkdocs.yml Normal file
View file

@ -0,0 +1,236 @@
site_name: Crowdsec
nav:
- Home: index.md
- Getting Started:
- Concepts : getting_started/concepts.md
- Installation : getting_started/installation.md
- Crowdsec Tour: getting_started/crowdsec-tour.md
- Glossary : getting_started/glossary.md
- FAQ: getting_started/FAQ.md
- Guide:
- Overview: guide/crowdsec/overview.md
- Acquisition: guide/crowdsec/acquisition.md
- Parsers: guide/crowdsec/parsers.md
- Enrichers: guide/crowdsec/enrichers.md
- Scenarios: guide/crowdsec/scenarios.md
- Cscli: guide/cscli.md
- Cheat Sheets:
- Ban Management: cheat_sheets/ban-mgmt.md
- Configuration Management: cheat_sheets/config-mgmt.md
- Observability:
- Overview: observability/overview.md
- Logs: observability/logs.md
- Metrics: observability/metrics.md
- Dashboard: observability/dashboard.md
- References:
- Parsers format: references/parsers.md
- Scenarios format: references/scenarios.md
- Outputs format: references/output.md
- Write Configurations:
- Requirements: write_configurations/requirements.md
- Acquisition: write_configurations/acquisition.md
- Parsers: write_configurations/parsers.md
- Scenarios: write_configurations/scenarios.md
- Whitelist: write_configurations/whitelist.md
- Blockers:
- Overview : blockers/index.md
- Nginx:
- Installation : blockers/nginx/installation.md
- Configuration : blockers/nginx/configuration.md
- Wordpress:
- Installation : blockers/wordpress/installation.md
- Configuration : blockers/wordpress/configuration.md
- Netfilter:
- Installation : blockers/netfilter/installation.md
- Configuration : blockers/netfilter/configuration.md
- Contributing: contributing/
- Cscli commands:
- API: cscli/cscli_api.md
- Backup: cscli/cscli_backup.md
- Bans: cscli/cscli_ban.md
- Metrics: cscli/cscli_metrics.md
- Update: cscli/cscli_update.md
- Install configurations: cscli/cscli_install.md
- Remove configurations: cscli/cscli_remove.md
- Upgrade configurations: cscli/cscli_upgrade.md
- List configurations: cscli/cscli_list.md
- Inspect configurations: cscli/cscli_inspect.md
- Dashboard: cscli/cscli_dashboard.md
- About: about.md
markdown_extensions:
- codehilite:
guess_lang: false
- toc:
permalink: true
- admonition
theme:
name: material
logo: assets/images/crowdsec2.png
favicon: assets/images/crowdsec2.png
palette:
primary: "#3d85c6"
language: en
font:
text: Montserrat
highlightjs: true
hljs_languages:
- yaml
repo_url: https://github.com/crowdsecurity/crowdsec
repo_name: GitHub
plugins:
- search
- macros
extra:
doc:
new_issue: "[new documentation issue](https://github.com/crowdsecurity/crowdsec/issues/new)"
discourse: "[CrowdSecurity discourse](http://discourse.crowdsec.net)"
community: "[community](http://discourse.crowdsec.net)"
hub:
name: Crowdsec Hub
htmlname: "[Crowdsec Hub](https://master.d3padiiorjhf1k.amplifyapp.com/)"
url: "https://master.d3padiiorjhf1k.amplifyapp.com/"
plugins_url: "https://master.d3padiiorjhf1k.amplifyapp.com/browse/#blockers"
scenarios_url: "https://master.d3padiiorjhf1k.amplifyapp.com/browse/#configurations"
parsers_url: "https://master.d3padiiorjhf1k.amplifyapp.com/browse/#configurations"
collections_url: "https://master.d3padiiorjhf1k.amplifyapp.com/browse/#collections"
crowdsec:
name: Crowdsec
Name: Crowdsec
bin: crowdsec-agent
path: /usr/bin/crowdsec-agent
url: https://github.com/crowdsecurity/crowdsec
bugreport: "https://github.com/crowdsecurity/crowdsec/issues"
main_log: "/var/log/crowdsec.log"
download_url: https://github.com/crowdsecurity/crowdsec/releases/latest
cli:
name: cscli
Name: Cscli
bin: cscli
path: /usr/bin/cscli
main_doc: /cscli/cscli/
url: "https://github.com/crowdsecurity/crowdsec"
bugreport: "https://github.com/crowdsecurity/crowdsec/issues"
api_doc: /cscli/cscli_api/
ban_doc: /cscli/cscli_ban/
metrics_doc: /cscli/cscli_metrics/
remove_doc: /cscli/cscli_remove/
install_doc: /cscli/cscli_install/
list_doc: /cscli/cscli_list/
update_doc: /cscli/cscli_update/
upgrade_doc: /cscli/cscli_upgrade/
backup_doc: /cscli/cscli_backup/
config:
cli_dir: /etc/crowdsec/cscli/
crowdsec_dir: "/etc/crowdsec/config/"
acquis_path: "/etc/crowdsec/config/acquis.yaml"
plugins:
name: blockers
url: "https://master.d3padiiorjhf1k.amplifyapp.com/"
binpath: "/var/lib/crowdsec/plugins/"
configpath: "/etc/crowdsec/plugins/"
metabase:
name: metabase
url: https://github.com/crowdsecurity/crowdsec
wizard:
name: wizard
url: "https://github.com/crowdsecurity/crowdsec"
bin: "./wizard.sh"
bugreport: "https://github.com/crowdsecurity/crowdsec/issues"
ref:
parser: "[parser](/references/parsers/)"
Parser: "[Parser](/references/parsers/)"
scenario: "[scenarios](/references/scenarios/)"
Scenario: "[Scenarios](/references/scenarios/)"
acquis: "[acquisition](/references/acquis/)"
Acquis: "[Acquisition](/references/acquis/)"
output: "[output](/references/output/)"
Output: "[Output](/references/output/)"
# All the technical terms
event:
name: event
Name: Event
htmlname: "[event](/getting_started/glossary/#event)"
Htmlname: "[Event](/getting_started/glossary/#event)"
expr:
name: expr
Name: Expr
htmlname: "[expr](https://github.com/antonmedv/expr)"
Htmlname: "[Expr](https://github.com/antonmedv/expr)"
stages:
name: stages
name: Stages
htmlname: "[stages](/getting_started/glossary/#stages)"
Htmlname: "[Stages](/getting_started/glossary/#stages)"
filter:
name: filter
Name: Filter
htmlname: "[filter](/references/parsers/#filter)"
Htmlname: "[Filter](/references/parsers/#filter)"
onsuccess:
name: onsuccess
Name: Onsuccess
htmlname: "[onsuccess](/references/parsers/#onsuccess)"
Htmlname: "[Onsuccess](/references/parsers/#onsuccess)"
statics:
name: statics
Name: Statics
htmlname: "[statics](/references/parsers/#statics)"
Htmlname: "[Statics](/references/parsers/#statics)"
parsers:
name: parsers
Name: Parsers
htmlname: "[parsers](/getting_started/glossary/#parser)"
Htmlname: "[Parsers](/getting_started/glossary/#parser)"
scenarios:
name: scenarios
Name: Scenarios
htmlname: "[scenarios](/getting_started/glossary/#scenario)"
Htmlname: "[Scenarios](/getting_started/glossary/#scenario)"
collections:
name: collections
Name: Collections
htmlname: "[collections](/getting_started/glossary/#collection)"
Htmlname: "[Collections](/getting_started/glossary/#collection)"
timeMachine:
name: timeMachine
Name: TimeMachine
htmlname: "[timeMachine](/getting_started/glossary/#timemachine)"
Htmlname: "[TimeMachine](/getting_started/glossary/#timemachine)"
overflow:
name: overflow
Name: Overflow
htmlname: "[overflow](/getting_started/glossary/#overflow-or-signaloccurence)"
Htmlname: "[Overflow](/getting_started/glossary/#overflow-or-signaloccurence)"
signal:
name: signal
Name: Signal
htmlname: "[signal](/getting_started/glossary/#overflow-or-signaloccurence)"
Htmlname: "[Signal](/getting_started/glossary/#overflow-or-signaloccurence)"
blockers:
name: blockers
Name: Blockers
htmlname: "[blockers](/blockers/)"
Htmlname: "[blockers](/blockers/)"
#scenario stuff
leakspeed:
name: leakspeed
Name: Leakspeed
htmlname: "[leakspeed](/references/scenarios/#leakspeed)"
Htmlname: "[Leakspeed](/references/scenarios/#leakspeed)"
capacity:
name: capacity
Name: Capacity
htmlname: "[capacity](/references/scenarios/#capacity)"
Htmlname: "[Capacity](/references/scenarios/#capacity)"
duration:
name: duration
Name: Duration
htmlname: "[duration](/references/scenarios/#duration)"
Htmlname: "[Duration](/references/scenarios/#duration)"
api:
name: API
htmlname: "[API](TBD)"
topX:
name: topX
htmlname: "[topX](TBD)"