mod-security-users — General discussion about mod_security

Re: [mod-security-users] nolog rule still logs

[Christian F. <chr...@ne...>]

Hi Bren,

This is all a bit complicated. Yet there is a chance this is logged in the
audit log because the status is 403. That does not really explain the error
log though.

What engine version and which connector are you using?

Best,

Christian

On Sat, Apr 03, 2021 at 05:38:27PM +0000, Bren via mod-security-users wrote:
> Hello,
> 
> I've been working to roll out ModSecurity on Nginx (OpenResty 1.19.3.1 / nginx-1.19.3). I compiled the Nginx connector against the Debian 10 version of libmodsecurity (v3.0.3, but this happens when using v3/master as well).
> 
> Using the stock unmodified modsecurity.conf-recommended. I added this line for haproxy health checks:
> 
> SecRule REQUEST_FILENAME "/waf_health_check" "id:1000,nolog,deny"
> 
> Even with nolog this rule still logs to the audit log and the Nginx error log. I've tried every combo of options I could find to get this to stop logging but for some reason it still gets logged.
> 
> As far as I can tell from the docs, nolog should prevent this rule match from appearing in any logs. I shouldn't need anything else but this. What am I missing?
> 
> Bren
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] nolog rule still logs

[Bren <umu...@pr...>]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, April 3rd, 2021 at 11:35 PM, Ehsan Mahdavi <ehs...@gm...> wrote:
> try "id:1000,nolog,noauditlog,deny"

I tried that and:

id:1000,nolog,noauditlog,ctl:auditEngine=Off,deny

>From this ticket:

https://github.com/SpiderLabs/ModSecurity/issues/1217

And still this rule match gets logged. According to the documentation nolog should be enough (unless I'm misunderstanding) so I am not sure what's going on.

The full conf is:

# The stock recommended conf
Include /etc/openresty/modsecurity/modsecurity.conf
SecRule REQUEST_FILENAME "/waf_health_check" "id:1000,nolog,deny"

This is what's getting logged:

---XlVYmBXD---A--
[04/Apr/2021:12:40:35 -0400] 161755443589.343274 127.0.0.1 4502 127.0.0.1 8504
---XlVYmBXD---B--
HEAD /waf_health_check HTTP/1.0
content-length: 0

---XlVYmBXD---D--

---XlVYmBXD---F--
HTTP/1.0 403

---XlVYmBXD---H--

---XlVYmBXD---I--

---XlVYmBXD---J--

---XlVYmBXD---Z--

This is the only thing I've tried so far that stops this line from getting logged:

SecAuditLogRelevantStatus "^(?:5|4(?!04|03))"

But I want other 403s to be logged of course.

Re: [mod-security-users] nolog rule still logs

[Ehsan M. <ehs...@gm...>]

Hi
try "id:1000,nolog,noauditlog,deny"

On Sat, Apr 3, 2021 at 10:12 PM Bren via mod-security-users <
mod...@li...> wrote:

> Hello,
>
> I've been working to roll out ModSecurity on Nginx (OpenResty 1.19.3.1 /
> nginx-1.19.3). I compiled the Nginx connector against the Debian 10 version
> of libmodsecurity (v3.0.3, but this happens when using v3/master as well).
>
> Using the stock unmodified modsecurity.conf-recommended. I added this line
> for haproxy health checks:
>
> SecRule REQUEST_FILENAME "/waf_health_check" "id:1000,nolog,deny"
>
> Even with nolog this rule still logs to the audit log and the Nginx error
> log. I've tried every combo of options I could find to get this to stop
> logging but for some reason it still gets logged.
>
> As far as I can tell from the docs, nolog should prevent this rule match
> from appearing in any logs. I shouldn't need anything else but this. What
> am I missing?
>
> Bren
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>


-- 
                    regards
                 Ehsan.Mahdavi
PhD candidated for Computer Engineering
    by Isfahan University of Technology
        http://emahdavi.ece.iut.ac.ir/

[mod-security-users] nolog rule still logs

[Bren <umu...@pr...>]

Hello,

I've been working to roll out ModSecurity on Nginx (OpenResty 1.19.3.1 / nginx-1.19.3). I compiled the Nginx connector against the Debian 10 version of libmodsecurity (v3.0.3, but this happens when using v3/master as well).

Using the stock unmodified modsecurity.conf-recommended. I added this line for haproxy health checks:

SecRule REQUEST_FILENAME "/waf_health_check" "id:1000,nolog,deny"

Even with nolog this rule still logs to the audit log and the Nginx error log. I've tried every combo of options I could find to get this to stop logging but for some reason it still gets logged.

As far as I can tell from the docs, nolog should prevent this rule match from appearing in any logs. I shouldn't need anything else but this. What am I missing?

Bren

Re: [mod-security-users] mlogc-ng

[Christian V. <cv...@it...>]

Hi Blason.

I haven’t used mlogc-ng, but I use “filebeat" to send logs to ELK.

this link might guide you.
https://logit.io/sources/configure/apache

Cheers.
Chris.

> On sábado, mar. 27, 2021 at 1:55 a. m., Blason R <bla...@gm... (mailto:bla...@gm...)> wrote:
> Hi Team,
>
> I am really having difficulty in finding any documents for mlogc-ng binary. Can anyone guide me about the official documentation for configuring mlogc-ng?
>
> My scenario is I have 2 nginx-reverse proxy protecting around 20 web sites with modsec 3.0.4 and generating audit.log in nginx format in their individual directory under /var/log/nginx.
>
> I am planning to use ELK stack for analyzing the logs can someone please suggest the setup and strategy?
>
> TIA
> Blason R
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

[mod-security-users] mlogc-ng

[Blason R <bla...@gm...>]

Hi Team,

I am really having difficulty in finding any documents for mlogc-ng binary.
Can anyone guide me about the official documentation for configuring
mlogc-ng?

My scenario is I have 2 nginx-reverse proxy protecting around 20 web sites
with modsec 3.0.4 and generating audit.log in nginx format in their
individual directory under /var/log/nginx.

I am planning to use ELK stack for analyzing the logs can someone please
suggest the setup and strategy?

TIA
Blason R

[mod-security-users] ModSecurity and Envoy

[Osama E. <oel...@gm...>]

Hi,

Is anyone on this mailing list currently using ModSecurity on Envoy? I'm
currently running Istio/Kubernetes and the defalut Ingress gateway is
Envoy. I could change it to something like nginx but that would result in
losing some of Istio's functionality.

If so, what was your impression compared to the more traditional
ModSecurity/Apache or ModSecurity/nginx? Was the performance comparable?
Are the instructions here - https://github.com/octarinesec/ModSecurity-envoy -
still applicable for newer versions of Envoy?

Thanks

-- 
Osama Elnaggar

Re: [mod-security-users] modsecurity on http-https redirect on apache

[Franz A. <fra...@gm...>]

Hi Christian,

i moved redirect to .htaccess file and all working fine now...

Yes i think ModSec in this way filter before Apache, thanks!

Franz

Il giorno gio 18 mar 2021 alle ore 09:10 Christian Folini
<chr...@ne...> ha scritto:
>
> Hey Franz,
>
> ModSec works in multiple phases and the redirect is relatively early. In
> fact Mod_rewrite works in two phases IIRC and here it is faster than ModSec.
> The rule in question runs in phase 2 and that's relatively late.
>
> You have 3 options:
> - Forget about it. I mean who cares since the attack can not affect you due
>   to the redirect anyways.
> - Implement the redirect in ModSecurity in ModSec phase 2 after the Core Rule
>   Set include. (-> custom rule)
> - Move the Redirect into the VH or potentially into the container if that
>   is possible (have not done this in years). That might force apache to
>   execute it later and ModSec comes first. But you need to test this.
>
> Best,
>
> Christian
>
> On Thu, Mar 18, 2021 at 08:54:18AM +0100, Franz Angeli wrote:
> > Hi,
> >
> > Sorry but i'm new on modsecurity, i've installed a Debian apache
> > server with modsecurity with no custom rules for testing/learning.
> >
> > If i try to use:
> >
> > curl https://www.example.test/index.html?exec=/bin/bash
> >
> > all working fine with:
> >
> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> > <html><head>
> > <title>403 Forbidden</title>
> > </head><body>
> > <h1>Forbidden</h1>
> > <p>You don't have permission to access this resource.</p>
> > </body></html>
> >
> > and on modsecurity log:
> >
> > Message: Warning. Matched phrase "bin/bash" at ARGS:exec. [file
> > "/etc/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"]
> > [line "518"] [id "932160"] [msg "Remote Command Execution: Unix Shell
> > Code Found"] [data "Matched
> >
> >
> > on the same server i've configured a simple http to https redirection
> > Redirect / https://www.example.test/
> >
> > with redirect the same test fail:
> >
> > redirects acts before modsecurity? How can i solve this?
> >
> > Thanks in advance
> >
> > Franz
> >
> >
> > _______________________________________________
> > mod-security-users mailing list
> > mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] modsecurity on http-https redirect on apache

[Blason R <bla...@gm...>]

This should not be the case at all. I am running at least 15 sites with
nginx as reverse proxy and apache as virtual host and all that works
perfectly fine.
However I am offloading my https traffic on my nginx server and then
inspecting it only then clean traffic is sent to my backend apache server.

Though I am stil on PL1 and figuring out how the rule chain works and
understanding lot other concepts
like Anomaly mode
PL levels
Phase

etc...

On Thu, Mar 18, 2021 at 4:48 PM logo <lo...@kr...> wrote:

> Hi Franz,
>
> Am 18.03.2021 um 09:07 schrieb Christian Folini <
> chr...@ne...>:
>
> Hey Franz,
>
> ModSec works in multiple phases and the redirect is relatively early. In
> fact Mod_rewrite works in two phases IIRC and here it is faster than
> ModSec.
> The rule in question runs in phase 2 and that's relatively late.
>
> You have 3 options:
> - Forget about it. I mean who cares since the attack can not affect you due
>  to the redirect anyways.
> - Implement the redirect in ModSecurity in ModSec phase 2 after the Core
> Rule
>  Set include. (-> custom rule)
> - Move the Redirect into the VH or potentially into the container if that
>  is possible (have not done this in years). That might force apache to
>  execute it later and ModSec comes first. But you need to test this.
>
> Best,
>
> Christian
>
> On Thu, Mar 18, 2021 at 08:54:18AM +0100, Franz Angeli wrote:
>
> Hi,
>
> Sorry but i'm new on modsecurity, i've installed a Debian apache
> server with modsecurity with no custom rules for testing/learning.
>
> If i try to use:
>
> curl https://www.example.test/index.html?exec=/bin/bash
>
>
> is this to https or http?
>
> all working fine with:
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>403 Forbidden</title>
> </head><body>
> <h1>Forbidden</h1>
> <p>You don't have permission to access this resource.</p>
> </body></html>
>
> and on modsecurity log:
>
> Message: Warning. Matched phrase "bin/bash" at ARGS:exec. [file
> "/etc/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"]
> [line "518"] [id "932160"] [msg "Remote Command Execution: Unix Shell
> Code Found"] [data "Matched
>
>
>
>
> on the same server i've configured a simple http to https redirection
> Redirect / https://www.example.test/
>
> with redirect the same test fail:
>
> redirects acts before modsecurity? How can i solve this?
>
>
> if I understood you correctly, the request is also not blocked when you
> arrive in the site after the redirect (on https?) ?
>
> If that is the case, are you enabling Modsecurity globally or only in one
> VirtualHost? In latter case, you have to also set SecRuleEngine On in the
> https virtualHost (or even add the whole config there).
>
> HTH
>
> Peter
>
>
> Thanks in advance
>
> Franz
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

Re: [mod-security-users] modsecurity on http-https redirect on apache

[logo <lo...@kr...>]

Hi Franz,

> Am 18.03.2021 um 09:07 schrieb Christian Folini <chr...@ne...>:
> 
> Hey Franz,
> 
> ModSec works in multiple phases and the redirect is relatively early. In 
> fact Mod_rewrite works in two phases IIRC and here it is faster than ModSec. 
> The rule in question runs in phase 2 and that's relatively late.
> 
> You have 3 options:
> - Forget about it. I mean who cares since the attack can not affect you due
>  to the redirect anyways.
> - Implement the redirect in ModSecurity in ModSec phase 2 after the Core Rule
>  Set include. (-> custom rule)
> - Move the Redirect into the VH or potentially into the container if that
>  is possible (have not done this in years). That might force apache to
>  execute it later and ModSec comes first. But you need to test this.
> 
> Best,
> 
> Christian
> 
> On Thu, Mar 18, 2021 at 08:54:18AM +0100, Franz Angeli wrote:
>> Hi,
>> 
>> Sorry but i'm new on modsecurity, i've installed a Debian apache
>> server with modsecurity with no custom rules for testing/learning.
>> 
>> If i try to use:
>> 
>> curl https://www.example.test/index.html?exec=/bin/bash
>> 

is this to https or http?

>> all working fine with:
>> 
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <html><head>
>> <title>403 Forbidden</title>
>> </head><body>
>> <h1>Forbidden</h1>
>> <p>You don't have permission to access this resource.</p>
>> </body></html>
>> 
>> and on modsecurity log:
>> 
>> Message: Warning. Matched phrase "bin/bash" at ARGS:exec. [file
>> "/etc/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"]
>> [line "518"] [id "932160"] [msg "Remote Command Execution: Unix Shell
>> Code Found"] [data "Matched
>> 


>> 
>> on the same server i've configured a simple http to https redirection
>> Redirect / https://www.example.test/
>> 
>> with redirect the same test fail:
>> 
>> redirects acts before modsecurity? How can i solve this?
>> 

if I understood you correctly, the request is also not blocked when you arrive in the site after the redirect (on https?) ?

If that is the case, are you enabling Modsecurity globally or only in one VirtualHost? In latter case, you have to also set SecRuleEngine On in the https virtualHost (or even add the whole config there).

HTH

Peter


>> Thanks in advance
>> 
>> Franz
>> 
>> 
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>> http://www.modsecurity.org/projects/commercial/rules/
>> http://www.modsecurity.org/projects/commercial/support/
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] modsecurity on http-https redirect on apache

[Christian F. <chr...@ne...>]

Hey Franz,

ModSec works in multiple phases and the redirect is relatively early. In 
fact Mod_rewrite works in two phases IIRC and here it is faster than ModSec. 
The rule in question runs in phase 2 and that's relatively late.

You have 3 options:
- Forget about it. I mean who cares since the attack can not affect you due
  to the redirect anyways.
- Implement the redirect in ModSecurity in ModSec phase 2 after the Core Rule
  Set include. (-> custom rule)
- Move the Redirect into the VH or potentially into the container if that
  is possible (have not done this in years). That might force apache to
  execute it later and ModSec comes first. But you need to test this.

Best,

Christian

On Thu, Mar 18, 2021 at 08:54:18AM +0100, Franz Angeli wrote:
> Hi,
> 
> Sorry but i'm new on modsecurity, i've installed a Debian apache
> server with modsecurity with no custom rules for testing/learning.
> 
> If i try to use:
> 
> curl https://www.example.test/index.html?exec=/bin/bash
> 
> all working fine with:
> 
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>403 Forbidden</title>
> </head><body>
> <h1>Forbidden</h1>
> <p>You don't have permission to access this resource.</p>
> </body></html>
> 
> and on modsecurity log:
> 
> Message: Warning. Matched phrase "bin/bash" at ARGS:exec. [file
> "/etc/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"]
> [line "518"] [id "932160"] [msg "Remote Command Execution: Unix Shell
> Code Found"] [data "Matched
> 
> 
> on the same server i've configured a simple http to https redirection
> Redirect / https://www.example.test/
> 
> with redirect the same test fail:
> 
> redirects acts before modsecurity? How can i solve this?
> 
> Thanks in advance
> 
> Franz
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

[mod-security-users] modsecurity on http-https redirect on apache

[Franz A. <fra...@gm...>]

Hi,

Sorry but i'm new on modsecurity, i've installed a Debian apache
server with modsecurity with no custom rules for testing/learning.

If i try to use:

curl https://www.example.test/index.html?exec=/bin/bash

all working fine with:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>

and on modsecurity log:

Message: Warning. Matched phrase "bin/bash" at ARGS:exec. [file
"/etc/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"]
[line "518"] [id "932160"] [msg "Remote Command Execution: Unix Shell
Code Found"] [data "Matched


on the same server i've configured a simple http to https redirection
Redirect / https://www.example.test/

with redirect the same test fail:

redirects acts before modsecurity? How can i solve this?

Thanks in advance

Franz

Re: [mod-security-users] Custom 403 error Message

[Blason R <bla...@gm...>]

Excellent - Thanks a lot man :)

On Fri, Mar 12, 2021 at 9:24 PM Christian Varas via mod-security-users <
mod...@li...> wrote:

> you can have custom error pages in nginx.
> have a look:
> https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-to-use-custom-error-pages-on-ubuntu-14-04
>
>
> Cheers.
> Chris.
>
>
>
> On viernes, mar. 12, 2021 at 5:15 a. m., Blason R <bla...@gm...>
> wrote:
> Hi Team,
>
> I tried searching a lot but most of the time I found this functionality
> can only be achieved using Apache.but not with nginx.
>
> Is it really possible to display custome 403 error messages with a nginx
> as a reverse proxy mode instead of default nginx 403 Forbidden message?
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

Re: [mod-security-users] Custom 403 error Message

[Christian V. <cv...@it...>]

you can have custom error pages in nginx.
have a look: https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-to-use-custom-error-pages-on-ubuntu-14-04

Cheers.
Chris.

> On viernes, mar. 12, 2021 at 5:15 a. m., Blason R <bla...@gm... (mailto:bla...@gm...)> wrote:
> Hi Team,
>
> I tried searching a lot but most of the time I found this functionality can only be achieved using Apache.but not with nginx.
>
> Is it really possible to display custome 403 error messages with a nginx as a reverse proxy mode instead of default nginx 403 Forbidden message?
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

[mod-security-users] Custom 403 error Message

[Blason R <bla...@gm...>]

Hi Team,

I tried searching a lot but most of the time I found this functionality can
only be achieved using Apache.but not with nginx.

Is it really possible to display custome 403 error messages with a nginx as
a reverse proxy mode instead of default nginx 403 Forbidden message?

Re: [mod-security-users] remove

[Reindl H. <h.r...@th...>]

ok, writing "remove" as response to a random thread is even more stupid 
as send "unsubscribe" to a random mailing-list

how do you imagine that any of the other susbcribers could do that for you?

https://lists.sourceforge.net/lists/listinfo/mod-security-users is at 
the bottom of every single message and there you have "Click here to 
unsubscribe or change settings"

there are also mail-headers in every single list-message on planet earth

List-Id: <mod-security-users.lists.sourceforge.net>
List-Unsubscribe:
  <https://lists.sourceforge.net/lists/options/mod-security-users>,
 
<mailto:mod...@li...?subject=unsubscribe>
List-Archive:
 
<http://sourceforge.net/mailarchive/forum.php?forum_name=mod-security-users>
List-Post: <mailto:mod...@li...>
List-Help:
  <mailto:mod...@li...?subject=help>
List-Subscribe:
  <https://lists.sourceforge.net/lists/listinfo/mod-security-users>,
 
<mailto:mod...@li...?subject=subscribe>

Am 11.03.21 um 19:22 schrieb Dolev Pony:
> בכבוד רב
> 
> דולב פוני
> 
> מנכ"ל
> 
> 2all Systems LTD
> 
> 052-2802851
> 
> 077-2700300
> 
> https://web.2all.co.il <https://web.2all.co.il>
> 
> *From:*Blason R [mailto:bla...@gm...]
> *Sent:* Thursday, March 11, 2021 7:37 PM
> *To:* mod...@li...
> *Subject:* Re: [mod-security-users] Logrotate file for Ubuntu
> 
> Thanks guys!!!
> 
> On Thu, Mar 11, 2021 at 4:19 PM Andrew Howe 
> <and...@lo... <mailto:and...@lo...>> wrote:
> 
>     Hi Blason,
> 
>     You could try using the copytruncate option, which negates the need to
>     reload Apache by leaving the original log file in place.
> 
>     As an example, we use the following configuration to rotate audit logs:
> 
>     /var/log/httpd/modsec_audit*.log {
>              copytruncate
>              weekly
>              rotate 12
>              size 20M
>              create 0640 root root
>     }
> 
>     Just another idea you could test :)
> 
>     Thanks,
>     Andrew
> 
>     -- 
> 
>     Andrew Howe
>     Loadbalancer.org Ltd.
>     www.loadbalancer.org <http://www.loadbalancer.org>
>     +1 888 867 9504 / +44 (0)330 380 1064
> 
> 
>     _______________________________________________
>     mod-security-users mailing list
>     mod...@li...
>     <mailto:mod...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mod-security-users
>     <https://lists.sourceforge.net/lists/listinfo/mod-security-users>
>     Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>     http://www.modsecurity.org/projects/commercial/rules/
>     <http://www.modsecurity.org/projects/commercial/rules/>
>     http://www.modsecurity.org/projects/commercial/support/
>     <http://www.modsecurity.org/projects/commercial/support/>
> 
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

[mod-security-users] remove

[Dolev P. <ad...@2a...>]

 

 

בכבוד רב

דולב פוני

מנכ"ל 

2all Systems LTD

052-2802851

077-2700300

 <https://web.2all.co.il> https://web.2all.co.il

 

From: Blason R [mailto:bla...@gm...] 
Sent: Thursday, March 11, 2021 7:37 PM
To: mod...@li...
Subject: Re: [mod-security-users] Logrotate file for Ubuntu

 

Thanks guys!!!

 

On Thu, Mar 11, 2021 at 4:19 PM Andrew Howe <and...@lo... <mailto:and...@lo...> > wrote:

Hi Blason,

You could try using the copytruncate option, which negates the need to
reload Apache by leaving the original log file in place.

As an example, we use the following configuration to rotate audit logs:

/var/log/httpd/modsec_audit*.log {
        copytruncate
        weekly
        rotate 12
        size 20M
        create 0640 root root
}

Just another idea you could test :)

Thanks,
Andrew

-- 

Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org <http://www.loadbalancer.org> 
+1 888 867 9504 / +44 (0)330 380 1064


_______________________________________________
mod-security-users mailing list
mod...@li... <mailto:mod...@li...> 
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] Logrotate file for Ubuntu

[Blason R <bla...@gm...>]

Thanks guys!!!

On Thu, Mar 11, 2021 at 4:19 PM Andrew Howe <and...@lo...>
wrote:

> Hi Blason,
>
> You could try using the copytruncate option, which negates the need to
> reload Apache by leaving the original log file in place.
>
> As an example, we use the following configuration to rotate audit logs:
>
> /var/log/httpd/modsec_audit*.log {
>         copytruncate
>         weekly
>         rotate 12
>         size 20M
>         create 0640 root root
> }
>
> Just another idea you could test :)
>
> Thanks,
> Andrew
>
> --
>
> Andrew Howe
> Loadbalancer.org Ltd.
> www.loadbalancer.org
> +1 888 867 9504 / +44 (0)330 380 1064
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>

Re: [mod-security-users] Logrotate file for Ubuntu

[Christian V. <cv...@it...>]

+1
I use this method (copytruncate) and works without issues

Cheers.
Chris.

> On jueves, mar. 11, 2021 at 7:45 a. m., Andrew Howe <and...@lo... (mailto:and...@lo...)> wrote:
> Hi Blason,
>
> You could try using the copytruncate option, which negates the need to
> reload Apache by leaving the original log file in place.
>
> As an example, we use the following configuration to rotate audit logs:
>
> /var/log/httpd/modsec_audit*.log {
> copytruncate
> weekly
> rotate 12
> size 20M
> create 0640 root root
> }
>
> Just another idea you could test :)
>
> Thanks,
> Andrew
>
> --
>
> Andrew Howe
> Loadbalancer.org Ltd.
> www.loadbalancer.org
> +1 888 867 9504 / +44 (0)330 380 1064
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] Logrotate file for Ubuntu

[Andrew H. <and...@lo...>]

Hi Blason,

You could try using the copytruncate option, which negates the need to
reload Apache by leaving the original log file in place.

As an example, we use the following configuration to rotate audit logs:

/var/log/httpd/modsec_audit*.log {
        copytruncate
        weekly
        rotate 12
        size 20M
        create 0640 root root
}

Just another idea you could test :)

Thanks,
Andrew

-- 

Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064

Re: [mod-security-users] Logrotate file for Ubuntu

[Christian F. <chr...@ne...>]

On Thu, Mar 11, 2021 at 08:26:22AM +0100, Ervin Hegedüs wrote:
> so it looks like the option "size" overwrites the "daily".

I was puzzled by that as well...

Christian



> 
> hth,
> 
> 
> a.
>  
> 
> 
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] Logrotate file for Ubuntu

[Christian F. <chr...@ne...>]

Hey Blason,

If on Apache, then you need to reload the server config to instruct
the server to open the logfiles anew. I used to do this inside the
curly brackets, IIRC.

Regs,

Christian

On Thu, Mar 11, 2021 at 09:39:15AM +0530, Blason R wrote:
> Hi Team,
> 
> Somehow my logroate with Ubuntu 20.04 is not working for modsec audit log
> and still a single file is being filled with the logs.
> 
> Am I doing anything wrong?
> 
> more /etc/logrotate.d/modsec_audit
> /var/log/modsec_audit.log {
> su root root
> daily
> rotate 7
> *size 10M*
> missingok
> compress
> delaycompress
> }
> 
> I want the files to be rotated every day
> 
> ls -larth /var/log/modsec*
> -rw-r--r-- 1 root root 887K Mar 10 13:54 /var/log/modsec_audit.log.2.gz
> -rw-r--r-- 1 root root    0 Mar 11 00:00 /var/log/modsec_audit.log
> -rw-r--r-- 1 root root  *36M* Mar 11 08:12 /var/log/modsec_audit.log.1


> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

Re: [mod-security-users] Logrotate file for Ubuntu

[Ervin H. <ai...@gm...>]

Hi Blason,

On Thu, Mar 11, 2021 at 09:39:15AM +0530, Blason R wrote:
> Hi Team,
> 
> Somehow my logroate with Ubuntu 20.04 is not working for modsec audit log
> and still a single file is being filled with the logs.
> 
> Am I doing anything wrong?

from the manual of logrotate:

     size size
              Log files are rotated *only* if they grow bigger than size bytes.

> more /etc/logrotate.d/modsec_audit
> /var/log/modsec_audit.log {
> su root root
> daily
> rotate 7
> *size 10M*
> missingok
> compress
> delaycompress
> }
> 
> I want the files to be rotated every day

so it looks like the option "size" overwrites the "daily".

hth,


a.
 

[mod-security-users] Logrotate file for Ubuntu

[Blason R <bla...@gm...>]

Hi Team,

Somehow my logroate with Ubuntu 20.04 is not working for modsec audit log
and still a single file is being filled with the logs.

Am I doing anything wrong?

more /etc/logrotate.d/modsec_audit
/var/log/modsec_audit.log {
su root root
daily
rotate 7
*size 10M*
missingok
compress
delaycompress
}

I want the files to be rotated every day

ls -larth /var/log/modsec*
-rw-r--r-- 1 root root 887K Mar 10 13:54 /var/log/modsec_audit.log.2.gz
-rw-r--r-- 1 root root    0 Mar 11 00:00 /var/log/modsec_audit.log
-rw-r--r-- 1 root root  *36M* Mar 11 08:12 /var/log/modsec_audit.log.1

Re: [mod-security-users] Paranoia level

[Blason R <bla...@gm...>]

Thanks for heads up - but I am still confused and would take this up with
offline.
Though this is not the correct forum I might not spam this list.

On Wed, Mar 10, 2021 at 12:46 PM Christian Folini <
chr...@ne...> wrote:

> Hey Blason,
>
> On Wed, Mar 10, 2021 at 11:21:14AM +0530, Blason R wrote:
> > I am really looking at everywhere but unable to find the exact
> information.
> > I am struggling to find how do I increase Paranoia level gradually?
> > I really dont see settings in configuration or might have overlooked? but
> > can someone can help me understanding the procedure?
>
> You have probably overlooked the explanation it in crs-setup.conf.
>
> There are two values involved:
>
> - tx.paranoia_level
>   This is the PL that we are going to block in. We thought about renaming
>   this to tx.blocking_paranoia_level, but then we thought it would have
>   been too cumbersome on the users.
> - tx.executing_paranoia_level
>   This is the PL of the rules that we are going to execute. It is greater
>   or equal to tx.paranoia_level.
>
> So with these two settings, you can block on PL1, but execute PL2, tune
> away
> the false positives of PL2 and then raise the blocking PL to 2 as well.
> And then to the next step.
>
> The advantage of this process is that without the executing PL setting, you
> would dive into a higher PL without knowing the new false positives in
> advance and you would probably have to raise the anomaly threshold for
> a certain transition period, thus lowering your defenses. The introduction
> of the execution paranoia level allows you to keep the defenses up.
>
> Cheers,
>
> Christian
>
>
> --
> Seek simplicity, and distrust it.
> -- Alfred North Whitehead
>
>
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>