https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/index.htmlDeep dive into core CRS concepts in this chapter.Hugoen-ushttps://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-1-anomaly_scoring/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-1-anomaly_scoring/index.htmlCRS 3 is designed as an anomaly scoring rule set. This page explains what anomaly scoring is and how to use it. Overview of Anomaly Scoring Anomaly scoring, also known as “collaborative detection”, is a scoring mechanism used in CRS. It assigns a numeric score to HTTP transactions (requests and responses), representing how ‘anomalous’ they appear to be. Anomaly scores can then be used to make blocking decisions. The default CRS blocking policy, for example, is to block any transaction that meets or exceeds a defined anomaly score threshold.https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-2-paranoia_levels/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-2-paranoia_levels/index.htmlParanoia levels are an essential concept when working with CRS. This page explains the concept behind paranoia levels and how to work with them on a practical level. Introduction to Paranoia Levels The paranoia level (PL) makes it possible to define how aggressive CRS is. Paranoia level 1 (PL 1) provides a set of rules that hardly ever trigger a false alarm (ideally never, but it can happen, depending on the local setup). PL 2 provides additional rules that detect more attacks (these rules operate in addition to the PL 1 rules), but there’s a chance that the additional rules will also trigger new false alarms over perfectly legitimate HTTP requests.https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-3-false-positives-and-tuning/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-3-false-positives-and-tuning/index.htmlWhen a genuine transaction causes a rule from CRS to match in error it is described as a false positive. False positives need to be tuned away by writing rule exclusions, as this page explains. What are False Positives? CRS provides generic attack detection capabilities. A fresh CRS deployment has no awareness of the web services that may be running behind it, or the quirks of how those services work. It is possible that genuine transactions may cause some CRS rules to match in error, if the transactions happen to match one of the generic attack behaviors or patterns that are being detected. Such a match is referred to as a false positive, or false alarm.https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-4-sampling_mode/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://8192de7b.documentation-km5.pages.dev/2-how-crs-works/2-4-sampling_mode/index.htmlSampling mode makes it possible to apply CRS to a limited percentage of traffic only. This may be useful in certain scenarios when enabling CRS for the first time, as this page explains. Introduction to Sampling Mode The CRS’s sampling mode mechanism was first introduced in version 3.0.0 in 2016. Although the feature has been available since then, it’s rarely used in practice, partly due to it being one of the lesser-known features of CRS.