The Open Web Application Security Project® (OWASP) is an umbrella organization with several projects under its wings. The OWASP ModSecurity Core Rule Set (shortened to CRS) is one of its flagship projects. CRS is a set of generic attack detection rules for use with ModSecurity or compatible Web Application Firewall (WAF). The Core Rule Set aims to protect web applications from a wide range of security risks with a minimum of false positives. This includes those described by the OWASP Top Ten.
The Core Rule Set runs on top of the extremely popular ModSecurity WAF engine. The ModSecurity engine allows administrators to write their own rules or rely on well-known commercial offerings from Atomicorp, Comoro, or Trustwave Spiderlabs. Unlike the commercial offerings, the OWASP CRS are more generic in nature and cover a much larger set of applications from a broader attack surface. This means that the OWASP CRS protects you from generic attacks rather than individual-specific known exploits. For example, there are not rules for all known SQL injection attacks but a small set of rules protecting your application from any attack that looks like an SQL injection attack. This provides significantly enhanced coverage for Zero Day and other unknown attacks.
It is this generic approach that has made the CRS one of the most popular WAF rule sets on the internet. Its installation account for over 100 TBit/s of traffic is being protected around the globe. We achieved this with the help of big integrators: Amazon AWS, Microsoft Azure, Google Cloud, Verizon Media, Akamai, Cloudflare, Fastly, etc. they all have a CRS offering of some sort. So, Kemp is in very good company when it puts the priority on delivering you a LoadMaster with a pre-installed ModSecurity / CRS web application firewall.
The most striking benefit is, that a generic SQL injection rule will protect you from new and unknown SQL injections as well – or at least with a very high probability. That means you do not always have to rush when a new exploit comes out or a new CVE is being published. For full protection, Kemp recommends that the application security updates are applied as recommended by the application owner.
Chances are that CRS has you covered, and you have time to upgrade / patch your software. That means ModSecurity and CRS serve as the first line of defence that buys you time and good sleep. No surprise, being the “1st Line of Defence” is also the CRS motto.
Now don’t get lazy and forget about security! This is no silver bullet. But CRS removes the noise from your traffic and blocks most security scans and all the blatant HTTP attacks. This lets you concentrate on the real enemies of your internet presence. Tuning is key. And that is perhaps the main difference with the commercial and more exploit-oriented rule sets: the generic approach comes with false positives. Even in the default installation where we really, really try to avoid them. This phenomenon of false positives brings a need to tune away the false alarms.
The generic nature of CRS allows the installation to come with relatively few rules: around 200 depending on the exact configuration. Compare this with the thousands of rules of the commercial offerings named above. This points in the direction of a profound speed and configuration advantage, since it’s very hard to remain on top of 200 rules, let alone 5,000. I have talked about generic rules, but how does that work in practice? Here is an example: Rule 942430 checks for special characters in a parameter submitted via HTTP. Anything with a dozen or more special characters is considered an attack by this rule. It does not know anything about web-based attacks; it knows very well that a benign parameter rarely contains 12 special characters. 12 special characters and this rule smells like a rat. 942430 is a strong rule that has stopped a lot of attacks.
Yet of course, the limit of 12 special chars is very arbitrary. It really depends on your security appetite or how much you are willing to invest into the tuning of the rule set. If you want to configure a higher security level than the default installation, then you can raise the so-called paranoia level. This enables additional rules. Among these rules is a sibling of 942430. This sibling has the same idea, but it sets the limit to eight specials characters. And then there is even another sibling that sets the limit to two.
Naturally, the higher you set your paranoia level, the more false positives you will get; false alarms if you want. False positives are the price you must pay for getting a tighter security posture via higher paranoia level setting. It’s like keeping a mad dog: Such a dog makes it more and more difficult for burglars to enter your house. But you better keep your dog in check when the pizza guy rings on the door.
The paranoia level setting is an important, but it is not the most critical feature of CRS. That feature is the anomaly scoring. Anomaly scoring means, that CRS does not block a request immediately. Instead, it separates the detection from the blocking decision. When a rule triggers because it has encountered a specific pattern in a request, it raises the anomaly score of the request. A separate rule that runs will then check the total anomaly score. That separate rule performs the blocking decision based on the anomaly threshold.
This may sound overly complicated, but it adds a lot of flexibility to the CRS operation. New installations can get a very high threshold for starters – and therefore run with blocking mode enabled from the very beginning. And then you slide down the anomaly mode threshold over several iterations while keeping an eye on the false positives and the benign requests.
With a rule set that blocks immediately (like the commercial rule offerings referenced), you must run in monitoring mode until you are 100% sure everything is perfect. You do this while you wait for the big day where you go into blocking mode. And that day never comes for many web application installations.
With the anomaly scoring, there is a more gradual approach. You start in blocking mode from day one and then you get tighter and tighter as you learn more about your system and manage to tune away the false positives. In Kemp’s latest release they have included valuable enhancements from their previous WAF implementation resulting in an enhanced experience for administrators of the LoadMaster WAF.
Now that we have introduced the basic background on the Core Rule Set, next week we will demonstrate some practical examples these enhancements and the value that the Core Rule Set brings when running them on the LoadMaster.
If you are currently looking at utilizing Web Application Firewall (WAF), make sure to check out theKemp WAF here…
Part 1: Introduction to OWASP CRSPart 2: How do you run OWASP CRS on load master Part 3: Deploying custom rulesPart 4: False Positive AnalysisPart 5: Reporting