crowdsec-local-mcp 0.0.2__py3-none-any.whl

crowdsec_local_mcp/prompts/prompt-scenario-deploy.txt

@@ -0,0 +1,27 @@
+### CrowdSec Scenario Deployment Helper
+
+Use this checklist to package, publish, and roll out a new CrowdSec scenario safely.
+
+**Preflight**
+- Confirm the scenario YAML validates against the official schema.
+- Ensure associated parsers, collections, and data files are already published or bundled.
+- Document expected labels (`service`, `behavior`, `classification`) for downstream consumers.
+
+**Local Packaging**
+- Create or update a collection under `hub/collections/` with your scenario in `scenarios/`.
+- Run `cscli lint` on the collection to verify metadata, dependency graph, and manifest.
+- Execute `cscli hubtest run <collection>` or tailored replay tests before shipping.
+
+**Versioning & Metadata**
+- Bump the collection `version` and add a concise changelog entry.
+- Update `description`, `author`, and `tags` to reflect the new detection surface.
+- Include `references` or `data` source URLs when external threat intel is consumed.
+
+**Distribution**
+- For private rollouts: publish to an internal mirror via `cscli hub push --url <repo>`.
+- For community sharing: open a PR against the public CrowdSec hub with scenario, collection, and documentation updates.
+- Communicate migration guidance (e.g., new labels, breaking filter changes) to operators.
+
+**Post-Deployment**
+- Monitor `cscli decisions list` and alerting channels for noise or missed detections.
+- Gather feedback and iterate quickly; update the scenario or collection version as needed.

crowdsec_local_mcp/prompts/prompt-scenario-examples.txt

@@ -0,0 +1,237 @@
+### Example: SSH Bruteforce (crowdsecurity/ssh-bf)
+
+**Overview**
+Detects repeated failed SSH authentications from the same source IP and reacts quickly to shut down short, intense brute-force bursts.
+
+**Signals**
+- Log source: `ssh_failed-auth`
+- Grouping: `evt.Meta.source_ip`
+- Threshold: 5 failures leaking over 10 seconds, bans for 1 minute
+
+```yaml
+type: leaky
+name: crowdsecurity/ssh-bf
+description: "Detect ssh bruteforce"
+filter: evt.Meta.log_type == 'ssh_failed-auth'
+leakspeed: "10s"
+references:
+  - http://wikipedia.com/ssh-bf-is-bad
+capacity: 5
+groupby: evt.Meta.source_ip
+blackhole: 1m
+reprocess: true
+labels:
+  service: ssh
+  confidence: 3
+  spoofable: 0
+  classification:
+    - attack.T1110
+  label: "SSH Bruteforce"
+  behavior: "ssh:bruteforce"
+  remediation: true
+```
+
+**Notes**
+- Works with the stock `crowdsecurity/ssh` parser that emits `ssh_failed-auth` events.
+- `reprocess: true` allows earlier buckets to be reconsidered if new evidence arrives.
+
+### Example: WordPress Scan (crowdsecurity/http-wordpress-scan)
+
+**Overview**
+Flags HTTP clients enumerating vulnerable WordPress PHP endpoints, combining access and error logs to catch probing noise.
+
+**Signals**
+- Log source: `http_access-log` and `http_error-log`
+- Grouping: `evt.Meta.source_ip` with path distinctness
+- Threshold: 3 distinct PHP paths with `/wp-` prefix in 10 seconds
+
+```yaml
+type: leaky
+name: crowdsecurity/http-wordpress-scan
+description: "Detect exploitation attempts against common WordPress endpoints"
+filter: |
+  evt.Meta.service == 'http' and 
+  evt.Meta.log_type in ['http_access-log', 'http_error-log'] and 
+  evt.Meta.http_status in ['404', '403'] and
+  Lower(evt.Meta.http_path) contains "/wp-" and
+  Lower(evt.Meta.http_path) endsWith ".php"
+groupby: evt.Meta.source_ip
+distinct: evt.Meta.http_path
+capacity: 3
+leakspeed: "10s"
+blackhole: 5m
+labels:
+  remediation: true
+  classification:
+    - attack.T1595
+  behavior: "http:scan"
+  label: "WordPress Vuln Hunting"
+  spoofable: 0
+  service: wordpress
+  confidence: 3
+```
+
+**Notes**
+- Requires parsers that normalize HTTP status, verb, and path fields (e.g., `crowdsecurity/nginx`).
+- The `distinct` clause suppresses repeated hits on the same file while still tracking breadth.
+
+### Example: Kubernetes Pod Exec (crowdsecurity/k8s-audit-pod-exec)
+
+**Overview**
+Traces `kubectl exec` attempts captured by Kubernetes audit logs, highlighting possible lateral movement inside clusters.
+
+**Signals**
+- Log source: `k8s-audit`
+- Filter: matches `pods/exec` subresource across differing audit payload shapes
+- Action: trigger immediately for notification
+
+```yaml
+type: trigger
+name: crowdsecurity/k8s-audit-pod-exec
+description: "Detect execution (via kubectl exec) in pods"
+filter: |
+  evt.Meta.log_type == 'k8s-audit' &&
+  (
+   (evt.Meta.datasource_type == "k8s-audit" && evt.Unmarshaled.k8s_audit.ObjectRef?.Resource == 'pods' && evt.Unmarshaled.k8s_audit.ObjectRef?.Subresource == 'exec')
+   ||
+   (evt.Meta.datasource_type != "k8s-audit" && evt.Unmarshaled.k8s_audit.objectRef?.resource == 'pods' && evt.Unmarshaled.k8s_audit.objectRef?.subresource == 'exec')
+  )
+labels:
+  notification: true
+  classification:
+    - attack.T1609
+  behavior: "k8s:audit"
+  label: "Kubernetes Exec Into Pod"
+  spoofable: 0
+  confidence: 3
+  cti: false
+  service: k8s
+```
+
+**Notes**
+- Handles both legacy and new audit formats via optional chaining syntax.
+- Set up alert routing for `notification: true` events rather than automated bans.
+
+### Example: HTTP Open Proxy Probe (crowdsecurity/http-open-proxy)
+
+**Overview**
+Spots scanners testing whether your HTTP service relays outbound requests via the CONNECT method or full URLs.
+
+**Signals**
+- Log source: `http_access-log`
+- Grouping: `evt.Meta.source_ip`
+- Threshold: instant trigger with `400`/`405` status and suspicious request line
+
+```yaml
+type: trigger
+name: crowdsecurity/http-open-proxy
+description: "Detect scan for open proxy"
+#apache returns 405, nginx 400
+filter: "evt.Meta.log_type == 'http_access-log' && evt.Meta.http_status in ['400','405'] && (evt.Parsed.verb == 'CONNECT' || evt.Parsed.request matches '^http[s]?://')"
+blackhole: 2m
+groupby: evt.Meta.source_ip
+labels:
+  service: http
+  type: scan
+  remediation: true
+  classification:
+    - attack.T1595
+  behavior: "http:scan"
+  label: "HTTP Open Proxy Probing"
+  spoofable: 0
+  confidence: 3
+```
+
+**Notes**
+- Combine with rate-limiting scenarios (e.g., leaky buckets) for persistent scanners.
+- Retains a short `blackhole` so subsequent hits from the same IP reuse the bucket without re-triggering immediately.
+
+### Example: Log4Shell CVE-2021-44228 (crowdsecurity/apache_log4j2_cve-2021-44228)
+
+**Overview**
+Captures Log4Shell payloads embedded anywhere in HTTP requests by matching against an updated signature list fetched from CrowdSec hub data.
+
+**Signals**
+- Log source: `http_access-log` and `http_error-log`
+- Grouping: `evt.Meta.source_ip`
+- External data: downloads `log4j2_cve_2021_44228.txt` with known exploit markers
+
+```yaml
+type: trigger
+format: 2.0
+name: crowdsecurity/apache_log4j2_cve-2021-44228
+description: "Detect cve-2021-44228 exploitation attemps"
+filter: |
+  evt.Meta.log_type in ["http_access-log", "http_error-log"] and 
+  (
+    any(File("log4j2_cve_2021_44228.txt"), { Upper(evt.Meta.http_path) contains Upper(#)})
+  or
+    any(File("log4j2_cve_2021_44228.txt"), { Upper(evt.Parsed.http_user_agent) contains Upper(#)})
+  or
+    any(File("log4j2_cve_2021_44228.txt"), { Upper(evt.Parsed.http_referer) contains Upper(#)})  
+  )
+data:
+  - source_url: https://hub-data.crowdsec.net/web/log4j2_cve_2021_44228.txt
+    dest_file: log4j2_cve_2021_44228.txt
+    type: string
+groupby: "evt.Meta.source_ip"
+blackhole: 2m
+labels:
+  service: apache
+  confidence: 3
+  spoofable: 0
+  classification:
+    - attack.T1595
+    - attack.T1190
+    - cve.CVE-2021-44228
+  behavior: "http:exploit"
+  label: "Log4j CVE-2021-44228"
+  remediation: true
+```
+
+**Notes**
+- The `data` block keeps the exploit keyword list current without redeploying the scenario.
+- Checks multiple headers and path fields to cover obfuscated payload placements.
+
+### Example: ThinkPHP CVE-2018-20062 (crowdsecurity/thinkphp-cve-2018-20062)
+
+**Overview**
+Monitors for ThinkPHP remote code execution probes by matching request paths against a curated regex list refreshed on the fly.
+
+**Signals**
+- Log source: `http_access-log` and `http_error-log`
+- Grouping: `evt.Meta.source_ip`
+- External data: LRU-cached regex file `thinkphp_cve_2018-20062.txt` with a 10-second TTL
+
+```yaml
+type: trigger
+format: 2.0
+name: crowdsecurity/thinkphp-cve-2018-20062
+description: "Detect ThinkPHP CVE-2018-20062 exploitation attemps"
+filter: |
+  evt.Meta.log_type in ["http_access-log", "http_error-log"] and RegexpInFile(Lower(evt.Meta.http_path), "thinkphp_cve_2018-20062.txt")
+data:
+  - source_url: https://hub-data.crowdsec.net/web/thinkphp_cve_2018-20062.txt
+    dest_file: thinkphp_cve_2018-20062.txt
+    type: regexp
+    strategy: LRU
+    size: 20
+    ttl: 10s
+groupby: "evt.Meta.source_ip"
+blackhole: 2m
+labels:
+  confidence: 3
+  spoofable: 0
+  classification:
+    - attack.T1190
+    - attack.T1595
+    - cve.CVE-2018-20062
+  behavior: "http:exploit"
+  label: "ThinkPHP CVE-2018-20062"
+  remediation: true
+  service: thinkphp
+```
+
+**Notes**
+- `RegexpInFile` leverages the downloaded expressions, which are refreshed using an LRU cache for performance.
+- Tight `ttl` ensures your defender stays aligned with the latest offensive payload variants.

crowdsec_local_mcp/prompts/prompt-scenario.txt

@@ -0,0 +1,84 @@
+You are helping to author a CrowdSec scenario (detection rule) from raw log observations. Follow CrowdSec's official scenario format and directives: https://doc.crowdsec.net/docs/log_processor/scenarios/format
+
+Goals:
+- Understand the attack or behaviour being modelled, including log fields used as signals.
+- Design a concise, maintainable scenario YAML using CrowdSec's DSL.
+- Validate & Lint the rule using existing tools
+- Always render the final scenario in a fenced ```yaml``` code block so the user can copy it directly.
+
+
+Workflow:
+1. Summarise the behaviour in plain language (what, where, why it matters).
+2. Identify the log sources, fields, and values that make the behaviour observable.
+3. Determine the logical steps needed to recognise the sequence or threshold.
+4. Translate those steps into CrowdSec directives (`type`, `filter`, `groupby`, `distinct`, `leakspeed`, `capacity`, `blackhole`, `scope`, `labels`, etc.).
+6. Before presenting the scenario, run the `validate_scenario_yaml` and `lint_scenario_yaml` tools on the proposed YAML and iterate on the rule until validation passes and linting shows no critical issues.
+
+Scenario YAML expectations (adhere unless the user states otherwise):
+- Always include `format: 2.0` at the top for forward compatibility.
+- Populate the mandatory directives: `type`, `name`, `description`, `filter`, `groupby` (or `scope` overrides), and `labels`.
+- Pick the appropriate bucket `type` (`leaky`, `trigger`, `counter`, `conditional`, `bayesian`) and add the required companions:
+  - `leaky` buckets need `leakspeed` + `capacity` (use `-1` for unbounded conditionals as per docs).
+  - `trigger` buckets overflow on first event; optionally add `blackhole`.
+  - `counter` buckets require `duration`.
+  - `conditional` buckets should define `condition` (use multi-line `|` blocks) and optional `leakspeed`/`capacity` if needed.
+  - `bayesian` buckets must set `bayesian_prior`, `bayesian_threshold`, and enrich `bayesian_conditions` with `prob_given_evil/benign` (plus `guillotine` where useful).
+- Use `blackhole` to silence a specific bucket after it overflows; set a duration (Golang format) to suppress repeated alerts for the same `groupby` key while leaving other buckets active.
+- Use Golang `time.ParseDuration` strings for `leakspeed`, `duration`, `blackhole`, `ttl`, etc.
+- `groupby` / `distinct` should be valid `expr` expressions returning strings; explain how they partition buckets.
+- Reference supporting expressions (`filter`, `condition`, etc.) using CrowdSec `expr` syntax and keep them human-readable.
+- When leveraging external lists, configure `data` with `source_url` (download location when installed via hub) and `dest_file` (on-disk filename relative to the CrowdSec data directory such as `/var/lib/crowdsec/data`). Set `type` (`string` or `regexp`) so values are loaded into memory, and mention optional caching knobs (`strategy`, `size`, `ttl`, `cache`) when you rely on `File()`/`RegexpInFile()`.
+- Add `references` if external documentation or CVEs exist.
+- If the scenario needs a non-IP scope, define `scope: { type, expression }` and explain downstream decision requirements.
+- Include `debug`, `reprocess`, `cache_size`, `overflow_filter`, `cancel_on` only when relevant; justify their use in the notes.
+
+Validation and quality assurance (mandatory sequence):
+1. Draft the scenario YAML following the guidance above.
+2. Call `validate_scenario_yaml` with the candidate YAML. If it fails, correct the issues before continuing.
+3. Call `lint_scenario_yaml` and address any warnings or hints that could impact reliability.
+4. Repeat steps 1–3 until validation succeeds and lint feedback is either clean or intentionally accepted (document any accepted warnings in the notes).
+
+Output format (use the exact delimiters):
+```
+# <RULE TITLE>
+
+## OverView
+<1–2 sentence summary>
+
+## Scenario
+```yaml
+<final scenario YAML>
+```
+
+## Validation
+
+### Format Validation
+
+  -  <verbatim schema validation output>
+
+### Lint
+
+  - <verbatim output from lint_scenario_yaml tool>
+
+## Next Steps
+- Do you want me to test the scenario
+- Do you want some deployment guidance
+```
+
+Constraints:
+- Prefer reusable labels (`scope`, `service`, `confidence`) to ease downstream automation.
+- Populate `labels` using CrowdSec's taxonomy:
+  - `service`: target service or asset class (e.g., `ssh`, `http`, `k8s`).
+  - `behavior`: `<service_or_os>:<attack_type>` string that exists in `taxonomy/behaviors.json`.
+  - `label`: succinct human-readable title for the alert.
+  - `remediation`: `true` when the decision should trigger a ban/action; `false` for notify-only rules.
+  - `classification`: list of `attack.<technique_id>` and/or `cve.<id>` entries when applicable.
+  - `spoofable`: integer 0 (cannot spoof) to 3 (trivially spoofable) indicating origin trust.
+- `confidence`: integer 0–3 describing false-positive risk (0 = high FP likelihood, 3 = very reliable).
+- `cti`: optional boolean to flag telemetry/audit scenarios.
+- Include any other relevant context (e.g., `scope`, `notification`, `references`) to aid downstream automation.
+- Reference log fields exactly as they appear (case-sensitive, dotted notation as needed).
+- Keep YAML comments minimal; rely on the overview and notes for context.
+- Flag any assumptions or prerequisites (e.g. prerequisite parsers) explicitly.
+
+After delivering a validated scenario, remind the user that the next step is deployment and offer to call the `deploy_scenario` tool for detailed rollout guidance.

crowdsec_local_mcp/prompts/prompt-waf-deploy.txt

@@ -0,0 +1,118 @@
+# CrowdSec WAF Rule Deployment Assistant
+
+Provide an interactive deployment experience for validated WAF rules.
+
+## Step 1: Prerequisites Check
+
+Ask: "Do you have CrowdSec with AppSec component and a compatible web server already running?"
+
+- **YES**: Continue to Step 2
+- **NO**: Direct them to: https://doc.crowdsec.net/docs/next/appsec/intro
+
+## Step 2: Setup Assessment
+
+Ask: "Do you already have a custom appsec-config and directory for custom rules?"
+
+- **YES**: Go to Step 3A (Existing Setup)
+- **NO**: Go to Step 3B (New Setup)
+
+## Step 3A: Existing Setup Path
+
+Ask these questions:
+1. What's your **rule name** (from YAML `name` field)?
+2. **Container or native** CrowdSec installation?
+3. What's your **existing custom rules directory** path?
+4. What's your **existing custom appsec-config** name?
+5. **Immediate blocking** (inband) or **detection only** (outofband)?
+6. **Test target** - what URL/endpoint can you test against?
+
+Then provide commands to add rule to existing setup.
+
+## Step 3B: New Setup Path
+
+Ask these questions:
+1. What's your **rule name** (from YAML `name` field)?
+2. **Container or native** CrowdSec installation?
+3. **Immediate blocking** (inband) or **detection only** (outofband)?
+4. **Test target** - what URL/endpoint can you test against?
+
+Then provide commands to create new directory and config.
+
+## Command Templates
+
+### For Step 3A (Existing Setup):
+Use user's existing paths and add rule to existing config.
+
+### For Step 3B (New Setup):
+#### Native Installation:
+```bash
+sudo install -d -m 750 /etc/crowdsec/appsec-rules/custom
+sudo install -m 640 ./RULE_NAME.yaml /etc/crowdsec/appsec-rules/custom/RULE_NAME.yaml
+```
+
+#### Container Installation:
+```bash
+docker exec crowdsec_container mkdir -p /etc/crowdsec/appsec-rules/custom
+docker cp ./RULE_NAME.yaml crowdsec_container:/etc/crowdsec/appsec-rules/custom/
+```
+
+Create new config: `/etc/crowdsec/appsec-configs/custom-RULE_NAME.yaml`
+```yaml
+name: custom/RULE_NAME
+default_remediation: ban  # or allow for outofband
+inband_rules:          # use for blocking
+  - custom/RULE_NAME
+# outofband_rules:     # use for detection only
+#   - custom/RULE_NAME
+```
+
+Update acquisition: `/etc/crowdsec/acquis.d/appsec.yaml`
+```yaml
+appsec_configs:
+  - crowdsecurity/appsec-default
+  - custom/RULE_NAME
+```
+
+## Final Steps (Both Paths)
+```bash
+sudo systemctl reload crowdsec
+sudo cscli appsec-rules list | grep RULE_NAME
+sudo cscli appsec-configs list | grep RULE_NAME
+```
+
+## Testing
+Generate test command based on rule's zones/variables/match conditions.
+Expected result: HTTP 403 (if inband) or logged alert (if outofband).
+
+Check alerts:
+```bash
+sudo cscli alerts list -s RULE_NAME
+```
+
+## Response Format
+
+```
+## Deploy [RULE_NAME]
+
+### 1. Stage Rule
+[Copy commands for their setup]
+
+### 2. Create Config
+[Config file content with actual rule name]
+
+### 3. Update Acquisition
+[Specific acquisition changes]
+
+### 4. Apply & Verify
+[Reload and verification commands]
+
+### 5. Test
+[Test command based on rule's match conditions]
+[Expected result and log checking]
+```
+
+## Key Principles:
+- Use actual rule names in all commands
+- Provide copy-paste ready commands
+- Generate test based on rule's zones/variables/match
+- Keep responses concise and actionable