CrowdSec
CrowdSec from Debian: detects attacks in the logs (SSH from the journal, nginx, Apache) and blocks the addresses with nftables (own tables). Shares signals with the CrowdSec community and uses its blocklist; private networks are never blocked. Manage with cscli
Add to a guest
In the guest as root – container and VM alike:
update --add-modules crowdsecRuns a normal update and installs the module on the way.
From the Proxmox node, without logging in:
pct exec <ID> -- update --add-modules crowdsec # container
ssh root@<IP> update --add-modules crowdsecChoose when creating a guest
Without a dialog, on the Proxmox node:
IAC_NONINTERACTIVE=1 var_modules=auto-update,crowdsec \
bash -c "$(curl -fsSL https://iac.heyer.systems/<app>/ct.sh)"var_modules replaces the app's preselection – keep auto-update in the list if you want it. Interactive: choose “advanced” in the dialog, or tick the module in the generator on the app page.
Remove
update --remove-modules crowdsecRemoves the module's packages, services, firewall rules and configuration again. Data stays.
Details
CrowdSec from Debian detects attacks in the logs – SSH from the
journal, plus nginx and Apache – and blocks the addresses with nftables in tables of its own
(ip crowdsec, ip6 crowdsec6); the iac firewall stays untouched. CrowdSec reports detected
attacks to CrowdSec’s Central API and in return receives the community blocklist. Addresses from
private networks are never blocked.
cscli decisions list # local bans (with -a also the community's)
cscli decisions delete --ip 192.0.2.10 # lift a ban
cscli metrics # what was read and detected
The local API of CrowdSec only listens on 127.0.0.1:6880, because port 8080 is taken by many
apps. In a VM the module is installed on the first boot, not in the image – so every instance has
its own credentials. When the module is removed, all bans disappear as well. For SSH one of the
two is enough: crowdsec or fail2ban.