apachemod-security2

SecRuleEngine On seem to block PUT and DELETE requests in mod_security


I have enabled SecRuleEngine in order to implement a per IP request burst limit in apache's mod_security following this tutorial.

https://johnleach.co.uk/words/2012/05/15/rate-limiting-with-apache-and-mod-security/

After a few tests it seem to work as intended on GET and POST requests, however enabling SecRuleEngine by itself (without any rule enabled) seem to block PUT and DELETE requests. This doesn't seem to be an intended behavior.

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRuleEngine

I use Apache 2.4 with mod_security version 2, but I'm willing to drop mod_security if it happens to be a bug in it and I have an alternative for rate-limiting to it.

How can I fix the rate-limiting system with or without using mod_security ?


Solution

  • ModSecurity only blocks what it is told to block.

    My guess is that despite saying you didn’t enable any rules you included the OWASP CRS which explicitly does block those methods.

    Version 2 had the following rule in its modsecurity_crs_10_setup.conf.example config file for example:

    #
    # Set the following policy settings here and they will be propagated to the 30 rules
    # file (modsecurity_crs_30_http_policy.conf) by using macro expansion.  
    # If you run into false positves, you can adjust the settings here.
    #
    SecAction \
      "id:'900012', \
      phase:1, \
      t:none, \
      setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
      setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf|application/json', \
      setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
      setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/', \
      setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/', \
      nolog, \
      pass"
    

    As you can see only GET, HEAD, POST and OPTIONS are set as allowed methods.

    The newer version 3 has this similar config in crs-setup.conf.example:

    # HTTP methods that a client is allowed to use.
    # Default: GET HEAD POST OPTIONS
    # Example: for RESTful APIs, add the following methods: PUT PATCH DELETE
    # Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK
    #          MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK
    # Uncomment this rule to change the default.
    #SecAction \
    # "id:900200,\
    #  phase:1,\
    #  nolog,\
    #  pass,\
    #  t:none,\
    #  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS'"
    

    In both cases as subsequent rule than uses this set up to block methods like PUT and DELETE.

    Whether you are using these rules, or another rule set, ModSecurity should log WHY it is blocking a request in the Apache error log. Check that to see why it’s being blocked.