We will explore a fundamental configuration of the AppSec Component, emphasizing a rule set dedicated to virtual patching.
Virtual patching rules focus on preventing the exploitation of well-known vulnerabilities and are a great way to deter and slow down someone scanning your web application.
The following configuration is crafted to offer the best ROI for your web application firewall!
To have a functional AppSec Component, you need:
- Crowdsec security engine >= 1.5.6
- One of the compatible bouncers:
Before diving into the practical steps, it's crucial to familiarize yourself with the core configuration aspects of the AppSec Component:
- acquisition configuration: Specifies how to acquire the AppSec Component stream of data
- AppSec Component configuration: Tells which rules are loaded in inband (blocking) and out-of-band (non-blocking) phases, and allows tweaking the behavior of the component via the powerful expr bindings.
- rules allow writing a signature to detect and/or block malevolent requests.
With that covered, let's jump into the installation.
In the following sections, we'll start with retrieving items from the CrowdSec hub to have a base to work on and then customize them.
Initialize AppSec configuration and rules
As often in CrowdSec, the relevant pieces of configuration can be acquired by installing a collection.
We are going to use a collection targeting vulnerabilities that are popular and might be exploited by bad actors trying to break into your server:
cscli collections install crowdsecurity/appsec-virtual-patching
This collection provides you:
- The config for the AppSec Component (
- All our virtual patching rules
- The CrowdSec Parser for AppSec
- The CrowdSec Scenario(s) for AppSec
Configure the AppSec Component acquisition
The AppSec Component acts as a data source, sending request data to the security engine. We'll connect this data source using an acquisition file, just like we do with other data sources.
This can be done by editing
/etc/crowdsec/acquis.yaml or adding a new YAML file in
For this type of data-source we'll declare the address and port through which the AppSec Component will communicate with the security engine to relay request data and get the verdict.
The important lines are:
listen_addrthat indicates on which interface/port the service listens to
appsec_configis the configuration name that the AppSec Component will use. For this example, we're employing
crowdsecurity/virtual-patchingthat we obtained from the hub, but feel free to create and name your own configuration. You can locate them in
mkdir -p /etc/crowdsec/acquis.d
cat > /etc/crowdsec/acquis.d/appsec.yaml << EOF
We'll then restart CrowdSec:
systemctl restart crowdsec
And you should be able to see CrowdSec starting the AppSec Component in the logs (
INFO[2023-12-05 09:16:31] 1 appsec runner to start type=appsec
INFO[2023-12-05 09:16:31] Starting Appsec server on 127.0.0.1:7422/ type=appsec
INFO[2023-12-05 09:16:31] Appsec Runner ready to process event type=appsec uuid=3b80fefe-6665-4f81-8567-a2a7f09a706a
As well as actively listening on the specified port:
# netstat -laputen | grep 7422
tcp 0 0 127.0.0.1:7422 0.0.0.0:* LISTEN 0 6923691 779516/crowdsec
Configuration : Remediation component
At the time of writing, only the crowdsec nginx bouncer supports native integration with the AppSec Component, and requires version >= X.Y.Z.
To enable the integration, you simply have to add a
APPSEC_URL parameter to the existing bouncer remediation configuration:
Note: Some remediation components might have different parameter name for the APPSEC_URL, directly check their documentation if APPSEC_URL doesn't work
In your bouncer config file:
Add the communication URL with the port you want:
⚠️ The remediation component uses the same API key for both AppSec and LAPI communication.
Make sure your bouncer has a valid API and is properly connected to the LAPI via
sudo cscli metrics⚠️
We can now restart our remediation component:
sudo systemctl restart nginx
Making sure everything works
For testing purposes, let's trigger a rule that is part of the Virtual Patching Collection:
It is trivial, for example, let's trigger the rule for
CVE-2023-42793 by trying to access an URI that ends with
▶ curl -I localhost/rpc2
HTTP/1.1 403 Forbidden
Server: nginx/1.18.0 (Ubuntu)
Date: Tue, 05 Dec 2023 14:26:03 GMT
And if we look at it in a browser, the user is presented with the HTML page emitted by the remediation component (that can be customized):
Et Voila !
Your application should now be protected from the most common exploitation attempts.
If you have already enrolled your instance in the console, you will see alerts appearing there too!