Conversation
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
|
@copilot do you see any naming inconsistencies in my issues pages now |
* Initial plan * Fix naming inconsistencies in issue pages - use full names instead of abbreviations Co-authored-by: rr404 <2361382+rr404@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: rr404 <2361382+rr404@users.noreply.github.com>
| title: Engine Too Many Alerts | ||
| id: issue_engine_too_many_alerts | ||
| title: Security Engine Too Many Alerts | ||
| id: issue_se_too_many_alerts |
There was a problem hiding this comment.
common root causes : custom scenario without blackhole.
drop the Review acquisition configuration to ensure log files aren't listed multiple times: and only keep the acquis metric review
How to resolve:
- For misconfigured scenarios -> disable or tune faulty scenarios
| --- | ||
| title: Security Engine Offline | ||
| id: issue_security_engine_offline | ||
| id: issue_se_offline |
There was a problem hiding this comment.
- Enrollment revoked or pending: Engine enrollment was removed from the Console or is awaiting approval. -> not possible
- Enrollment revoked or pending -> kill
- Console connectivity issues -> add cscli capi status
- Re-enroll the engine in the Console -> kill
| title: Engine No Alerts | ||
| id: issue_engine_no_alerts | ||
| title: Security Engine No Alerts | ||
| id: issue_se_no_alerts |
There was a problem hiding this comment.
root causes:
- Events massively whitelisted: ie. traffic coming from private IPs and being discarded by default allowlists.
Evaluate your service activity level:
- suggest to check for massive allowlists/whitelists hits
Check if proactive defenses are blocking threats upstream -> kill
troubleshoot: suggest a cscli explain to ensure logs are not dropped by allowlists/whitelists
| --- | ||
| title: Log Processor Offline | ||
| id: issue_log_processor_offline | ||
| id: issue_lp_offline |
There was a problem hiding this comment.
Look for errors -> too specific errors, jsut tell the user to look at the output
Also verify the API endpoint in /etc/crowdsec/config.yaml -> kill, too specific
Test network connectivity: -> kill, too specific
If the Local API service is unavailable + If the central LAPI is unreachable from the agent -> doublon ?
| --- | ||
|
|
||
| The **LP No Logs Read** issue appears when a Log Processor is running but hasn't acquired any log lines in the last 24 hours. This is the first step in the detection pipeline and must work for CrowdSec to function. | ||
| The **Log Processor No Logs Read** issue appears when a Log Processor is running but hasn't acquired any log lines in the last 24 hours. This is the first step in the detection pipeline and must work for CrowdSec to function. |
There was a problem hiding this comment.
How to Resolve -> maybe too much details
If CrowdSec can't read log files: -> hallucination on user crowdsec, it doesn't exist
| @@ -1,9 +1,9 @@ | |||
| --- | |||
| title: LP No Logs Parsed | |||
| title: Log Processor No Logs Parsed | |||
There was a problem hiding this comment.
sudo cscli collections search nginx -> hallucination
Most services have a collection that includes parsers and scenarios: -> send the user to the hub
Option 1: Adjust log format to match parser -> danger. Point the user to cscli explain or suggest him to use stock logs.
Common Parser FILTER Values -> too specific
FOR ALL link the user to PS $$$
| ### If no logs are being read | ||
|
|
||
| Follow the [LP No Logs Read troubleshooting guide](/u/troubleshooting/issue_lp_no_logs_read) for detailed steps. | ||
| Follow the [Log Processor No Logs Read troubleshooting guide](/u/troubleshooting/issue_lp_no_logs_read) for detailed steps. |
There was a problem hiding this comment.
Identify the affected Log Processor -> already indicated by yhe console
FOR ALL NO ALERTS LP/SE : point to healthcheck scenarios
| --- | ||
|
|
||
| The **RC Integration Offline** (Remediation Component Integration Offline) refers to a Blocklist-Integration of type Remediation Component has not pulled from its endpoint for more than 24 hours. | ||
| The **Remediation Component Integration Offline** refers to a Blocklist-Integration of type Remediation Component has not pulled from its endpoint for more than 24 hours. |
There was a problem hiding this comment.
Bouncer not loaded: Bouncer Module/plugin is installed but not enabled or started. -> no doublon
For host-based processes: too detailed
Standalone daemon bouncers -> too detailed, send the user to the dedicated bouncer page
For web server modules -> too detailed
If the API URL or API key is incorrect, update the bouncer's configuration file: -> too detailed
Enable the module/plugin -> too detailed
--- hallu
module not loaded - Integration not enabled in web server
invalid configuration - Config file syntax or parameter errors
rate limit exceeded - Cloud service plan limits reached
| title: Firewall Integration Offline | ||
| id: issue_fw_integration_offline | ||
| id: issue_integration_fw_offline | ||
| --- |
There was a problem hiding this comment.
// a few lines describe generic ways for them to check their firewall is workin and can ping https://admin.api.crowdsec.net/ -> rephrase c'est les notes pour le LLM
Navigate to the external blocklist configuration section (varies by vendor) -> too detailed on the submenus
Common log locations by vendor: Path to logs may vary depending on your firewall version, check your documentation. -> too detailed
No description provided.