AppSec Component

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!

Pre-requisites

To have a functional AppSec Component, you need:

• Crowdsec security engine >= 1.5.6
• One of the compatible bouncers:

Name	Minimum Version
nginx	1.0.6rc
openresty	1.0.1rc

Overview

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 and our collection of generic attack vectors:

cscli collections install crowdsecurity/appsec-virtual-patching
cscli collections install crowdsecurity/appsec-generic-rules

These collections provide you:

• The config for the AppSec Component (crowdsecurity/appsec-default)
• All our virtual patching rules
• The CrowdSec Parser for AppSec
• The CrowdSec Scenario(s) for AppSec

If you want to learn how to write your own rules you can check our rule writing tutorial.

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 /etc/crowdsec/acquis.d/

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_addr that indicates on which interface/port the service listens to
• appsec_config is the configuration name that the AppSec Component will use. For this example, we're employing crowdsecurity/appsec-default that we obtained from the hub, but feel free to create and name your own configuration. You can locate them in /etc/crowdsec/...

mkdir  -p /etc/crowdsec/acquis.d
cat > /etc/crowdsec/acquis.d/appsec.yaml << EOF
listen_addr: 127.0.0.1:7422
appsec_config: crowdsecurity/appsec-default
name: myAppSecComponent
source: appsec
labels:
  type: appsec
EOF

We'll then restart CrowdSec:

systemctl restart crowdsec

And you should be able to see CrowdSec starting the AppSec Component in the logs (/var/log/crowdsec.log):

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.

If you don't have the bouncer installed, do it now !

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:

/etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf

/etc/crowdsec/bouncers/crowdsec-openresty-bouncer.conf

...

Add the communication URL with the port you want:

...
APPSEC_URL=http://127.0.0.1:7422
...

⚠️ 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 /rpc2:

▶ curl -I localhost/rpc2
HTTP/1.1 403 Forbidden
Server: nginx/1.18.0 (Ubuntu)
Date: Tue, 05 Dec 2023 14:26:03 GMT
Content-Type: text/html
Connection: keep-alive

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!