Logging with OWASP CRS, Part 1: What Your WAF Is Telling You
A web application firewall produces exactly one thing you can hold in your hands: logs. Blocking is a side effect of a rule matching; the log line is the record that it happened, why, and what the request looked like. If nobody reads those logs, the WAF is a very expensive way to return 403s. This is the first of a three part series on logging with OWASP CRS: Part 1 (this post): what ModSecurity and CRS write to disk, how to read it, what to look for, and the two small additions we recommend before you ship a single line to a log platform. Part 2: ModSecurity, with the logs shipped to the Elastic Stack (Logstash, Elasticsearch, Kibana) and a ready made dashboard. Part 3: Coraza, with the logs shipped to Grafana and Loki through Alloy, and the same dashboard. Parts 2 and 3 come with Docker Compose stacks you can run locally in a few minutes. Each post has its files attached, and a zip with all of them at the end. Both use the CRS project’s own container images and the same CRS release. Part 2 runs owasp/modsecurity-crs, NGINX with ModSecurity v3 (libmodsecurity). Part 3 runs coraza-crs, Caddy with Coraza. The examples in this post come from ModSecurity v3; most of it applies to ModSecurity v2 on Apache and to Coraza as well, and where the engines differ, we say so.
The CRS Plugin Mechanism
Plugins are not part of the CRS 3.3.x release line. They will be released officially with the next major CRS release 4.x. In the meantime, you can use them with one of the stable releases by following the instructions below. What are Plugins? Plugins are sets of additional rules that you can plug in to your web application firewall in order to expand CRS with complementary functionality or to interact with CRS. Rule exclusion plugins are a special case: these are plugins that disable certain rules to integrate CRS into a context that is otherwise likely to trigger certain false alarms.
Disabling Request Body Access in ModSecurity 3 Leads to Complete Bypass
If you are running ModSecurity 3 with request body access disabled, then I have some bad news. Please sit down, this will be a while. If you are running ModSecurity 2, or you give the engine access to the request body, then you are not affected. But maybe you want to read this post nevertheless. I’ll be discussing a new ModSec3 vulnerability an upcoming new CRS feature and some fundamental problems affecting existing ModSecurity rule sets.
CVE-2020-15598 - ModSecurity v3 Affected By DoS (Severity HIGH)
The OWASP ModSecurity Core Rule Set (CRS) team has identified a Denial of Service vulnerability in the underlying ModSecurity engine. This affects all releases in the ModSecurity v3 release line. The vendor Trustwave Spiderlabs did not release an update yet. However, we are providing users with a patch for ModSecurity and a workaround if they can not patch. Likewise, we are coordinating the patching with the Linux distributors. This blog post tries to give you a comprehensive overview of the problem with all the resources you need to cope with the situation.
CVE-2019-19886 - HIGH - DoS against libModSecurity 3
The ModSecurity 3.0.x release line suffers from a Denial of Service vulnerability after triggering a segmentation fault on the webserver when parsing a malformed cookie header. All users of ModSecurity 3.0.0 - 3.0.3 should update to ModSecurity 3.0.4 as soon as possible. ModSecurity 2.x is not affected. The CVSS score for the vulnerability is 7.5 (HIGH). MITRE lists the vulnerability as CVE-2019-19886 (but as of this writing, it is only reserved). The OWASP ModSecurity Core Rule Set (CRS) project makes heavy use of unit tests. One of the goals is making sure that all our rules behave as intended on the underlying ModSecurity engine. ModSecurity 2.9 on Apache is our reference platform that passes our expanding list of over 2300 tests.
Core Rule Set Project Won a German OSBAR Award!
The OWASP ModSecurity Core Rule Set Project is very excited about winning one of the OSBAR awards of the German Open Source Business Alliance. The prize is awarded to projects, start-ups and outstanding ideas from the open source environment. The increased attention should make it easier for the award winners to attract users, developers and supporters. CRS hackers Christian Folini and Franziska Bühler with the OSBAR award trophy (photo Fridolin Zurlinden)
The Top 5 Ways CRS Can Help You Fight the OWASP Top 10
The new edition OWASP Top Ten list mentions ModSecurity and the OWASP ModSecurity Core Rule Set for the first time. Let me explain you what the Core Rule Set does and how it can help you protect your services from these risks. The CRS - short for OWASP ModSecurity Core Rule Set - is a set of generic attack detection rules. They are meant for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks with a minimum of false alerts. The Core Rule Set is thus meant as a 1st line of defense against web application attacks as described by the OWASP Top Ten.