You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Welcome to the interactive health check of your CrowdSec setup.
15
-
We'll guide you through a series of tests to ensure that your Security Stack is fully functional and ready to protect your services: **Detecting**, **Threat Sharing** and **Remediating**.
16
-
This guide covers cases of protecting common services such as web servers (HTTP) and SSH.
14
+
Welcome to the interactive Health-Check of your CrowdSec setup.
15
+
We'll guide you through a series of tests to ensure that your Security Stack is fully functional and ready to protect your services:
16
+
**Detecting**, **Threat Sharing** and **Remediating**.
17
+
*This guide covers cases of protecting common services such as web servers (HTTP) and SSH.*
17
18
18
-
Via a **top-down approach** we'll test the end goal of components, and then dive into detailed troubleshooting if needed.
19
+
We'll first test the final functionality of each component (top-down approach) before diving into detailed troubleshooting if issues arise.
19
20
20
21
This health check is divided into three main sections:
21
-
-[**📡 Detecting**](#-detection-checks) behaviors on your services.
22
-
-[**🔗 Connectivity**](#-crowdsec-connectivity-checks)with CrowdSec network to retrieve the community blocklist.
23
-
-[**🛡️ Protecting**](#-remediation-checks)your services by remediating alerts automatically with bouncers.
22
+
-[**📡 Detection**](#-detection-checks): Ensuring CrowdSec properly detects threats targeting your services.
23
+
-[**🔗 Connectivity**](#-crowdsec-connectivity-checks): Verifying communication with the CrowdSec network to receive the community blocklist.
24
+
-[**🛡️ Protection**](#-remediation-checks): Confirming that your bouncers automatically block threats detected by CrowdSec
24
25
25
26
* * *
26
27
27
28
## 📡 Detection checks
28
29
29
30
### *Trigger CrowdSec's test scenarios*
30
31
31
-
:::info
32
-
Check that your Security Engine properly reads and parses the logs of the services you protect.
33
-
The HTTP collection and the Linux collection contain **dummy scenarios** allowing you to prove your Security Engine works as intended, without having to do penetration tests, risking getting you banned from your own server.
34
-
:::
32
+
Let's use CrowdSec's built-in **dummy scenarios** (HTTP and Linux) to safely verify your Security Engine detects threats, without risking accidental self-blocking.
35
33
36
34
<details>
37
35
<summary>🌐 **HTTP** detection test</summary>
38
36
39
-
Let's trigger the `crowdsecurity/http-generic-test`dummy scenario by calling a *probe path* on your web server.
37
+
We'll trigger the dummy scenario `crowdsecurity/http-generic-test` by accessing a **probe path** on your web server.
40
38
41
-
1️⃣ Request your service URL with the following path: `/crowdsec-test-NtktlJHV4TfBSK3wvlhiOBnl`
39
+
1️⃣ Access your service URL with this path: `/crowdsec-test-NtktlJHV4TfBSK3wvlhiOBnl`
2️⃣ Confirm the alert has triggered for the scenario `crowdsecurity/appsec-generic-test`
82
80
<CodeBlockclassName="language-bash">sudo cscli alerts list -s crowdsecurity/appsec-generic-test</CodeBlock>
83
81
84
-
Note that this scenario has a delay of **1** minute before it can re-trigger _(blackhole parameter of the scenario)_.
82
+
**Notes:**
83
+
- This scenario can only be triggered again after a 1-minute delay.
85
84
</details>
86
85
87
86
* * *
88
87
89
88
### Were all the tests successful ?
90
89
91
-
Were all the tests related to your setup successful ?
92
-
If so, you can proceed to the next phase of the health check: [**Connectivity checks**](#crowdsec-connectivity-checks).
90
+
Were all the tests related to your setup successful?
91
+
👍 If so, you can proceed to the next phase of the health check: [**Connectivity checks**](#-crowdsec-connectivity-checks).
93
92
94
-
If not, check the troubleshooting section below
93
+
🛠️ If not, check the troubleshooting section below.
95
94
96
95
<details>
97
-
<summary>🚨**Detection Troubleshooting**</summary>
96
+
<summary>🐞**Detection Troubleshooting**</summary>
98
97
99
-
*No alerts triggered? Let's investigate: Here are some tests to identify where the issue might be.*
98
+
**No alert triggered? Let's find out why.**
100
99
101
-
If you installed **CrowdSec Security Engine** on the same **Host** as the service you want to protect, the install wizards should have automatically detected the service and installed the appropriate parsers and scenarios.
102
-
103
-
If you have non-default paths or format for your logs, or if you chose other installation methods (docker, kubernetes..), you may need to manually install the parsers and scenarios.
100
+
If you installed CrowdSec on the same **host** as the service you're protecting, it should have auto-detected it and installed the right collections of parsers and scenarios.
101
+
However, if you're using *custom log paths*, *unusual log formats*, or running in *Docker/Kubernetes*, you might need to configure some things manually.
104
102
105
-
**This troubleshooting section will help you identify the issue and guide you through the necessary steps to fix it.**
103
+
**This section will help you pinpoint the issue and walk you through how to fix it.**
106
104
107
105
<details>
108
106
<summary>Are your logs being properly read and parsed?</summary>
109
107
110
-
The acquisition and parsing aspect of CrowdSec is crucial, as it tells The Security Engine which logs to read and how to parse them. You can setup multiple datasources (files, syslog, etc.), for more details you can refer to the [datasources documentation](https://doc.crowdsec.net/docs/next/log_processor/data_sources/intro).
111
-
112
-
Let's do a Top Down check using the `cscli metrics` command to see if your logs are being read and parsed correctly.
108
+
CrowdSec needs to know what logs to read and how to interpret them.
109
+
This is handled by the acquisition configuration (log sources) and parsing (how to read them).
110
+
Multiple log sources can be defined in the acquisition(s) configuration files and they support diverse datasources (files, syslog, etc.).
111
+
For more details you can refer to the [datasources documentation](https://doc.crowdsec.net/docs/next/log_processor/data_sources/intro).
113
112
113
+
We'll look at the security engine **metrics** to see if logs are **being read** and if what's read is **parsed correctly**.
114
+
We'll do that using the `cscli metrics` command:
114
115
<CodeBlockclassName="language-bash">sudo cscli metrics show acquisition parsers</CodeBlock>
115
116
116
-
- You should see the **names of the log files/stream** configured in the acquisition files, and the number of lines parsed for each of them.
117
-
- The number of "Lines parsed" should be non-zero for each of the files you configured in the acquisition section.
118
-
- The parsers metrics show you what parsers were successfully used. Look for the name of the parsers installed for the logs you're reading
117
+
Under **Acquisition Metrics** you should see:
118
+
- The source name of the log files or streams that have been read and the number of lines read and parsed for each of them.
119
+
- If you don't see any sources or some you have configured are missing, it means that the acquisition configuration is not properly set up.
120
+
- A non zero number of "Lines parsed" is expected for each source, proving that the appropriate parser was found and used.
121
+
122
+
Under The **Parsers Metrics** you have the details of the parsers used.
0 commit comments