Slashdot Mirror


OWASP ModSecurity Core Rule Set Version 3.0 Released (modsecurity.org)

Need a new set of generic attack detection rules for your web application firewall? Try the new OWASP ModSecurity Core Rule Set version 3.0.0! Long-time Slashdot reader dune73 writes: The OWASP CRS is a widely-used Open Source set of generic rules designed to protect users against threats like the OWASP Top 10. The rule set is most often deployed in conjunction with an existing Web Application Firewall like ModSecurity. Four years in the making, this release comes with dozens of new features including reduced false positives (by over 90% in the default setup), improved detection of SQLi, XSS, RCE and PHP injections, the introduction of a Paranoia Mode which allows assigning a certain security level to a site, and better documentation that takes the pain out of ModSecurity.
There's rumors this new rule set is even being made into a movie

17 comments

  1. Correct me if I'm wrong... by Anonymous Coward · · Score: 1

    ...but this is for lazy people who want bathe in false sense of security. Build proper code with proper firewalling and separation of different systems and data and you'll be fine.

    1. Re:Correct me if I'm wrong... by Gavagai80 · · Score: 2

      It's for web hosts and other people running code they didn't write -- in other words, the 99.998% of websites that aren't custom-built from scratch. Unfortunately, the false positives are a major headache which make me loathe modsecurity.

      --
      This space intentionally left blank
    2. Re:Correct me if I'm wrong... by bill_mcgonigle · · Score: 2, Insightful

      false sense of security. Build proper code

      Oh, the irony.

      "Proper code?" Do tell me about your stunning insights into software security engineering.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    3. Re:Correct me if I'm wrong... by dune73 · · Score: 1

      The ModSec Core Rule Set 3.0 (CRS3) comes with a reduction of at least 90% of false positives (more like 99% on my servers). Time to give it another go.

    4. Re:Correct me if I'm wrong... by Anonymous Coward · · Score: 0

      Could you tell us again why exactly we should have a 3rd party protecting us against shellshock, a bash bug over 2 years old? Or why should we have something like this protecting us against SQL injections in a world where any sane person would use prepared statements? Why should we outsource geo IP blocking to this instead of a proper dedicated firewall, or why should we geo IP block as a security measure any way when it's obviously easy as anything to circumvented by any serious hacker? Why should we let this do web server ID masking instead of properly configuring the web server directly (not that it matters any way if you do any half-assed analysis on your targets)?

      What you get with this is indeed a false sense of security and further complication of your server environment. Not to mention all the false positives it gives you.

    5. Re: Correct me if I'm wrong... by Anonymous Coward · · Score: 0

      Stop replying to yourself.

    6. Re:Correct me if I'm wrong... by Gavagai80 · · Score: 1

      I worked out all issues with the core rule set in my scripts a long time ago anyway. The big problem is that some web hosts use more than just the core rule set, and when I don't know in advance where people are going to install my scripts it's quite hard to develop for unpredictable random rules that a few people are using.

      --
      This space intentionally left blank
    7. Re:Correct me if I'm wrong... by Anonymous Coward · · Score: 1

      Do tell me about your stunning insights into software security engineering.

      You obviously have none if ad hominem is all you have to offer.

      Captcha: behavior

  2. False Positives mostly gone in CRS3 by dune73 · · Score: 4, Informative

    [project committer here]

    The ModSec Core Rule Set 3.0 (CRS3) comes with a reduction of at least 90% of false positives (more like 99% on my servers). The base setups of Wordpress and Drupal can be run without any FPs.

    If you see FPs with a default install of the Core Rules, please report. The idea is to have next to no FPs in the standard deployment mode.

    There is a series of tutorials, which explains the installation of ModSec, the inclusion of the Core Rule Set and the handling of False Positives (still important at higher Paranoia Levels).

  3. Naive hueristic proxies are dangerous by WaffleMonster · · Score: 1

    Bad enough these systems don't work and unnecessarily inconvenience legitimate users.

    What makes them dangerous they may be leveraged to deny access and used as a vector to mask illegitimate activities. People deploying these systems may come to incorrectly depend on them as a "solution" for the underlying systems known vulnerabilities.

    Finally placing middle boxes within trusted path exposes your system to any exploitable vulnerabilities these proxy systems may contain. Several components of the application stack used by this system have had known serious security vulnerabilities in the past.

    1. Re:Naive hueristic proxies are dangerous by dune73 · · Score: 2

      Several components of the application stack used by this system have had known serious security vulnerabilities in the past.

      Could you elaborate, please?

      The stack I see Apache/NginX/IIS + ModSecurity + Libinjection + Core Rule Set. What am I missing? Apache has certainly had it's share of weaknesses, but with ModSec the track records seems quite clean; as is the case of Libinjection and the CRS.