# Concepts

## Global overview[​](#global-overview "Direct link to Global overview")

This page defines the core CrowdSec concepts and how the components interact. It focuses on how detection is done, where data is stored, and where remediation is enforced.

## Security Engine[​](#security-engine "Direct link to Security Engine")

> The Security Engine is the CrowdSec software you install (an IDS: Intrusion Detection System). It detects threats and produces alerts. The Local API can turn alerts into decisions using [profiles](https://docs.crowdsec.net/docs/next/local_api/profiles/intro.md). Threat prevention (blocking) is enforced by Remediation Components (bouncers). Internally, the Security Engine is made of two main components: the Log Processor (detection) and the Local API (storage and decision distribution).

A Security Engine can run [standalone](https://docs.crowdsec.net/docs/next/intro.md#architecture) (Log Processor + Local API on the same host) or in a [distributed setup](https://docs.crowdsec.net/docs/next/intro.md#deployment-options) (multiple Log Processors sending alerts to a shared Local API). This lets you adapt CrowdSec to your infrastructure and constraints.

In a distributed setup, detection content (collections/parsers/scenarios) runs on the Log Processor machines, while the Local API focuses on storing data and serving decisions. See the [multi-server setup guide](https://docs.crowdsec.net/u/user_guides/multiserver_setup.md) for a concrete deployment pattern.

### Log Processor (LP)[​](#log-processor-lp "Direct link to Log Processor (LP)")

> The Log Processor is the part of the Security Engine in charge of detecting malicious behavior based on your logs and HTTP traffic.

The Log Processor (abbreviated as `LP`) detects malicious behavior in two main ways:

* It [acquires](https://docs.crowdsec.net/docs/next/log_processor/data_sources/intro.md) logs, [parses](https://docs.crowdsec.net/docs/next/log_processor/parsers/intro.md) and [enriches](https://docs.crowdsec.net/docs/next/log_processor/parsers/enricher.md) events, then matches them against [scenarios](https://docs.crowdsec.net/docs/next/log_processor/scenarios/intro.md).
* It receives [HTTP requests](https://docs.crowdsec.net/docs/next/log_processor/data_sources/appsec.md) and matches them against [AppSec rules](https://docs.crowdsec.net/docs/next/appsec/intro.md).

When a scenario or an AppSec rule is triggered, the Log Processor sends an alert to the `LAPI`.

Related documentation:

* Installation and updates of detection content: [Collections](https://docs.crowdsec.net/docs/next/log_processor/collections/intro.md), [Hub management](https://docs.crowdsec.net/docs/next/cscli/cscli_hub.md)
* Add context to alerts (visible in `cscli`/Console): [Alert context](https://docs.crowdsec.net/docs/next/log_processor/alert_context/intro.md)
* AppSec request inspection and compatible integrations: [AppSec](https://docs.crowdsec.net/docs/next/appsec/intro.md)

### Local API (LAPI)[​](#local-api-lapi "Direct link to Local API (LAPI)")

> The Local API is the part of the Security Engine that stores alerts/decisions and acts as the middleman between Log Processors, Remediation Components, and the Central API.

The Local API (abbreviated as `LAPI`) has several roles:

* Receive alerts from Log Processors and (optionally) create decisions based on configured [profiles](https://docs.crowdsec.net/docs/next/local_api/profiles/intro.md).
* Expose decisions to [Remediation Components](https://docs.crowdsec.net/u/bouncers/intro.md) so they can enforce them.
* Interact with the Central API to share signals and receive community blocklists.

For implementation details, see:

* Local API configuration for distributed setups: [Local API configuration](https://docs.crowdsec.net/docs/next/local_api/configuration.md)
* How bouncers consume decisions: [Bouncers API](https://docs.crowdsec.net/docs/next/local_api/bouncers.md)
* Authentication methods: [Local API authentication](https://docs.crowdsec.net/docs/next/local_api/authentication.md)
* Notifications: [Notification plugins](https://docs.crowdsec.net/docs/next/local_api/notification_plugins/intro.md)
* Storage: [Databases](https://docs.crowdsec.net/docs/next/local_api/database.md)
* Controlling exemptions: [AllowLists](https://docs.crowdsec.net/docs/next/local_api/centralized_allowlists.md)

## Glossary[​](#glossary "Direct link to Glossary")

Quick definitions of terms used throughout the documentation and in tools like `cscli`:

* **Collections**: bundles of parsers, scenarios, and other items installed together. See [Collections](https://docs.crowdsec.net/docs/next/log_processor/collections/intro.md) and [Hub management](https://docs.crowdsec.net/docs/next/cscli/cscli_hub.md).
* **Scenarios**: behavior detections evaluated by the Log Processor. See [Scenarios](https://docs.crowdsec.net/docs/next/log_processor/scenarios/intro.md).
* **AppSec rules**: WAF rules evaluated by the AppSec component. See [AppSec](https://docs.crowdsec.net/docs/next/appsec/intro.md).
* **Alerts**: records created when a scenario/AppSec rule triggers; stored in the Local API. See [`cscli alerts`](https://docs.crowdsec.net/docs/next/cscli/cscli_alerts.md).
* **Decisions**: remediation instructions (for example `ban`, sometimes other types depending on your setup) created by Local API [profiles](https://docs.crowdsec.net/docs/next/local_api/profiles/intro.md) or manually via `cscli`; consumed by bouncers. See [`cscli decisions`](https://docs.crowdsec.net/docs/next/cscli/cscli_decisions.md) and [Bouncers API](https://docs.crowdsec.net/docs/next/local_api/bouncers.md).

## Remediation Components (Bouncers)[​](#remediation-components-bouncers "Direct link to Remediation Components (Bouncers)")

> The Remediation Components (also called `Bouncers`) are external components in charge of enforcing decisions.

Remediation Components rely on the Local API to receive decisions about malicious IPs to be blocked *(or other remediation types such as CAPTCHA, supported by some bouncers).*<br />*Note that they also support [CrowdSec's Blocklist as a Service](https://docs.crowdsec.net/u/integrations/intro.md).*

Those decisions can come from detections made by the `LP` or from blocklists.

Remediation Components leverage existing parts of your infrastructure to block malicious IPs where it matters most (firewall, reverse proxy, web server, ...). You can find them on our [Remediation Components Hub](https://app.crowdsec.net/hub/remediation-components).

## Central API (CAPI)[​](#central-api-capi "Direct link to Central API (CAPI)")

> The Central API (CAPI) serves as the gateway for network participants to connect and communicate with CrowdSec's network.

The Central API (abbreviated as `CAPI`) receives attack signals from participating Security Engines and signal partners. It then redistributes curated community decisions (the [Community Blocklist](https://docs.crowdsec.net/docs/next/central_api/community_blocklist.md)).

The Central API is also at the heart of CrowdSec centralized [blocklist services](https://docs.crowdsec.net/u/blocklists/intro.md).

For details about what data is sent (and when), see the [Central API introduction](https://docs.crowdsec.net/docs/next/central_api/intro.md). If you want to disable sharing to the Central API, see [how to disable the Central API](https://docs.crowdsec.net/u/troubleshooting/security_engine.md#how-to-disable-the-central-api).

## Console[​](#console "Direct link to Console")

> The CrowdSec Console is a web-based interface for reporting, alerting, and management across your CrowdSec products (from your fleet of Security Engines to CTI-related actions).

The [Console](https://app.crowdsec.net) allows you to:

* [Manage alerts](https://docs.crowdsec.net/u/console/alerts/intro.md) from your security stack.
* [Manage decisions](https://docs.crowdsec.net/u/console/decisions/decisions_intro.md) in real time.
* View and use [blocklists and integrations](https://docs.crowdsec.net/u/blocklists/intro.md).
* Manage your API keys ([CTI API](https://docs.crowdsec.net/u/cti_api/intro.md), [Service API](https://docs.crowdsec.net/u/console/service_api/getting_started.md)).

To connect an instance to the Console, see [Console enrollment](https://docs.crowdsec.net/u/getting_started/post_installation/console.md) and the `cscli` command reference: [`cscli console enroll`](https://docs.crowdsec.net/docs/next/cscli/cscli_console_enroll.md).

## Example: from a log line to a block[​](#example-from-a-log-line-to-a-block "Direct link to Example: from a log line to a block")

This is a typical flow for a log-based scenario (for example, SSH brute-force):

1. **Install detection content**: you typically install a [collection](https://docs.crowdsec.net/docs/next/log_processor/collections/intro.md) from the Hub (parsers + scenarios) using `cscli` (see [Hub management](https://docs.crowdsec.net/docs/next/cscli/cscli_hub.md)).
2. **Acquire**: the Log Processor reads your service logs via an [acquisition configuration](https://docs.crowdsec.net/docs/next/log_processor/data_sources/intro.md) (for example, a file tail on `/var/log/auth.log`).
3. **Parse + enrich**: [parsers](https://docs.crowdsec.net/docs/next/log_processor/parsers/intro.md) extract fields (source IP, service, status, ...) and [enrichers](https://docs.crowdsec.net/docs/next/log_processor/parsers/enricher.md) add context (GeoIP/ASN, ...).
4. **Detect**: a [scenario](https://docs.crowdsec.net/docs/next/log_processor/scenarios/intro.md) correlates events over time (for example, many failed logins from the same IP) and triggers an **alert**.
5. **Store + decide**: the Log Processor sends the alert to the `LAPI`. The `LAPI` applies your [profiles](https://docs.crowdsec.net/docs/next/local_api/profiles/intro.md) to create a **decision** (for example, `ban` for a given duration).
6. **Enforce**: a [Remediation Component (bouncer)](https://docs.crowdsec.net/u/bouncers/intro.md) pulls decisions from the `LAPI` and enforces them where it matters (firewall, reverse proxy, web server, ...).