beenull/crowdsec
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

doc update (#491)

Browse source 
* fix doc indent

* up bouncer doc & arm doc
This commit is contained in:
Thibault "bui" Koechlin 2020-12-01 11:28:29 +01:00 committed by GitHub
parent c6eb2afa20
commit 0be78d4cbf
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 18 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
docs/faq.md
View file

@ -96,6 +96,7 @@ not exactly the same target as the debian named armhf port.
The best way to have a crowdsec version for such an architecture is to
do:
1. install golang (all versions from 1.13 will do)
2. `export GOARCH=arm`
3. `export CGO=1`

6
docs/v1.X/docs/bouncers/index.md
View file

@ -1,11 +1,13 @@
# Bouncers
{{v1X.bouncers.Name}} are standalone software pieces in charge of acting upon blocked IPs.
{{v1X.bouncers.Name}} are standalone software pieces in charge of acting upon a decision taken by crowdsec : block an IP, present a captcha, enforce MFA on a given user, etc.
They can either be within the applicative stack, or work out of band :
[nginx bouncer](https://github.com/crowdsecurity/cs-nginx-bouncer) will check every unknown IP against the database before letting go through or serving a *403* to the user, while a [firewall bouncer](https://github.com/crowdsecurity/cs-firewall-bouncer) will simply "add" malevolent IPs to nftables/ipset set of blacklisted IPs.
[nginx bouncer](https://github.com/crowdsecurity/cs-nginx-bouncer) will check every unknown IP against the local API before letting go through or serving a *403* to the user, while a [firewall bouncer](https://github.com/crowdsecurity/cs-firewall-bouncer) will simply "add" malevolent IPs to nftables/ipset set of blacklisted IPs.
Bouncers rely on [crowdsec's Local API](/Crowdsec/v1/localAPI/) to be able to get informations about a given IP or such.
You can explore [available {{v1X.bouncers.name}} on the hub]({{v1X.hub.bouncers_url}}).

13
docs/v1.X/docs/getting_started/concepts.md
View file

@ -16,7 +16,7 @@ Then, {{v1X.bouncers.htmlname}} can "consume" those decisions (via the very same
## Crowd sourced aspect
[[References](/Crowdsec/v1/getting_started/crowd-power)]
[[References](https://crowdsecurity.github.io/api_doc/index.html?urls.primaryName=CAPI)]
Whenever the {{v1X.lapi.htmlname}} receives an alert with associated decisions, the meta information about the alert are shared with our central api :
@ -24,7 +24,16 @@ Whenever the {{v1X.lapi.htmlname}} receives an alert with associated decisions,
- The scenario that was triggered
- The timestamp of the attack
These are the only information that are sent to our API. Those are then processed on our side to be able to redistribute relevant blocklists to all the participants.
These are the only information that are sent to our API. Those are then processed on our side to be able to redistribute relevant blocklists to all the participants. You can check the central API documentation in the references link to have an exhaustive view of what might be shared between your instance and our services.
## Bouncers
[[References](/Crowdsec/v1/bouncers/)]
Bouncers are standalone software pieces in charge of acting upon IPs that triggered alerts.
To do so, bouncers are going to query the local API to know if there is an existing decisions against a given IP, range, username etc. [You can find a list of existing bouncers on the hub]({{v1X.bouncers.url}})
# Configuration items

2
docs/v1.X/docs/localAPI/index.md
View file

@ -7,6 +7,8 @@ The Local API (LAPI) is a core component of {{v1X.crowdsec.name}} and has a few
- Allow `cscli` to view add or delete decisions
[You can find the swagger documentation here](https://crowdsecurity.github.io/api_doc/index.html?urls.primaryName=LAPI)
## Authentication
There is two kinds of authentication to the local API :