We are embedding the OWASP CRS in our Apache web server and eliminating false alarms.<\/p>\n
The ModSecurity Web Application Firewall, as we set up in Tutorial 6, still has barely any rules. The protection only works when you configure an additional rule set. The CRS provides generic blacklisting. This means that they inspect requests and responses for signs of attacks. The signs are often keywords or typical patterns that may be suggestive of a wide variety of attacks. This also entails false alarms (false positives<\/em>) being triggered and we have to eliminate these for a successful installation.<\/p>\n We will be working with the new major release of the CRS, CRS3; short for CRS 3.0. The official distribution comes with an INSTALL<\/em> file that does a good job explaining the setup (after all, yours truly wrote a good deal of that file), but we will tweak the process a bit to suit our needs.<\/p>\n The CRS are being developed under the umbrella of OWASP<\/em>, the Open Web Application Security Project. The rules themselves are available on GitHub<\/em> and can be downloaded via git<\/em> or with the following wget<\/em> command:<\/p>\n This unpacks the base part of the CRS in the directory The setup file allows us to tweak many different settings. It is worth a look – if only to see what is included. However, we are OK with the default settings and will not touch the file: We just make sure it is available under the new filename In Tutorial 6, where we embedded ModSecurity itself, we marked out a section for the CRS. We now add several Include<\/em> directives into this section. Specifically, four parts are added to the existing configuration. (1) The CRS base configuration, (2) a part for self-defined rule exclusions before the CRS rules. Then (3) CRS themselves as well as CRS plugins and finally a part (4) for rule exclusions after CRS.<\/p>\n The rule exclusions are directives and rules used for managing the false alarms described above. Some false alarms must be prevented before the corresponding CRS rule is loaded. Some false alarms can only be intercepted following the definition of the rule itself. But one thing at a time. Here is the new block of configuration which we will insert into the base configuration we assembled when we enabled ModSecurity:<\/p>\n The CRS comes with a base configuration file named We have the option to edit settings in that base configuration file. However, the strategy for this series of tutorials has been to define all the important things in our single Apache configuration file. We do not want to insert the complete contents of the For now, we leave the file untouched, but we take four important values out of What does that mean? The CRS works with a scoring mechanism by default. For every rule a request violates, there is a score being raised. When all the request rules have passed, the score is compared to the limit. If if hits the limit, the request is blocked. The same thing happens with the responses, where we want to avoid information leaks to the client.<\/p>\n The CRS comes in blocking mode by default. If a rule is violated and the score hits the limit, the blocking will be effective immediately. But we are not yet sure our service runs smoothly and the danger of false alarms is always there. We want to avoid unwanted blocks, so we set the threshold at a value of 10000. Rule violations score 5 points at most, so even if cumulation is possible, a request is unlikely to hit the limit. Yet, we remain in blocking mode and when we grow more confident in our configuration, we can lower the threshold gradually.<\/p>\n Then we add the definition of another two variable to this rules. And finally, we set the reporting level via The center of the previous config snippet follows the includes statement for CRS and any plugins. CRS v4 introduced an architecture for plugins. Plugins are rules with additional detection abilities or rules performing special tasks, that are not interesting for the majority of setups. We are not loading any plugins just yet, but we prepare the include directives, so we can drop plugins in the said folder in the future and have them enabled immediately.<\/p>\n The CRS include is the third in the row and it loads all files with suffix The rule files are grouped by request and response rules. We start off with an initialization rule file. There are a lot of things commented out in the Every file is dedicated to a topic or type of attack. The CRS occupies the ID namespace from 900,000 to 999,999. The three digit long numbers in the filenames correspond to the first three digits of the IDs of the rules managed within the file. This means the IP reputation rules in An important rule file is Then begin the outbound rules, which are less numerous and basically check for code leakages (stack traces!) and leakages in error messages (which give an attacker useful information to construct an SQL injection attack). The outbound score is checked in the file with the 980 prefix.<\/p>\n Some of the rules come with data files. These files have a Before and after the rules Include<\/em> directive in our Apache configuration file, there is a bit of configuration space reserved. This is where we will be handling false alarms in the future. Some of them are being treated before the rules are loaded in the configuration, some after the Include<\/em> directive. We\u2019ll return to this later in this tutorial.<\/p>\n For completeness, here is the complete Apache configuration including ModSecurity, CRS and all the other config bits from the earlier tutorials that we depend on:<\/p>\nRequirements<\/h3>\n
\n
Step 1: Downloading OWASP CRS<\/h3>\n
$> cd \/apache\/conf\n$> wget https:\/\/github.com\/coreruleset\/coreruleset\/archive\/refs\/tags\/v4.22.0.tar.gz\n$> tar -xvzf v4.22.0.tar.gz\ncoreruleset-4.22.0\ncoreruleset-4.22.0\/\ncoreruleset-4.22.0\/.github\/\ncoreruleset-4.22.0\/.github\/ISSUE_TEMPLATE.md\ncoreruleset-4.22.0\/.gitignore\ncoreruleset-4.22.0\/.gitmodules\ncoreruleset-4.22.0\/.travis.yml\ncoreruleset-4.22.0\/CHANGES\ncoreruleset-4.22.0\/IDNUMBERING\ncoreruleset-4.22.0\/INSTALL\ncoreruleset-4.22.0\/KNOWN_BUGS\ncoreruleset-4.22.0\/LICENSE\ncoreruleset-4.22.0\/README.md\ncoreruleset-4.22.0\/crs-setup.conf.example\ncoreruleset-4.22.0\/documentation\/\ncoreruleset-4.22.0\/documentation\/OWASP-CRS-Documentation\/\ncoreruleset-4.22.0\/documentation\/README\n...\n$> ln -s coreruleset-4.22.0 \/apache\/conf\/crs\n$> cp crs\/crs-setup.conf.example crs\/crs-setup.conf\n$> rm v4.22.0.tar.gz<\/code><\/pre>\n\/apache\/conf\/coreruleset-4.22.0<\/code>. We create a link from \/apache\/conf\/crs<\/code> to this folder. Then we copy a file named crs-setup.conf.example<\/code> to a new file crs-setup.conf<\/code> and finally, we delete the CRS tar file.<\/p>\ncrs-setup.conf<\/code>. Then we can continue to update the configuration to include the rules files.<\/p>\nStep 2: Embedding the CRS<\/h3>\n
<\/a># === ModSec CRS Base Configuration (ids: 900000-900999)<\/span><\/span>\n<\/a><\/span>\n<\/a>Include<\/span> \/apache\/conf\/crs\/crs-setup.conf<\/span>\n<\/a><\/span>\n<\/a>SecAction<\/span> "id:900110,phase:1,pass,nolog,\\<\/span><\/span>\n<\/a> setvar:tx.inbound_anomaly_score_threshold=10000,\\<\/span><\/span>\n<\/a> setvar:tx.outbound_anomaly_score_threshold=10000,\\<\/span><\/span>\n<\/a> setvar:tx.blocking_paranoia_level=1,\\<\/span><\/span>\n<\/a> setvar:tx.reporting_level=4"<\/span><\/span>\n<\/a><\/span>\n<\/a><\/span>\n<\/a># === ModSec CRS: Runtime Exclusion Rules (ids: 10000-49999)<\/span><\/span>\n<\/a><\/span>\n<\/a># ...<\/span><\/span>\n<\/a><\/span>\n<\/a><\/span>\n<\/a># === CRS and CRS Plugin Inclusion<\/span><\/span>\n<\/a><\/span>\n<\/a>Include<\/span> \/apache\/conf\/crs\/plugins\/*-config.conf<\/span>\n<\/a>Include<\/span> \/apache\/conf\/crs\/plugins\/*-before.conf<\/span>\n<\/a><\/span>\n<\/a>Include<\/span> \/apache\/conf\/crs\/rules\/*.conf<\/span>\n<\/a><\/span>\n<\/a>Include<\/span> \/apache\/conf\/crs\/plugins\/*-after.conf<\/span>\n<\/a><\/span>\n<\/a><\/span>\n<\/a># === ModSec CRS: Startup Time Rules Exclusions<\/span><\/span>\n<\/a><\/span>\n<\/a># ...<\/span><\/span><\/code><\/pre><\/div>\ncrs-setup.conf<\/code> which we prepared during the installation. Copying the original example file guarantees that we can update the CRS distribution without harming our copy of the config file unless we want to.<\/p>\ncrs-setup.conf<\/code> file into our configuration (but we include it) in order to get the minimal set of configuration items needed to run CRS. I do not want to dive into all the options in the settings file, but it is worth having a look at.<\/p>\ncrs-setup.conf<\/code> and define them in our config so we have them in sight at all times. We define two thresholds in the unconditional rule 900110<\/em>: The inbound anomaly score and the outbound anomaly score. This is done via the setvar<\/code> action which sets both values to 10000.<\/p>\ntx.blocking_paranoia_level<\/code>, defines the Paranoia Level<\/em> to 1. CRS rules are divided in four groups at paranoia levels 1 – 4. As the name suggests, the higher the paranoia level, the more paranoid the rules. The default is paranoia level 1, where the rules are quite sane and false alarms are rare. When you raise the PL to 2, additional rules are enabled. Starting with PL 2, you will face more and more false alarms, also called false positives. This number grows with PL3 and when you arrive at PL4, you are likely to face false alarms as though your web application firewall has become quite paranoid, so to speak. We will deal with false positives later in this tutorial, but for the moment you just need to be aware that you can control the aggressiveness of the rule set with the paranoia level setting and that PL3 and PL4 are really for advanced users with very high security needs.<\/p>\ntx.reporting_level<\/code>. The reporting level configures a reporting rule that lists a summary of CRS for a given request. CRS can write this summary for every request, also those that did not trigger any alerts, it can write the summary for those requests that did, it can write it for requests that have been blocked or it can leave out that summary report. Depening on your use case, this information can be useful, but I personally run without it (-> reporting level 0<\/code>).<\/p>\nStep 3: A closer look at the rules folder<\/h3>\n
.conf<\/code> from the rules sub folder in the CRS directory. This is where all the rules are being loaded. Let\u2019s take a look at them:<\/p>\n<\/a>$><\/span> ls<\/span> -1 crs\/rules\/*.conf<\/span>\n<\/a>crs\/rules\/REQUEST-901-INITIALIZATION.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-905-COMMON-EXCEPTIONS.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-911-METHOD-ENFORCEMENT.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-913-SCANNER-DETECTION.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-921-PROTOCOL-ATTACK.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-922-MULTIPART-ATTACK.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-930-APPLICATION-ATTACK-LFI.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-931-APPLICATION-ATTACK-RFI.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-932-APPLICATION-ATTACK-RCE.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-933-APPLICATION-ATTACK-PHP.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-934-APPLICATION-ATTACK-GENERIC.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-941-APPLICATION-ATTACK-XSS.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-944-APPLICATION-ATTACK-JAVA.conf<\/span><\/span>\n<\/a>crs\/rules\/REQUEST-949-BLOCKING-EVALUATION.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-950-DATA-LEAKAGES.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-951-DATA-LEAKAGES-SQL.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-952-DATA-LEAKAGES-JAVA.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-953-DATA-LEAKAGES-PHP.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-954-DATA-LEAKAGES-IIS.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-955-WEB-SHELLS.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-956-DATA-LEAKAGES-RUBY.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-959-BLOCKING-EVALUATION.conf<\/span><\/span>\n<\/a>crs\/rules\/RESPONSE-980-CORRELATION.conf<\/span><\/span><\/code><\/pre><\/div>\ncrs-setup.conf<\/code> file. These values are simply set to their default value in the 901 rule file. This helps keep the config neat and tidy and still have all default settings applied. Then we have two application specific rule files for WordPress and Drupal, followed by an exceptions file that is mostly irrelevant to us. Starting with 910, we have the real rules.<\/p>\nREQUEST-910-IP-REPUTATION.conf<\/code> will occupy the rule range 910,000 – 910,999. The method enforcement rules follow between 911,000 and 911,999, etc.. Some of these rule files are small and they do not use up their assigned rule range by far. Others are much bigger and the infamous SQL Injection rules run the risk of touching their ID ceiling one day.<\/p>\nREQUEST-949-BLOCKING-EVALUATION.conf<\/code>. This is where the anomaly score is checked against the inbound threshold and the request is blocked accordingly.<\/p>\n.data<\/code> extension and reside in the same folder with the rule files. Data files are typically used when the request has to be checked against a long list of keywords, like unwanted user agents or php function names. Have a look if you are interested.<\/p>\n<\/a>ServerName<\/span> localhost<\/span>\n<\/a>ServerAdmin<\/span> root@localhost<\/span>\n<\/a>ServerRoot<\/span> \/apache<\/span>\n<\/a>User<\/span> www-data<\/span>\n<\/a>Group<\/span> www-data<\/span>\n<\/a>PidFile<\/span> logs\/httpd.pid<\/span>\n<\/a><\/span>\n<\/a>ServerTokens<\/span> Prod<\/span>\n<\/a>UseCanonicalName<\/span> On<\/span>\n<\/a>TraceEnable<\/span> Off<\/span>\n