[Owasp-modsecurity-core-rule-set] CRS3-RC1 not working on Apache 2.2

Jens Schleusener Jens.Schleusener at t-online.de
Sun Aug 21 10:48:32 UTC 2016


Hi Christian,

> We had the first major bug report for CRS3-RC1 today.
> https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/542
>
> The maximum line length of Apache 2.2 is too short for two of the
> new Remote Command Execution rules which come in at over 10K bytes.
>
> Expect a fix on github in the next few days; certainly for RC2.
>
> Meanwhile Apache 2.4 is doing great and github user @emphazer who
> discovered this bug reports of over 100 production machines running
> CRS3-RC1.
>
> But the list here has remained silent over the release. I see several
> possible reasons:
> - Nobody gives a shit
> - It fails so miserably on your server you removed it immediately and
>  you do not want to talk about CRS anymore
> - It worked like a charm without any false positives, so you forgot
>  about its existence instantly.
>
> Either way, some feedback would be nice. This is an opensource project.
> Chaim and Walter worked day and night for this, and if not even the
> project mailinglist has some positive or negative feedback, then I
> wonder why anybody is doing this at all.

One reason for the "silence" may be also the very laborious log file 
analysis.

But to get just a first impression I found your script aliases collection at

  https://github.com/Apache-Labor/labor/blob/master/bin/.apache-modsec.alias

very useful.

On the server that I manage (httpd 2.4.23, modsecurity 2.9.1) CRS3-RC1 is 
now for nearly a month in use and it works very well (big thanks to the 
CRS3 team!). Although the server may be not "typical" since it uses itself 
neither PHP nor SQL but offers amongst others soure code browsing of FOSS 
software that contains for e.g. PHP, SQL and HTML files here an example 
output for 5 days (with roughly 200.000 page requests in total) using the 
script alias "melidmsg" (entries fom some special self-written rules are 
removed):

cat modsec_audit.log.16081[5-9] | melidmsg | sort | uniq -c | sort -nr

     347 921140 HTTP Header Injection Attack via headers
     308 910000 Request from Known Malicious Client
                (Based on previous traffic violations).
     186 920350 Host header is a numeric IP address
     105 932130 Remote Command Execution: Unix Shell Expression Found
      73 920210 Multiple/Conflicting Connection Header Data Found.
      59 920430 HTTP protocol version is not allowed by policy
      50 920220 URL Encoding Abuse Attack Attempt
      48 930110 Path Traversal Attack (/../)
      43 911100 Method is not allowed by policy
      37 942100 SQL Injection Attack Detected via libinjection
      30 941130 XSS Filter - Category 3: Attribute Vector
      22 920170 GET or HEAD Request with Body Content.
      12 920330 Empty User Agent Header
       9 920280 Request Missing a Host Header
       8 933160 PHP Injection Attack: High-Risk PHP Function Call Found
       8 913100 Found User-Agent associated with security scanner
       5 933100 PHP Injection Attack: Opening/Closing Tag Found
       1 942140 SQL Injection Attack: Common DB Names Detected
       1 941120 XSS Filter - Category 2: Event Handler Vector
       1 941100 XSS Attack Detected via libinjection
       1 933130 PHP Injection Attack: Variables Found
       1 932100 Remote Command Execution: Unix Command Injection
       1 930100 Path Traversal Attack (/../)
       1 920180 POST request missing Content-Length Header.
       1 913110 Found request header associated with security scanner

The rules 920300, 920310, 920320, 920440 and 933150 are deactivated and 
the variable tx.inbound_anomaly_score_threshold was increased to 6 
(default 5) to avoid some FPs (sometimes probably caused just by a "long" 
Google Referer string?). The so CRS3-unmatched bad requests are hopefully 
already matched by other specific Apache configuration rules (using the 
mod_rewrite module) that are implemented on that server.

The rule 920210 ("Multiple/Conflicting Connection Header Data Found") in 
some cases seems to cause FPs (especially for the User-Agent 
"Go-http-client/1.1" that sends erroneously a "Connection: close, close" 
HTTP header).

Regards

Jens


More information about the Owasp-modsecurity-core-rule-set mailing list