CrowdSec

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for CrowdSec. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of t3.small or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, then create or select a security group that opens port 22 from your management network. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialisation runs a few seconds after the instance state becomes Running and the status checks pass. It rotates the per-instance Local API and bouncer credentials, then starts the engine and the firewall bouncer.

The command below launches an instance from the SecureAnyCloud CrowdSec Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name and <subnet-id> with your subnet ID. Replace <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.small \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=crowdsec}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name. You can find it in the EC2 console or with aws ec2 describe-instances.

Connect over SSH with your key pair and the login user for your operating system variant.

OS variant SSH login user

Ubuntu 24.04 ubuntu

ssh -i <key-name>.pem ubuntu@<public-ip>

A welcome banner prints the most useful commands. Run sudo cat /root/crowdsec-info.txt to see the full getting-started notes: what is running, where the per-instance credentials live, and the cscli commands to operate the engine.

CrowdSec runs as two system services, both enabled and started on boot. The crowdsec detection agent also serves the Local API, and the crowdsec-firewall-bouncer is the remediation component. Confirm that both are active:

systemctl is-active crowdsec crowdsec-firewall-bouncer

The output shows active twice. For the full unit status of either service, including the main PID and memory use, run systemctl status crowdsec --no-pager or systemctl status crowdsec-firewall-bouncer --no-pager.

Next, confirm the installed version, which is pinned to CrowdSec 1.7.8 on this image, and check that the agent can authenticate to the Local API:

sudo cscli version
sudo cscli lapi status

cscli version reports v1.7.8. cscli lapi status reports that you can successfully interact with the Local API, which proves that the agent and the embedded API are wired up correctly.

The agent serves an embedded Local API. On this image it is bound to loopback only (127.0.0.1:8080), so it answers on the instance but is never exposed to the network. Check the health endpoint, which returns HTTP 200 while the engine is healthy:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/health

The output is 200. The Local API holds the registered machines and bouncers, the raised alerts and the active decisions, all backed by a local database on the dedicated data volume.

You drive the API entirely through cscli, so there is no web interface to secure and the API stays private by default. To distribute decisions to bouncers on other hosts, register them against this Local API and expose port 8080 on your own terms.

cscli is the command-line interface to the engine. Inspect the acquisition and processing metrics to confirm that the pipeline is reading and parsing logs:

sudo cscli metrics show acquisition

The output lists the log sources the engine is reading (the SSH journal and the auth log), with lines-read and lines-parsed counters. Then list the detection collections installed on this image:

sudo cscli collections list

The crowdsecurity/linux and crowdsecurity/sshd collections ship installed, so brute-force and credential-stuffing behaviour against the host is detected out of the box. Each collection bundles the parsers and scenarios for one class of workload.

When a scenario fires, the engine records a decision, typically a ban, in the Local API. The firewall bouncer enforces it in iptables and ipset. List the active decisions and the registered bouncers:

sudo cscli decisions list
sudo cscli bouncers list

The bouncers list shows the crowdsec-firewall-bouncer registered with its per-instance API key. A recent Last API pull timestamp proves that it is polling the engine.

You can add and remove bans by hand at any time. These commands add a four-hour ban on an example address and then remove it:

sudo cscli decisions add --ip 192.0.2.10 --duration 4h --reason "manual block"
sudo cscli decisions delete --ip 192.0.2.10

The firewall bouncer picks up the new decision on its next pull and drops traffic from the banned address at the host firewall. It removes the rule when the decision is deleted or expires.

CrowdSec ships a hub of detection collections for web servers, proxies, mail servers, databases and dozens of other applications. Browse the available collections and install the ones that match your workloads. This example installs the nginx collection, then reloads the engine to load it:

sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec

To feed the new scenarios, point the engine's log acquisition at your own sources. The acquisition configuration is at /etc/crowdsec/acquis.yaml, and on this image it tails the SSH journal and the auth log. Add stanzas for your web server access logs, proxy logs or application logs, then reload the engine with sudo systemctl reload crowdsec.

The whitelists in the installed collections keep known-good actors from being banned. Add your own management addresses to a whitelist so you are never locked out.

The Local API database and engine state live on a dedicated EBS volume mounted at /var/lib/crowdsec. This keeps the security-engine database off the operating system disk and lets you resize or snapshot it independently. Confirm the mount with:

df -h /var/lib/crowdsec

The database under /var/lib/crowdsec/data holds the machines, bouncers, alerts and decisions. The hub content the engine uses to parse and detect also lives under this tree.

To grow the volume, expand the EBS volume in the AWS console. Then grow the filesystem on the instance by running sudo resize2fs on the underlying device.