CrowdSec on Ubuntu 24.04 on Azure User Guide

Overview

CrowdSec is an open-source (MIT) collaborative intrusion detection and prevention system. Its Security Engine parses your local logs (the systemd journal, SSH/auth activity), runs behavioural scenarios to spot aggressive behaviour such as SSH brute-force, and ships decisions to bouncers that enforce bans. The cloudimg image installs CrowdSec from the official CrowdSec package repository, enables the crowdsec.service agent with its Local API (LAPI), installs the crowdsecurity/linux and crowdsecurity/sshd collections so the appliance parses the journal and detects SSH attacks out of the box, and installs the iptables firewall bouncer so aggressive IPs are actively banned. Backed by 24/7 cloudimg support.

What is included:

• CrowdSec Security Engine (crowdsec.service) and the cscli management CLI
• The Local API (LAPI) bound to 127.0.0.1:8080 with a /health liveness endpoint
• The crowdsecurity/linux and crowdsecurity/sshd collections (journal parsing + SSH brute-force scenarios)
• The crowdsec-firewall-bouncer-iptables bouncer that enforces bans
• A per-VM Local API machine credential rotated on first boot (no shared default identity)
• 24/7 cloudimg support

This is a security daemon product: the Local API listens on 127.0.0.1:8080 only. The port is not opened to the internet - the engine works entirely from this VM's local logs and cscli is run on the VM.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point. NSG inbound: allow 22/tcp from your management network. No inbound application ports are needed because the Local API is loopback-only.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for CrowdSec by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) only. Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name crowdsec \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm CrowdSec is installed and running

crowdsec -version | head -1
systemctl is-active crowdsec

You should see a CrowdSec version line and active.

Step 5 - Check the Security Engine and Local API

cscli lapi status confirms the agent can authenticate to the Local API. The LAPI also exposes a plain HTTP /health endpoint on loopback.

sudo cscli lapi status
curl -s http://127.0.0.1:8080/health

cscli lapi status reports that you can successfully interact with the Local API, and /health returns a small JSON status document.

Step 6 - Review the loaded collections and scenarios

The image ships with the crowdsecurity/linux and crowdsecurity/sshd collections, which bring in the SSH brute-force and log-parsing scenarios.

sudo cscli collections list
sudo cscli scenarios list

You should see crowdsecurity/linux and crowdsecurity/sshd enabled, along with the crowdsecurity/ssh-bf family of scenarios.

Step 7 - Confirm the engine is parsing and watch for detections

cscli metrics shows the acquisition, parser and Local API activity, proving the engine is reading your logs. cscli decisions list and cscli alerts list show any bans and alerts the engine has raised (a freshly deployed VM starts with a clean history).

sudo cscli metrics
sudo cscli decisions list
sudo cscli alerts list

As real traffic hits the VM (for example repeated failed SSH logins from an attacker), the SSH scenarios fire, an alert is raised, and the firewall bouncer adds a ban decision - visible in cscli decisions list.

Step 8 - Confirm the firewall bouncer is registered

The iptables firewall bouncer enforces the engine's ban decisions at the network layer.

sudo cscli bouncers list

You should see the firewall bouncer registered and validated.

Security model

The Local API binds 127.0.0.1:8080 only and is never exposed publicly - keep your NSG limited to 22/tcp from trusted networks. CrowdSec auto-manages its machine and bouncer credentials; the cloudimg image rotates the per-VM Local API machine credential on first boot so every VM has its own identity. To extend protection, install additional collections from the CrowdSec Hub with sudo cscli collections install <name> and add bouncers for your web server, firewall or cloud edge.

Whitelist your admin network (avoid locking yourself out)

Because the firewall bouncer enforces SSH brute-force bans, repeated connections from a single source can trigger a ban. The image ships with loopback and the RFC1918 private ranges already whitelisted, and an editable whitelist at /etc/crowdsec/parsers/s02-enrich/cloudimg-admin-whitelist.yaml. Add your admin public IP or CIDR under ip: / cidr: in that file, then reload the engine with sudo systemctl reload crowdsec. If you ever lock yourself out, use the Azure Portal serial console (or run-command) to clear active bans with sudo cscli decisions delete --all.

Support

This image is maintained by cloudimg with 24/7 support. CrowdSec is a trademark of CrowdSec SAS; this image is not affiliated with or endorsed by CrowdSec SAS. See the cloudimg guides for more.