This is taking longer than expected.

Try againBrowse the library
AI Blocks

AI Blocks › Keep your code secure

CrowdSec protection checker

Share CrowdSec settings, protected services and status. It checks the supplied evidence and lists gaps, including the bouncer that blocks traffic, plus checks for an operator.

Bring CrowdSec settings and status. Get a check of protection gaps, including whether the bouncer can block traffic.

Free · No account · MIT licence · Made by magnus919 · Tested · Updated 28 Oct 2026

What you get

What goes in

  • Your host or container name, and the CrowdSec version
  • A few log lines from the service you protect
  • What you see going wrong
  • Your allowed scope, maintenance window and undo plan

Before you start

  • Read access to the host or container
  • An AI that can read your pasted command output (it cannot run commands for you in a chat)

What comes out

  • Scope and undo record: The target, version, what may be changed, and how to undo each change.
  • Stage-by-stage diagnosis: Status and evidence for log capture, parsing, scenarios, decisions and the bouncer, in that order.
  • Failed stage: The first stage where protection stops, and why an alert alone does not prove blocking.
  • Bounded fix: A small change that fixes the failed stage, with the safety checks to run before it.
  • Proof plan: A harmless test to show the proxy or firewall really blocks, plus what the test cannot show.

Is it for you?

Use it when

  • Alerts fire but blocked requests still reach your app.
  • A bouncer shows a stale last-pull time, or no decisions arrive.
  • Logs are coming in but nothing gets parsed or matched to a scenario.

Skip it when

  • You need general firewall design: use a firewall guide or your platform's own docs, then come back for the CrowdSec part.
  • You need Kubernetes or reverse-proxy design: ask a person or tool that knows that platform, and use this only for the CrowdSec link.
  • You want to change live blocking with no undo plan or maintenance window: agree both with your team first.

Fill it in

Add what this task works from, then copy the request.

  • The authorized host/container, installed CrowdSec version, log samples and observed symptoms.
  • Read access plus the agreed action scope, maintenance window and rollback plan before changes.

Run it

Download the complete instructions and supporting files. Add them to Claude, ChatGPT or Gemini once, then ask for it by name in any chat. Pasting the instructions into a chat works too.

Download all files

Before and after this skill

Choose the steps you need. Bring your own material when you have it.

Before

Bring the material listed under Fill it in.

This skill

CrowdSec protection checker

Open builder

After

Details

From magnus919. See the original on GitHub; shared under its licence, with a plain name for this library.

What it does

Bring host details and log samples. Trace each stage, then get a fix and proof plan.

What goes in and out

You give it

  • The authorized host/container, installed CrowdSec version, log samples and observed symptoms.
  • Read access plus the agreed action scope, maintenance window and rollback plan before changes.

You get

  • A stage-by-stage diagnosis from log capture through parser, scenario, decision and bouncer.
  • A bounded fix and harmless proof plan; an alert alone is not evidence of blocking.

Use it when

  • Alerts fire but blocked requests still reach your app.
  • A bouncer shows a stale last-pull time, or no decisions arrive.
  • Logs are coming in but nothing gets parsed or matched to a scenario.
  • You are handing over a CrowdSec setup and need proof that it blocks.

More for Keep your code secure

Every keep your code secure skill

How the task works

  • Confirm scope and recovery. Record target, version, read/write boundary and undo path. Prefer inspection and simulation before enforcement.
  • Trace the protection chain. Check acquisition, parsing, scenarios, decisions and bouncer activity in order to locate the failed stage.
  • Prove the scoped fix. Use benign fixtures and inspect the actual proxy/firewall outcome, retaining evidence and limits.

Full instructions

  • Download the complete skill folder and add it to your AI tool, or copy the instructions into a chat.
  • Provide the inputs listed here and ask your AI to follow the skill.
  • A chat AI cannot run commands on your host. You run each cscli or log command it asks for, then paste the output back.
  • Review the result and any missing facts before using it.
  • Use the operations checklist and the bouncer guide in the skill's references folder (Traefik or Nginx) to hand the setup over.

Full instruction file

CrowdSec

CrowdSec detects hostile behavior from logs and HTTP requests, then exposes alerts and decisions through LAPI. The engine alone does not block traffic: install and verify at least one remediation component (bouncer) before claiming protection.

Before you start

Use the material below to do this job. If facts or tool access are missing, explain what you can finish and what must wait.

What you need (use your own material or the linked skill):

  • Your question (yours): the decision or problem, and what a good outcome looks like.
  • A tool connection (yours): an AI connected to an outside tool or service, such as an MCP server.

How to start:

  1. Look first. Use what they've already attached, pasted or put in their about-me note. In a coding assistant with file access, look in the project too for these by name.
  2. Check what's missing. Look for your question, a tool connection. They can attach files, paste the details, or share a file path your assistant can read. Ask only for missing facts that change the result. If they ask you to start with what they have, complete the parts you can and mark the gaps.
  3. Do the job. Follow the skill below with the facts and tools you have. Mark each gap with MISSING: where it belongs and never invent a fact to fill it.
Safety Gate

Before any mutation, confirm the target host/container, scope, backup or rollback, and maintenance window. Prefer read-only inspection and simulation first. Never manually delete decisions, collections, or data without recording the reason and an undo path. Save bouncer keys when created; they are shown once. Use simulation: true while tuning scenarios so detections are observed without enforcement, then verify allowlists before live blocking.

If you cannot run commands yourself, ask the person to run each read-only cscli or log command and paste the output. Do not guess what a command would return.

Choose a Deployment

For Debian/Ubuntu, add the CrowdSec repository, install crowdsec, then install a remediation package such as crowdsec-firewall-bouncer-iptables or -nftables. For Docker Compose, expose LAPI (127.0.0.1:8080), metrics (127.0.0.1:6060), and AppSec (127.0.0.1:7422) only to required networks, mount /etc/crowdsec, /var/lib/crowdsec/data, and logs read-only, and pin a reviewed image version. Persist the data directory, mandatory for v1.7.0+. Load the Docker deployment guide for a full compose example and remote-agent caveats.

After installation, verify systemctl status crowdsec (or container health), then cscli version, cscli collections list, acquisition metrics, and bouncer connectivity. Do not expose LAPI or AppSec publicly without an explicit network and authentication design.

The Detection-to-Blocking Workflow
  1. Select collections for the actual log format, for example crowdsecurity/linux, sshd, nginx, traefik, or base-http-scenarios.
  2. Configure acquisition in /etc/crowdsec/acquis.yaml or acquis.d/; every source needs labels.type so the correct parser runs. Use poll_without_inotify: true for unreliable NFS/SMB or bind mounts and use_time_machine: true for buffered logs.
  3. Check parser/scenario hits and unparsed lines with cscli metrics -o json.
  4. Use profiles to map alerts to decisions. Keep profiles.yaml.local and remember YAML sequences replace rather than merge.
  5. Add a bouncer with cscli bouncers add NAME, store its one-time key securely, and verify cscli bouncers list plus a harmless test decision.
  6. Confirm the reverse proxy/firewall is actually enforcing decisions; an alert or LAPI decision alone is not proof of a blocked request.

For complete configuration directives, database choices, and hardening, read config-reference, database-config, and production-hardening.

cscli Essentials

Use cscli -o json for automation and capture command output, version, host, and time as evidence. Read-only triage commonly uses:

cscli version
cscli hub list
cscli collections list
cscli alerts list --contain "scenario:ssh-bf"
cscli decisions list -o json
cscli metrics -o json
cscli explain --file /path/to/sample.log

cscli hub update refreshes the local hub index and can change local state. It is optional, not part of the read-only triage path, and requires the safety gate above before running it. Manage hub items with collections|parsers|scenarios install/list/upgrade/inspect; those install, upgrade, and delete operations also require the safety gate. Manage alerts and decisions with alerts list/inspect and decisions add/list/delete; mutation commands require the safety gate above. Manage bouncers and machines with bouncers add/list/delete and machines add/list/delete. Use console status, console enroll, and lapi register only after confirming the destination and credentials. Load the full cscli reference for flags, output modes, and less common commands.

Acquisition and AppSec WAF

A minimal file acquisition entry is:

filenames: [/var/log/nginx/*.log]
labels: {type: nginx}

For AppSec, install the relevant virtual-patching/CRS collections and add an appsec acquisition source listening on 7422 with appsec_config: crowdsecurity/appsec-default and labels.type: appsec. Route requests from the proxy to AppSec and decide failure behavior deliberately: fail-open preserves availability but can bypass protection; fail-closed protects more strongly but can cause an outage. Test with benign fixtures and inspect AppSec metrics before enabling blocking. In-band rules block or captcha the current request; out-of-band rules emit events for later scenarios. Load the AppSec deep dive and the relevant bouncer guide or nginx-bouncer.

Operations and Troubleshooting

Check service logs, cscli metrics, parser/unparsed counts, scenario hits, active decisions, and bouncer last-pull time in that order. Distinguish “no logs acquired”, “logs acquired but unparsed”, “parsed but no scenario hit”, “decision exists but bouncer is stale”, and “bouncer enforced but proxy routing is wrong”. Do not interpret an empty alert query as proof of safety. Use the troubleshooting guide and the operations checklist for a bounded verification packet.

Use profiles and notifications deliberately. Test notification plugins with cscli notifications test NAME; never place webhook secrets or CTI keys in examples. Enable TLS/mTLS for LAPI across trust boundaries and review community/blocklist pulls before relying on them.

After this

When you've handed it back, suggest what they could do next in one short question. It's a suggestion: if they're done, that's fine. Offer these, and say they can type their own:

  • The AI agent attack tester. It takes the security report.
  • The Prompt injection defender. It takes the security report. If they pick one and that skill is added here, carry straight on with what you just made. If not, give the link and say what to bring.
References