<rss version="2.0"><channel><title>Logging on CRS Project</title><link>https://c6efa5fb.website-1u6.pages.dev/tags/logging/</link><description>Recent content in CRS Project</description><item><title>Logging with OWASP CRS, Part 1: What Your WAF Is Telling You</title><link>https://c6efa5fb.website-1u6.pages.dev/20261103/crs-logging-part-1-what-your-waf-is-telling-you/</link><pubDate>Tue, 03 Nov 2026 09:00:00 -0300</pubDate><description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This is the first of a three part series on logging with OWASP CRS:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Part 1 (this post):&lt;/strong&gt; 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.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Part 2:&lt;/strong&gt; ModSecurity, with the logs shipped to the Elastic Stack (Logstash, Elasticsearch, Kibana) and a ready made dashboard.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Part 3:&lt;/strong&gt; Coraza, with the logs shipped to Grafana and Loki through Alloy, and the same dashboard.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;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&amp;rsquo;s own container images and the same CRS release. Part 2 runs &lt;code&gt;owasp/modsecurity-crs&lt;/code&gt;, NGINX with ModSecurity v3 (libmodsecurity). Part 3 runs &lt;code&gt;coraza-crs&lt;/code&gt;, Caddy with &lt;a href="https://coraza.io/"&gt;Coraza&lt;/a&gt;. 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.&lt;/p&gt;</description></item><item><title>The Top 5 Ways CRS Can Help You Fight the OWASP Top 10</title><link>https://c6efa5fb.website-1u6.pages.dev/20171121/top-5-ways-crs-can-help-you-fight-owasp-top-10/</link><pubDate>Tue, 21 Nov 2017 16:36:31 +0100</pubDate><description>&lt;p&gt;The new edition &lt;a href="https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010-2017%20%28en%29.pdf"&gt;OWASP Top Ten&lt;/a&gt; list mentions &lt;a href="https://www.modsecurity.org"&gt;ModSecurity&lt;/a&gt; and the &lt;a href="https://coreruleset.org"&gt;OWASP ModSecurity Core Rule Set&lt;/a&gt; for the first time.&lt;/p&gt;
&lt;p&gt;Let me explain you what the Core Rule Set does and how it can help you protect your services from these risks.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item></channel></rss>