[Owasp-modsecurity-core-rule-set] CRS3-RC1 not working on Apache 2.2
Jens.Schleusener at t-online.de
Mon Aug 22 09:39:59 UTC 2016
> Good morning Jens,
> On Sun, Aug 21, 2016 at 12:48:32PM +0200, Jens Schleusener wrote:
>> 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
>> very useful.
> Thanks. I should probably cover them in a blogpost. Right now they seem
> to be a bit of a secret to those who have read my (German) tutorials.
>> 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!).
> Glad it works!
>> 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
> I guess you are aware of the alias 'sucs' and use the sort-uniq-c-sort
> combination here to make it more comprehensive for the other readers.
A "small" yes (but I wanted to reverse the sort order for this post) and
there is for e.g. also a related alias "melmsgs" in your collection that
does it all with a single command.
>> 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
> All in all, this is quite a big collection of alerts for 200K requests.
> Your site is special of course, but would this special content really
> affect the requests that much. Would not that be more a problem with
> the responses?
Sure, for e.g. if valued as meaningful the server tries to display a
requested HTML member file of an available software package in rendered
format but that leads sometimes to the mentioned errors like
105 932130 Remote Command Execution: Unix Shell Expression Found
if for e.g. that file includes stylesheets like
But that was the case only for one member file of one package that caused
all that 105 matches.
> There are a rules which point to a real positive. But with many others,
> we might face false positives. Did you investigate further, or do you
> think they point to malign requests?
As said that is very laborious if there hundred of entries. Often one had
to analyze additionally the big Apache access log to find out the further
behaviour of an suspicious IP and classify the according requests as
"good" or "bad".
Helpful would be a general program or script that can grep blocks of lines
given a main target pattern and two further patterns specifying the begin
and the end of the block. I just write a very primitive one that allows
for e.g. via
grep_blocks_by_sed -p 'id "921140"' \
-b '^--[0-9a-f]*-A--' -e '^--[0-9a-f]*-Z--' modsec_audit.log
to extract all matching blocks related to a special rule ID (the number
of matches can be restricted by an option "-n N") and filter them
So I found now that the 347 entries
347 921140 HTTP Header Injection Attack via headers
belongs all to a single IP (probably a proxy) that adds to the end of the
User-Agent header field a "\x0d".
Also all the 59 entries
59 920430 HTTP protocol version is not allowed by policy
are caused by a single client/bot (User-Agent: Java/1.6.0_04) that seems
to have misinterpreted responses of previously requested URLs and
requested now invalid URLs that the CRS3 rule seems to assign to the HTTP
>> 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).
> Would you please be so kind and open an issue on the github site for
> this false positive? Ideally including a full audit log entry for the
Ok (but a little bit later).
More information about the Owasp-modsecurity-core-rule-set