[Owasp-modsecurity-core-rule-set] CRS3-RC1 not working on Apache 2.2
Jens.Schleusener at t-online.de
Sun Aug 21 10:48:32 UTC 2016
> We had the first major bug report for CRS3-RC1 today.
> 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
> 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
But to get just a first impression I found your script aliases collection at
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
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"
More information about the Owasp-modsecurity-core-rule-set