FWIW, you're not the only one having a lot of trouble with
Cpanel's OWASP implementation.

Setting up logrotate helps keep the modsec_audit.log under control. Here's
what I did:

1. Create a file /etc/logrotate.d/modsec_audit.log (644 root/root)
2. Give it these contents:

/usr/local/apache/logs/modsec_audit.log {
 missingok
 notifempty
 daily
 copytruncate
 compress
}

I'll probably have to add "rotate 7" or something to keep it from storing
copies forever, but for now I'm just deleting the old ones manually.

I had to increase both of these to 10000 (default was 1500):
Perl Compatible Regular Expressions Library Match Limit
Perl Compatible Regular Expressions Library Match Limit Recursion

(see WHM/Security Center/ModSecurity Configuration, then scroll to the
bottom)

I also had to disable 950901 (SQL injection) because it was blocking pretty
much every edit on my Drupal site. I hope it gets revised soon (or that I
can figure and fix the problem) because preventing SQL injection is kind of
important.

Finally, I'm seeing lots of lines like this in modsec_debug.log. Neither my
ISP or Cpanel could figure out what's causing them or whether it's a
problem. Most are on /user/register or /user/login:

4775:[18/May/2015:10:21:48 --0400]
[my.domain.tld/sid#9cf1c90][rid#a71a050][/user/register][1] Rule processing
failed.



On Sun, May 17, 2015 at 6:57 PM, <
owasp-modsecurity-core-rule-set-requ...@lists.owasp.org> wrote:

>
> Message: 1
> Date: Sun, 17 May 2015 22:56:23 -0300
> From: Guilherme Y <asiaya...@hotmail.com>
> To: Barry Pollard <barry_poll...@hotmail.com>
> Cc: "owasp-modsecurity-core-rule-set@lists.owasp.org"
>         <owasp-modsecurity-core-rule-set@lists.owasp.org>
> Subject: Re: [Owasp-modsecurity-core-rule-set] Rule 960009 generates
>         false positives from my own server IP
> Message-ID: <snt151-w887af069927c88c9ac831bb6...@phx.gbl>
> Content-Type: text/plain; charset="windows-1252"
>
> Tks so much Barry!
> Pretty much standard modsecurity install: installed from WHM, enabled
> vendor OWASP and that was it. Maybe my Centos has some oddities...
> I understood your examples as part of the flexibility, that's OK. But
> newbies like me are not very imaginative and most (like me!) need these
> examples as part of the documentation so that at least we get to know what
> are the possibilities. If it wasn't for your kind help I would be sitting
> still staring and wondering what I did wrong!
> I had Modsecurity configured to log noteworthy transactions only but just
> a while ago I found out why my modsec_audit.log was filling up so fast: I
> had a permissions issue on var/cpanel/Secdatadir folder that was
> restraining Apache httpd user to write in there. Also my Apcahe error_log
> was growing excessively because of this issue. Fixed the group/owner and it
> all worked out as it should!
> I also appreciated your suggestion of disabling 960015 and already did it.
> Thank you very much for that too.
> BTW, I have disabled the following rules:958977 - it seems to deal with
> PHP injection and I don't know if I did right to disable it, do you agree
> with this? 960015 - that one! - your suggestion worked out just right981138
> - blocks Google bot for bad IP reputation - I thought it's OK to disable,
> didn't you?981175 - blocks Google bot for bad IP reputation - I thought
> it's OK to disable, didn't you?981204 - it seems to issue a Warning from
> anomaly score and blocks our iPhone app - had to disable981242 - this
> blocks entirely one of my apps - had to disable981245 - has to do with SQL
> authentication and seems to block logins from our iPhone app - had to
> disable981246 - has to do with login SQL auth and seems to block logins
> from our iPhone app - had to disable981257 - this blocks entirely one of my
> apps - had to disable
> I did not block but found the following rules already blocked after
> installing the OWASP rules vendor (I don't have the faintest idea
> why):970901973337981205990002Any idea why this is so? Is it OK to leave
> these disabled?
> PS.: I still did not find any hint in the documentation as to where (which
> file) hits are stored. I flushed modsec_audit.log but all hits since May
> 2nd still show up at WHM/Security Center/Modsecurity Tools. If you ever
> find an answer to this, please let me know, just out of curiosity.
> Thank you again!Have a great week, live long and prosper!All the best!Luiz
>
>
>
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

Reply via email to