User-Defined Detection Rules¶
In some cases, it may prove useful to add a signature for attack detection manually or to create a so-called virtual patch. As such, Wallarm does not use regular expressions to detect attacks, but it does allow users to add additional signatures based on regular expressions.
Adding a New Detection Rule¶
To do this, you need to create the rule Create regexp-based attack indicator and fill in the fields:
-
Regular expression: regular expression (signature). If the value of the following parameter matches the expression, that request is detected as an attack. Syntax and specifics of regular expressions are described in the instructions on adding rules.
Changing the regular expression specified in the rule
Changing the regular expression specified in the existing rule of the type Create regexp-based attack indicator results in automatic deletion of the rules Disable regexp-based attack detection that use the previous expression.
To disable attack detection by a new regular expression, please create a new rule Disable regexp-based attack detection with the new regular expression specified.
-
Experimental: this flag allows you to safely check the triggering of a regular expression without blocking requests. The requests won't be blocked even when the filter node is set to the blocking mode. These requests will be considered as attacks detected by the experimental method and will be hidden from the event list by default. They can be accessed using search query
experimental attacks
. -
Attack: the type of attack that will be detected when the parameter value in the request matches the regular expression.
-
in this part of request: determines a point in the request, where the system should detect the corresponding attacks.
Options sequentally (if several) selected in in this part of request should reflect a sequence of parsers Wallarm would apply to read the required request element.
Example: Blocking All Requests with an Incorrect X-Authentication Header¶
If the following conditions take place:
-
the application is accessible at the domain example.com
-
the application uses the X-Authentication header for user authentication
-
the header format is 32 hex symbols
Then, to create a rule for rejecting incorrect format tokens:
- Go to the Rules tab
- Find the branch for
example.com/**/*.*
and click Add rule -
Select Define as an attack on the basis of a regular expression
-
Set Regex value as
[^0-9a-f]|^.{33,}$|^.{0,31}$
-
Choose
Virtual patch
as the type of Attack -
Set the point
Header X-AUTHENTICATION
- Click Create
Example: Block all requests with the class.module.classLoader.*
body parameters¶
One of the ways to exploit the 0-day vulnerability in Spring Core Framework (Spring4Shell) is to send the POST request with certain malicious payloads injected into the following body parameters:
-
class.module.classLoader.resources.context.parent.pipeline.first.pattern
-
class.module.classLoader.resources.context.parent.pipeline.first.suffix
-
class.module.classLoader.resources.context.parent.pipeline.first.directory
-
class.module.classLoader.resources.context.parent.pipeline.first.prefix
-
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat
If you use vulnerable Spring Core Framework and the Wallarm node mode is different from blocking, you can prevent vulnerability exploitation using the virtual patch. The following rule will block all requests with listed body parameters even in the monitoring and safe blocking modes:
The regular expression field value is:
(class[.]module[.]classLoader[.]resources[.]context[.]parent[.]pipeline[.]first[.])(pattern|suffix|directory|prefix|fileDateFormat)
The Wallarm node operating in the blocking mode blocks such vulnerability exploitation attempts by default.
The Spring Cloud Function component also has the active vulnerability (CVE-2022-22963). If using this component and the Wallarm node mode is different from blocking, create the virtual patch as described below.
Example: Block all requests with the CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION
header¶
The Spring Cloud Function component has the active vulnerability (CVE-2022-22963) that can be exploited by injecting malicious payloads into the CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION
or CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION
header.
If using this component and the Wallarm node mode is different from blocking, you can prevent vulnerability exploitation using the virtual patch. The following rule will block all requests containing the CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION
header:
Blocking requests with the CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION
header
This rule does not block requests with the CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION
header but NGINX drops requests with this header as invalid ones by default.
The Wallarm node operating in the blocking mode blocks such vulnerability exploitation attempts by default.
There is also the 0-day vulnerability in Spring Core Framework (Spring4Shell). Learn how to block its exploitation attempts with the reqexp-based virtual patch.
Partial Disabling of a New Detection Rule¶
If the created rule should be partially disabled for a particular branch, this can easily be done by creating the rule Disable regexp-based attack detection with the following fields:
-
Regular expression: previously created regular expressions that must be ignored.
Behavior of the rule if the regular expression was changed
Changing the regular expression specified in the existing rule of the type Create regexp-based attack indicator results in automatic deletion of the rules Disable regexp-based attack detection that use the previous expression.
To disable attack detection by a new regular expression, please create a new rule Disable regexp-based attack detection with the new regular expression specified.
-
in this part of request: indicates the parameter that requires setting up an exception.
Example: Permit an Incorrect X-Authentication Header for a Designated URL
Let's say you have a script at example.com/test.php
, and you want to change the format of the tokens for it.
To create the relevant rule:
- Go to the Rules tab
- Find or create the branch for
example.com/test.php
and click Add rule -
Choose Disable regexp-based attack detection
-
Select the regular expression that you want to disable
-
Set the point
Header X-AUTHENTICATION
- Click Create
API call to create the rule¶
To create the regexp-based attack indicator, you can call the Wallarm API directly besides using the Wallarm Console UI. Below is the examples of the corresponding API call.
The following request will create the custom attack indicator based on the regexp ^(~(44[.]33[.]22[.]11))$
.
If requests to domain MY.DOMAIN.COM
have the X-FORWARDED-FOR: 44.33.22.11
HTTP header, the Wallarm node will consider them to be scanner attacks and block attacks if the corresponding filtration mode has been set.
curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: <YOUR_TOKEN>" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}"
curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: <YOUR_TOKEN>" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}"