Security Engine No Alerts
The Engine No Alerts issue appears when your Security Engine has been running but hasn't forwarded any alerts to the Central API in the last 48 hours.
What Triggers This Issue
- Trigger condition: No alerts generated for 48 hours
- Criticality: ⚠️ High
- Impact: Your detection system may not be working as expected
Common Root Causes
- Appropriate collections not installed: Make sure you have the detection scenarios and/or appsec rules covering your services needs
- Events massively whitelisted: Due to misconfiguration, proxy-ing issues or faulty custom whitelisting.
- Scenarios in simulation mode: Detection scenarios are installed but set to simulation mode, preventing actual alerts.
- Legitimate low-activity environment: Your proactive defenses might be good enough that you don't detect additional malicious behaviors (CrowdSec blocklists or other protections may already deflect all malicious activity)
Other Issues
- 🔗 No logs being read: The acquisition configuration may be missing, disabled, or pointing to empty log sources.
- 🔗 No logs being parsed: Logs are being read but parsers can't process them due to format mismatches or missing collections.
Diagnosis & Resolution
If it's not due to other issues, here are the diagnosis and resolutions for other root causes.
Appropriate collections not installed
🔎 Check installed collections match your services
Verify you have collections matching your protected services:
sudo cscli collections list
Run this command for Docker or Kubernetes
docker exec crowdsec cscli collections list
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli collections list
Compare your installed collections against your actual services (nginx, apache, ssh, etc.). Missing collections means no detection rules for those services.
You can try to run a test on your logs to spot issues. See the cscli explain documentation
🛠️ Install required collections for your services
Visit the CrowdSec Hub to find collections for your stack by either browsing or using the search bar. A collection is meant to embed parsers adn scenario that cover all that CrowdSec can detect for a given service: ie. The NGINX collection will have NGINX parser and Scenario correcpondig to HTTP base attacks.
Collections are packaged for various type of services:
- Web servers:
crowdsecurity/nginx,crowdsecurity/apache2,crowdsecurity/caddy - SSH:
crowdsecurity/sshd - Linux base:
crowdsecurity/linux - AppSec/WAF:
crowdsecurity/appsec-*collections for application-level protection
Install collections using:
sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli collections install crowdsecurity/nginx
docker restart crowdsec
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli collections install crowdsecurity/nginx
kubectl rollout restart deployment/crowdsec -n crowdsec
Events massively whitelisted
Misconfiguration of whitelists may result in alerts being ignored
🔎 Check whitelisting metrics
Verify if you have a lot of whitelisted lines maybe all of them.
sudo cscli metrics show acquisition
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli metrics show scenarios
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show scenarios
Look at the Lines whitelisted column
╭────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Acquisition Metrics │
├───────────────────────┬──────────────┬────────────────┬────────────────────────┬───────────────────┤
│ Source │ Lines read │ Lines parsed │ Lines unparsed │ Lines poured to bucket │ Lines whitelisted │
├──────────┼────────────┼──────────────┼────────────────┼────────────────────────┼───────────────────┤
│ file:... │ 743 │ 635 │ 108 │ - │ 185 │
╰──────────┴────────────┴──────────────┴────────────────┴────────────────────────┴───────────────────╯
🛠️ Make sure the IP in your logs are public IPs
Due to some misconfiguration or choice of log file it cna happen that the source IPs in the log are not the X-Forwarded-For but a private IP or your infrastructure.
Look at your log files and make sure any proxying mechanism in front of your service provide the X-Forwarded-For source IPs.
🛠️ Review and adjust your custom whitelist configuration
If you create custom whitelist configuration via s02-enrich, make sure it's not discarding legitimate alerts.
Check our documentation about whitelisting.
Scenarios in simulation mode
🔎 Check if scenarios are in simulation mode
Verify whether your scenarios are set to simulation mode:
sudo cscli simulation status
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli simulation status
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli simulation status
If scenarios are listed, they're in simulation mode and won't be sent to CrowdSec console (they should however still appear in cscli alerts list).
🛠️ Disable simulation mode to generate alerts
Disable simulation mode to allow alerts to be generated:
sudo cscli simulation disable --all
sudo systemctl reload crowdsec
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli simulation disable --all
docker restart crowdsec
``
**Kubernetes**
```bash
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli simulation disable --all
kubectl rollout restart deployment/crowdsec -n crowdsec
You can also disable simulation for specific scenarios only:
sudo cscli simulation disable crowdsecurity/ssh-bf
sudo systemctl reload crowdsec
Legitimate low-activity environment
If you have protection measures deployed ahead of your services it might block all unwanted traffic already.
With the state of background noise on the internet it's unlikely for a popular service exposed on the internet to completely avoid reconnaissance traffic but CrowdSec blocklists are very efficient at that and may be blocking all bad traffic already.
Let's check
🔎 Check traffic volume being processed
Check how much traffic your service is processing:
sudo cscli metrics show acquisition parsers
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli metrics show acquisition parsers
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show acquisition parsers
Look at "Lines parsed" - if this number is very low (dozens or hundreds per day), you may simply have insufficient traffic volume for malicious activity to appear.
🔎 Check if blocklists are blocking threats upstream
Check if proactive defenses are blocking threats upstream. you can do so with cscli or within the console remediation metrics if you have a compatible bouncer.
sudo cscli decisions list
sudo cscli metrics show bouncers
Run this command for Docker or Kubernetes
Docker
docker exec crowdsec cscli decisions list
docker exec crowdsec cscli metrics show bouncers
Kubernetes
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli decisions list
kubectl exec -n crowdsec -it $(kubectl get pods -n crowdsec -l type=lapi -o name) -- cscli metrics show bouncers
High numbers of active decisions or bouncer blocks may indicate your proactive defenses are effectively blocking all malicious actors. However lets make sure no other issues
Related Issues
- Log Processor No Logs Read - If acquisition is not working
- Log Processor No Logs Parsed - If parsing is failing
- Security Engine Troubleshooting - General Security Engine issues
Getting Help
If you've verified logs are being read and parsed correctly but still see no alerts:
