How to Use C-Rex in the Browser
Quick start guide
C-Rex is a graphical user interface for a popular tool that creates rule exclusions based on rule alert messages. You paste a rule alert into the text area on top, C-Rex processes the alert and presents you with a rule exclusion. You can then refine the rule exclusion to your needs via several controls or even edit the result by hand, before you copy it into your configuration.
It’s pretty much self-explanatory, really.
If you are not familiar with the concept of rule exclusions or with the web application firewall rules that lead to the alerts C-Rex is dealing with, then it’s probably a good moment to read through the ModSecurity / CRS tutorials on the netnea website, namely the tutorial number 6 and the tutorial number 7.
The tutorials mention a Rule Exclusion Cheat Sheet This is a summary of the different rule exclusion options you have and C-Rex implements the cheatsheet almost 1:1. It’s actually better than the cheat sheet, but we’ll leave this for the slower walk through.
The slower walk-through
C-Rex helps when dealing with false positives. False positives are false alarms that ModSecurity rules like the Core Rule Set rules create. Handling false positives usually means to instruct the WAF to ignore or skip certain rules in certain situations. This can mean to forget a rule completely, or to skip a certain parameter, when evaluating an individual rule.
Writing rule exclusions can be tedious and error-prone, namely for the more complex forms of rule exclusions that try to reduce the security impact of skipping a rule by adopting to the context.
We have developed a cheat sheet to help you writing rule exclusions.
And C-Rex is the application that implements the cheat sheet in a GUI. This may sound simple enough, but it’s really helpful.
The alert area
When starting C-Rex, you are greeted with the startup screen with an empty textarea labelled as “Input”.
This is where you paste the individual ModSecurity alert message.
As an alternative to the pasting of alert messages into this screen, it is also possible to open C-Rex with the alert message as a parameter. See the developer / integrator infos for more information about this option.
The parsed message
Once you paste an alert message into the text area, C-Rex processes the input, parses the various items and displays them for your reference. It displays the individual tokens it has read as “Parsed Log Message”. Immediately visible are the rule ID and the message of the rule. The other items can be displayed by clicking on the “expand” symbol next to the label.
Here is the full list of items that C-Rex reports.
| Label | Description |
|---|---|
| Id | ModSecurity rule ID (with paranoia level) |
| Msg | Message of the rule |
| Timestamp | Timestamp of the rule alert |
| Request ID | Unique ID of the request on the webserver |
| Remote IP | Source IP address as visible in the log file |
| Data | Additional data logged by the rule |
| Hostname | Hostname of the HTTP server |
| URI | The URI of the request |
| Parameter | Parameter that triggered the alert |
| Tags | Tags of the rule |
| File | Name of the file containing the rule |
| Line | Line in the file containing the rule |
| Version | Version of the rule according to the log file |
And this is how it looks like in the user interface:
The excludator
Beneath the parse log comes an area names “Configure Rule”. This is where you can tweak the rule exclusion. The most important part is the big custom widget on the left, that lets you pick one option in a 2:2 matrix, the “Excludator”.
The two options on the left are startup rule exclusions. This means that a rule is excluded the moment the web application firewall starts or loads / reloads its configuration. On the right are the two runtime rule exclusions. They happen when the request comes in and the URI path can be taken into consideration. That means they are context sensitive, which makes them hard to write (when compared to the startup rule exclusions).
The two rule exclusion options in the upper row exclude a complete rule or group of rules, the ones in the lower row excludes a rule (or group of rules) for a given parameter.
This gives you four options:
- Top Left: Startup rule exclusion
- Bottom Left: Startup rule exclusion for a given parameter
- Top Right: Runtime rule exclusion for a given URI
- Bottom Right: Runtime rule exclusion for a given URI for a given parameter
These four canonical rule exclusion types are not the only ones possible in ModSecurity, but we have found them to be the ones that can be applied in almost any situation.
Next to the Excludator you find another important option. It lets you choose between an individual rule to be excluded or a tag. CRS rules are all tagged and many of the tags form groups. So instead of excluding an individual rule, you can also remove a tag of rules. Make your selection by sliding the button between the two options.
When you pick the By-Tag option, a new selector opens that lets you select the tag you are interested in. Not all the tags make sense and it pays to look through the rules to understand which tags really matter.
Finally, you can pick a rule ID if you have selected a runtime rule exclusion. Startup time rule exclusions don’t come with a rule ID thanks to the way they are implemented in the ModSecurity engine. But with runtime rule exclusions, a rule ID is mandatory. As you probably know, the rule ID has to be unique per ModSecurity instance, so you really need a to pay attentiom us keep note of them.
The rule ID is saved between calls to C-Rex and you can also pass it as a parameter, when jumping into the application.
The rule exclusion
In the final part of the user interface, C-Rex displays the rule exclusion it created with your help. You can edit the rule exclusion by hand and you can of course copy it and paste it into your application.
There is one additional customization option near “Result” it allows you to include Metainformation into the rule, or rather the comment that comes with the rule. It is a good practice to include this information. It can help you verify if a certain rule exclusion is still needed in the future.
The Advisories
For a handful of rules, C-Rex does not propose a rule exclusion. These are rules, where a rule exclusion does not make sense. With most of them, it is better to change the configuration instead. E.g. when a parameter is too big, it’s better to adjust the size limit than to exclude the rule.
In these cases, C-Rex does not show you the Excludator to tweak with your rule, but it shows you an advisory that tells you what to do. Advisories exist for rule alerts triggered by CRS.
See below at Appendix I: The 4 States: State 3: Advisory for a list of all the advisories in C-Rex.
Appendix I: The 4 States
The C-Rex application is a single screen application. Yet the screen knows four different states.
State 1: Startup screen
The startup screen is mostly empty with a large text area where you can paste the rule alert you are interested to write a rule exclusion for.
State 2: Successful entry
This is the standard use case for C-Rex. The alert message has been pasted and you can now proceed to configure the exact rule exclusion that you would like to obtain.
This screen is explained in detail in the section “A slower walk-through”.
State 3: Advisory
There are alerts, where a rule exclusion does not make sense. In these situations it is better to change a configuration variable instead. In order cases a rule exclusion could destroy the correct working of the rule set (and the alert is not the false positive at the core of the issue).
In all these situations, C-Rex displays an advisory instead of the “Successful entry” workflow.
The following advisories exist:
| Rule ID | Message / Description |
|---|---|
| 920360 | Argument name too long |
| 920370 | Argument name too long |
| 920380 | Too many arguments in request |
| 920390 | Total arguments size exceeded |
| 920400 | Uploaded file size too large |
| 920410 | Total uploaded files size too large |
| 920420 | Request content type is not allowed by policy |
| 920430 | HTTP protocol version is not allowed by policy |
| 920440 | URL file extension is restricted by policy |
| 920450 | HTTP header is restricted by policy |
| 920480 | Request content type charset is not allowed by policy |
| 949110 | Inbound Anomaly Score Exceeded |
| 949111 | Inbound Anomaly Score Exceeded in phase 1 |
| 959100 | Outbound Anomaly Score Exceeded |
| 980130 | Inbound Anomaly Score Exceeded |
State 4: Could not parse alert - the error page
This is the error message that is being displayed when the alert message could not be read. Additionally, C-Rex displays a few example alert messages that are known to parse successfully.
