mod-security-users — General discussion about mod_security

Re: [mod-security-users] Using 'deprecatevar' on multiple variables in a collection

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

Hi,

I wanted to follow up with some further investigation into this.
Hopefully, these findings may help someone else in a similar scenario
in the future.

I ended up going through ModSecurity's (2.x) source to confirm how the
'deprecatevar' action works. Looking at re_actions.c confirmed my
suspicion: all variables in a given persistent collection are tied to
a *single timestamp* (LAST_UPDATE_TIME) for the purposes of
calculating their deprecation. This can cause strange behaviour when
deprecatevar is used on multiple variables in the same collection.

I've written a full explanation about this in a blog post, which can
be found here: https://www.loadbalancer.org/blog/modsecurity-and-the-case-of-the-never-decreasing-variables/

I've also written a Lua script which I'm using to work around this
issue. The script has been published to GitHub, here:
https://github.com/loadbalancer-org/modsec_decrement_script

If nothing else, this was a fun opportunity to spend time poking
around ModSecurity's source code :)

Thanks,
Andrew

-- 
Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org

Re: [mod-security-users] CRS Issues being automatically closed?

[Bill S. <bi...@go...>]

Christian,
Thank you for the explanation.

On Mon, Jan 11, 2021, 1:22 AM Christian Folini <chr...@ne...>
wrote:

> Hey Jamie,
>
> This is the mailing list for the ModSecurity engine. The CRS project has a
> separate mailinglist over at
>
> https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project
>
> But let me answer your question nevertheless:
>
> You are correct and this configuration to close stale issues after 120
> days is
> offensive. And we did not take it lightly. We have been struggling with not
> being able to address all the issues for years. We tried different methods,
> scheduling, assigning, highlighting, inviting the wider community to help,
> tagging as "#goodfirstissue" etc.  But it did not bring a real solution:
> The
> issues pile up and new issues (also vital ones!) can end up buried under a
> pile that is too big to plough through.
>
> As most open source projects, CRS is a volunteer driven project. People
> work
> on CRS because they want to work on CRS. Some steal time from their
> companies
> to do so, some put their children to bed to hack away. But it is always
> time
> that our developers give to the project freely. I as a co-leader of the
> project can not force issues into their hands. All I can do is making CRS a
> fun project to work with and prepare the environment in a way that makes
> it easy and cool to work on CRS.
>
> And the huge pile of issues started to have a chilling effect on
> developers or
> new developers. There is a moment where the pile is so big, you are not
> even
> addressing what you can address because of all the rest. Looking at the
> 36 issues open right now feels managable and most issues are being
> addressed.
> (You can tell easily, since most open issues do have a conversation
> history.)
>
> So we talked about the step a big deal and we took the decision about a
> year
> ago.  Ultimately it was a decision to pick between the goodwill and health
> of
> the developers and the goodwill of individual users. I am really not happy
> with the way it is and I have a new plan to help us address all the issues
> before they get stale. But it is not quite ready to share.
>
> What can you do: If you care about an issue, then comment on it. We read
> every
> comment on every issue. If get the notice that the issue has been tagged
> for
> removal (the tag "Stale issue" is being applied 2 weeks or so before it
> gets
> closed), then comment on the issue and tell us you still care. Also
> multiple
> users chiming in give an issue priority in our eyes. We currently do an
> issue
> chat once a month (3rd Monday every month), where we look into 5-10 open
> issues. One way to make sure an issue makes it into that meeting is the tag
> "Meeting agenda". Ask us to add this tag and we will take it on the list.
>
> All in all, using the services of the stale issue bot is not a sign that
> we do
> not care. Quite the opposite. We care a lot and we feel bad about using the
> stale issue bot. But it was the only solution we saw.
>
> Hope this explains our reasoning a bit.
>
> Best regards and thanks for speaking up,
>
> Christian Folini, CRS Co-Lead
>
>
>
>
>
>
> On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote:
> > Hi CRS Team
> >
> > I'm disappointed to see that issues I'm reporting (FPs) (e.g.
> > https://github.com/coreruleset/coreruleset/issues/1864) are being
> > automatically closed by stalebot. I fully understand that there may not
> be
> > the time nor the resources to address issues reported, and I know why
> > stalebot exists, but I don't think rule issues that people have spent
> time
> > looking at and reporting should be closed before they are actually
> > addressed. It certainly doesn't encourage me to continue reporting them
> > moving forward.
> >
> > Cheers, Jamie
>
>
> > _______________________________________________
> > 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] CRS Issues being automatically closed?

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

Hello Jamie,

On Mon, Jan 11, 2021 at 12:10:03PM -0000, Jamie Burchell wrote:
> Thanks for the response and apologise for posting in the incorrect list.

No worries.

> Great to see there is things in development to address this.
> 
> I just wanted to re-iterate that the issue I raise is not one of
> expectation for anyone to look at the issues reported (in their spare time
> or otherwise) - I fully understand your points here. Rather, I would just
> prefer to see current issues not automatically closed and buried.

Ah. Thanks. We're full of guilt already, so my reaction tends to be a bit
on the defensive side when it comes to this topic.

The issues are not gone, they are just a bit hidden. But I have now added a
link to a query that lets you filter for them on github. The link is in our
README and also on the coreruleset.org website. I think we should have added
this before and also documented the process much earlier. Thanks for pointing
it out.

Cheers,

Christian


> 
> Best Regards,
> Jamie
> 
> -----Original Message-----
> From: Christian Folini <chr...@ne...>
> Sent: 11 January 2021 07:21
> To: mod...@li...
> Subject: Re: [mod-security-users] CRS Issues being automatically closed?
> 
> Hey Jamie,
> 
> This is the mailing list for the ModSecurity engine. The CRS project has a
> separate mailinglist over at
> 
> https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project
> 
> But let me answer your question nevertheless:
> 
> You are correct and this configuration to close stale issues after 120
> days is offensive. And we did not take it lightly. We have been struggling
> with not being able to address all the issues for years. We tried
> different methods, scheduling, assigning, highlighting, inviting the wider
> community to help, tagging as "#goodfirstissue" etc.  But it did not bring
> a real solution: The issues pile up and new issues (also vital ones!) can
> end up buried under a pile that is too big to plough through.
> 
> As most open source projects, CRS is a volunteer driven project. People
> work on CRS because they want to work on CRS. Some steal time from their
> companies to do so, some put their children to bed to hack away. But it is
> always time that our developers give to the project freely. I as a
> co-leader of the project can not force issues into their hands. All I can
> do is making CRS a fun project to work with and prepare the environment in
> a way that makes it easy and cool to work on CRS.
> 
> And the huge pile of issues started to have a chilling effect on
> developers or new developers. There is a moment where the pile is so big,
> you are not even addressing what you can address because of all the rest.
> Looking at the
> 36 issues open right now feels managable and most issues are being
> addressed.
> (You can tell easily, since most open issues do have a conversation
> history.)
> 
> So we talked about the step a big deal and we took the decision about a
> year ago.  Ultimately it was a decision to pick between the goodwill and
> health of the developers and the goodwill of individual users. I am really
> not happy with the way it is and I have a new plan to help us address all
> the issues before they get stale. But it is not quite ready to share.
> 
> What can you do: If you care about an issue, then comment on it. We read
> every comment on every issue. If get the notice that the issue has been
> tagged for removal (the tag "Stale issue" is being applied 2 weeks or so
> before it gets closed), then comment on the issue and tell us you still
> care. Also multiple users chiming in give an issue priority in our eyes.
> We currently do an issue chat once a month (3rd Monday every month), where
> we look into 5-10 open issues. One way to make sure an issue makes it into
> that meeting is the tag "Meeting agenda". Ask us to add this tag and we
> will take it on the list.
> 
> All in all, using the services of the stale issue bot is not a sign that
> we do not care. Quite the opposite. We care a lot and we feel bad about
> using the stale issue bot. But it was the only solution we saw.
> 
> Hope this explains our reasoning a bit.
> 
> Best regards and thanks for speaking up,
> 
> Christian Folini, CRS Co-Lead
> 
> 
> 
> 
> 
> 
> On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote:
> > Hi CRS Team
> >
> > I'm disappointed to see that issues I'm reporting (FPs) (e.g.
> > https://github.com/coreruleset/coreruleset/issues/1864) are being
> > automatically closed by stalebot. I fully understand that there may
> > not be the time nor the resources to address issues reported, and I
> > know why stalebot exists, but I don't think rule issues that people
> > have spent time looking at and reporting should be closed before they
> > are actually addressed. It certainly doesn't encourage me to continue
> > reporting them moving forward.
> >
> > Cheers, Jamie
> 
> 
> > _______________________________________________
> > 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] CRS Issues being automatically closed?

[Jamie B. <ja...@ib...>]

Hi Christian

Thanks for the response and apologise for posting in the incorrect list.
Great to see there is things in development to address this.

I just wanted to re-iterate that the issue I raise is not one of
expectation for anyone to look at the issues reported (in their spare time
or otherwise) - I fully understand your points here. Rather, I would just
prefer to see current issues not automatically closed and buried.

Best Regards,
Jamie

-----Original Message-----
From: Christian Folini <chr...@ne...>
Sent: 11 January 2021 07:21
To: mod...@li...
Subject: Re: [mod-security-users] CRS Issues being automatically closed?

Hey Jamie,

This is the mailing list for the ModSecurity engine. The CRS project has a
separate mailinglist over at

https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project

But let me answer your question nevertheless:

You are correct and this configuration to close stale issues after 120
days is offensive. And we did not take it lightly. We have been struggling
with not being able to address all the issues for years. We tried
different methods, scheduling, assigning, highlighting, inviting the wider
community to help, tagging as "#goodfirstissue" etc.  But it did not bring
a real solution: The issues pile up and new issues (also vital ones!) can
end up buried under a pile that is too big to plough through.

As most open source projects, CRS is a volunteer driven project. People
work on CRS because they want to work on CRS. Some steal time from their
companies to do so, some put their children to bed to hack away. But it is
always time that our developers give to the project freely. I as a
co-leader of the project can not force issues into their hands. All I can
do is making CRS a fun project to work with and prepare the environment in
a way that makes it easy and cool to work on CRS.

And the huge pile of issues started to have a chilling effect on
developers or new developers. There is a moment where the pile is so big,
you are not even addressing what you can address because of all the rest.
Looking at the
36 issues open right now feels managable and most issues are being
addressed.
(You can tell easily, since most open issues do have a conversation
history.)

So we talked about the step a big deal and we took the decision about a
year ago.  Ultimately it was a decision to pick between the goodwill and
health of the developers and the goodwill of individual users. I am really
not happy with the way it is and I have a new plan to help us address all
the issues before they get stale. But it is not quite ready to share.

What can you do: If you care about an issue, then comment on it. We read
every comment on every issue. If get the notice that the issue has been
tagged for removal (the tag "Stale issue" is being applied 2 weeks or so
before it gets closed), then comment on the issue and tell us you still
care. Also multiple users chiming in give an issue priority in our eyes.
We currently do an issue chat once a month (3rd Monday every month), where
we look into 5-10 open issues. One way to make sure an issue makes it into
that meeting is the tag "Meeting agenda". Ask us to add this tag and we
will take it on the list.

All in all, using the services of the stale issue bot is not a sign that
we do not care. Quite the opposite. We care a lot and we feel bad about
using the stale issue bot. But it was the only solution we saw.

Hope this explains our reasoning a bit.

Best regards and thanks for speaking up,

Christian Folini, CRS Co-Lead






On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote:
> Hi CRS Team
>
> I'm disappointed to see that issues I'm reporting (FPs) (e.g.
> https://github.com/coreruleset/coreruleset/issues/1864) are being
> automatically closed by stalebot. I fully understand that there may
> not be the time nor the resources to address issues reported, and I
> know why stalebot exists, but I don't think rule issues that people
> have spent time looking at and reporting should be closed before they
> are actually addressed. It certainly doesn't encourage me to continue
> reporting them moving forward.
>
> Cheers, Jamie


> _______________________________________________
> 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] CRS Issues being automatically closed?

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

Hey Jamie,

This is the mailing list for the ModSecurity engine. The CRS project has a
separate mailinglist over at

https://groups.google.com/a/owasp.org/g/modsecurity-core-rule-set-project

But let me answer your question nevertheless:

You are correct and this configuration to close stale issues after 120 days is
offensive. And we did not take it lightly. We have been struggling with not
being able to address all the issues for years. We tried different methods,
scheduling, assigning, highlighting, inviting the wider community to help,
tagging as "#goodfirstissue" etc.  But it did not bring a real solution: The
issues pile up and new issues (also vital ones!) can end up buried under a
pile that is too big to plough through.

As most open source projects, CRS is a volunteer driven project. People work
on CRS because they want to work on CRS. Some steal time from their companies
to do so, some put their children to bed to hack away. But it is always time
that our developers give to the project freely. I as a co-leader of the
project can not force issues into their hands. All I can do is making CRS a
fun project to work with and prepare the environment in a way that makes
it easy and cool to work on CRS.

And the huge pile of issues started to have a chilling effect on developers or
new developers. There is a moment where the pile is so big, you are not even
addressing what you can address because of all the rest. Looking at the 
36 issues open right now feels managable and most issues are being addressed.
(You can tell easily, since most open issues do have a conversation history.)

So we talked about the step a big deal and we took the decision about a year
ago.  Ultimately it was a decision to pick between the goodwill and health of
the developers and the goodwill of individual users. I am really not happy
with the way it is and I have a new plan to help us address all the issues
before they get stale. But it is not quite ready to share.

What can you do: If you care about an issue, then comment on it. We read every
comment on every issue. If get the notice that the issue has been tagged for
removal (the tag "Stale issue" is being applied 2 weeks or so before it gets
closed), then comment on the issue and tell us you still care. Also multiple
users chiming in give an issue priority in our eyes. We currently do an issue
chat once a month (3rd Monday every month), where we look into 5-10 open
issues. One way to make sure an issue makes it into that meeting is the tag
"Meeting agenda". Ask us to add this tag and we will take it on the list.

All in all, using the services of the stale issue bot is not a sign that we do
not care. Quite the opposite. We care a lot and we feel bad about using the
stale issue bot. But it was the only solution we saw.

Hope this explains our reasoning a bit.

Best regards and thanks for speaking up,

Christian Folini, CRS Co-Lead






On Mon, Jan 11, 2021 at 12:49:17AM +0000, Jamie Burchell wrote:
> Hi CRS Team
> 
> I'm disappointed to see that issues I'm reporting (FPs) (e.g.
> https://github.com/coreruleset/coreruleset/issues/1864) are being
> automatically closed by stalebot. I fully understand that there may not be
> the time nor the resources to address issues reported, and I know why
> stalebot exists, but I don't think rule issues that people have spent time
> looking at and reporting should be closed before they are actually
> addressed. It certainly doesn't encourage me to continue reporting them
> moving forward.
> 
> Cheers, Jamie


> _______________________________________________
> 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] CRS Issues being automatically closed?

[Jamie B. <ja...@ib...>]

Hi CRS Team

I'm disappointed to see that issues I'm reporting (FPs) (e.g. https://github.com/coreruleset/coreruleset/issues/1864) are being automatically closed by stalebot. I fully understand that there may not be the time nor the resources to address issues reported, and I know why stalebot exists, but I don't think rule issues that people have spent time looking at and reporting should be closed before they are actually addressed. It certainly doesn't encourage me to continue reporting them moving forward.

Cheers,
Jamie

Re: [mod-security-users] The difference between v2 and v3

[Michael W. <sco...@ya...>]

Thanks for the info
Tel:       01257 266394 Mobile: 07944032617 Email:  sco...@ya... 

    On Friday, 8 January 2021, 15:37:02 GMT, Christian Folini <chr...@ne...> wrote:  
 
 On Fri, Jan 08, 2021 at 02:59:34PM +0000, Michael Woods via mod-security-users
wrote:
> We are current users of version 2 of mod_security and wondering what is the
> differences between this and version 3. What issues are experienced when
> moving to version 2?regards

Different when moving from v2 to v3? Or the other way around? Your wording is
not quite clear, sorry.

Brief summary of what is potentially a big discussion:

v3 has the advantage it runs "stable" on nginx. I put this in apostrophes,
since it has certain gaps in the implementation and suffers from a series of
weaknesses.

The ModSecurity reference platform for the OWASP ModSecurity Core Rule Set
project (CRS) is ModSecurity v2 on Apache 2.4.

v3 fails to pass the testsuite of CRS  because of the issues named above
and also has severe performance problems.

On the bright side, v3 is actively developed, while v2 is stable but no longer
under active development. Also, ModSecurity v2 is not stable on Nginx.

Regs,

Christian






> _______________________________________________
> 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] The difference between v2 and v3

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

On Fri, Jan 08, 2021 at 02:59:34PM +0000, Michael Woods via mod-security-users
wrote:
> We are current users of version 2 of mod_security and wondering what is the
> differences between this and version 3. What issues are experienced when
> moving to version 2?regards

Different when moving from v2 to v3? Or the other way around? Your wording is
not quite clear, sorry.

Brief summary of what is potentially a big discussion:

v3 has the advantage it runs "stable" on nginx. I put this in apostrophes,
since it has certain gaps in the implementation and suffers from a series of
weaknesses.

The ModSecurity reference platform for the OWASP ModSecurity Core Rule Set
project (CRS) is ModSecurity v2 on Apache 2.4.

v3 fails to pass the testsuite of CRS  because of the issues named above
and also has severe performance problems.

On the bright side, v3 is actively developed, while v2 is stable but no longer
under active development. Also, ModSecurity v2 is not stable on Nginx.

Regs,

Christian






> _______________________________________________
> 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] The difference between v2 and v3

[Michael W. <sco...@ya...>]

We are current users of version 2 of mod_security and wondering what is the differences between this and version 3. What issues are experienced when moving to version 2?regards

[mod-security-users] A nested json rule question

[Brian C. <bri...@ml...>]

Hi all,
I'm using mod_security 3.x.
I have a post request which the body contains nested json like below,

*{*
*  "field1": 111,*
*  "field2": [*
*    {*
*      "ff1": 1111*
*    },*
*    {*
*      "ff2": {*
*        "fff1": 11111*
*      }*
*    }*
*  ]*
*}*

I want to check the field exist so that I can make sure the post request is
legal.

So I wrote the rule below:
*SecRule ARGS_NAMES:json.field2.ff2.fff1 "fff1" "id:'200444',phase:3,log"*

Is this correct? Or should I change pattens to *"**json.field2.ff2.fff1"*?

As mentioned above, if I modified the rule to
*SecRule ARGS_NAMES "json.field2.ff2.fff1**"(or "fff1")
"id:'200444',phase:3,log"*

I should get the same result, right?


Best Regards,
Brian

Re: [mod-security-users] SecRuleUpdateTargetById in 3.0.4

[Jose R R <jos...@me...>]

On Tue, Jan 5, 2021 at 9:21 AM Henri Cook <he...@pr...> wrote:
>
> Hi everyone,
>
> I attempted an upgrade to 3.0.4 today from 3.0.3. Unfortunately I can't get over a hurdle.
>
> I have an existing rule:
>
> ```
> # Rule 930110 matches "..\u003e" in body (HTML escaped JSON value "..<")
> # Replacing REQUEST_BODY with ARGS_NAMES|ARGS fixes the issue as the rule see
> # the value after Unicode decoding '\u003e' => '>'.
> SecRuleUpdateTargetById 930110 "!REQUEST_BODY"
> SecRuleUpdateTargetById 930110 ARGS_NAMES,ARGS
> ```
>
> Due to modsec issue https://github.com/SpiderLabs/ModSecurity/issues/2251 it seems i'm using the 'non-regex' form of the rule that's fixed in master but not yet released.
>
> First I tried a patch, which failed to apply (any advice on how to patch this from the 3.0.4 tag would be appreciated) with this in my build process:
>
> ```
> curl -fSL https://github.com/SpiderLabs/ModSecurity/commit/1b1fdc055b8071ad3b24573abfe9b96e546c7abf.patch | patch -p1 && \
> ```
>
> When that didn't apply
CHANGES.rej is the only (non-)issue as the patch effectively applies
(inside your modsecurity-v3.0.4 directory) to all other files as .. |
patch --fuzz=0 -p1 .
As far as I can tell, you may edit CHANGES file manually by adding the
content inside CHANGES.rej and then removing the latter.

> I tried (as a temporary workaround) removing the rule, but for some reason it was still triggering in my unit tests. For that I used:
>
> ```
> SecRuleRemoveById 930110
> ```
>
> I don't really know where to go from here, i'm using the CRS 3.2.0 ruleset.
>
> Best Regards,
>
> Henri
> _______________________________________________
> 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/

Best Professional Regards.

--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.15 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---------------------------------------------------------------------------------------------
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
-------------------------------------------------------------------------------------------
Build Engine X 1.19.6 with built-in Nginx connector v1.0.1 module:
------------------------------------------------------------------------------------------
https://github.com/Metztli/debian-modsecurity-nginx-connector
------------------------------------------------------------------------------------------

[mod-security-users] SecRuleUpdateTargetById in 3.0.4

[Henri C. <he...@pr...>]

Hi everyone,

I attempted an upgrade to 3.0.4 today from 3.0.3. Unfortunately I can't get
over a hurdle.

I have an existing rule:

```
# Rule 930110 matches "..\u003e" in body (HTML escaped JSON value "..<")
# Replacing REQUEST_BODY with ARGS_NAMES|ARGS fixes the issue as the rule
see
# the value after Unicode decoding '\u003e' => '>'.
SecRuleUpdateTargetById 930110 "!REQUEST_BODY"
SecRuleUpdateTargetById 930110 ARGS_NAMES,ARGS
```

Due to modsec issue https://github.com/SpiderLabs/ModSecurity/issues/2251
it seems i'm using the 'non-regex' form of the rule that's fixed in master
but not yet released.

First I tried a patch, which failed to apply (any advice on how to patch
this from the 3.0.4 tag would be appreciated) with this in my build process:

```
curl -fSL
https://github.com/SpiderLabs/ModSecurity/commit/1b1fdc055b8071ad3b24573abfe9b96e546c7abf.patch
| patch -p1 && \
```

When that didn't apply I tried (as a temporary workaround) removing the
rule, but for some reason it was still triggering in my unit tests. For
that I used:

```
SecRuleRemoveById 930110
```

I don't really know where to go from here, i'm using the CRS 3.2.0 ruleset.

Best Regards,

Henri

[mod-security-users] High memory usage with nginx on 3.0.3

[Henri C. <he...@pr...>]

Hi all,

I'm running modsecurity 3.0.3 and modsecurity-nginx 1.0.0

Recently i've been working with a new payload, which is about 5.5MB of
JSON. When anyone POSTs this to my nginx instance memory on the container
goes from about 30MB (resting rate) to 140MB!

I've tried turning off the rule engine (ctl:ruleEngine=off) for traffic to
this specific path (@beginsWith /foo) but memory usage is still jumping
massively.

Can anyone think that might be causing this? and how I might stop it? I
could live without having this content inspected if that's what it takes.

Best Regards,

Henri

[mod-security-users] CRS v3.3.1 Release Candidate 1 available

[Walter H. <mo...@sp...>]

The OWASP ModSecurity Core Rule Set team is proud to announce the release candidate 1 for the upcoming CRS v3.3.1 release. The release candidate is available at:

https://github.com/coreruleset/coreruleset/archive/v3.3.1-rc1.tar.gz
https://github.com/coreruleset/coreruleset/archive/v3.3.1-rc1.zip

This is a maintenance release, containing the following changes:

- Run rules as early as possible, by decreasing phase:2 to phase:1 and phase:4 to phase:3 where the variables allow it (Ervin Hegedüs)
- Add early blocking mode (tx.blocking_early) to block at the end of phase:1 and phase:3 (Christian Folini)

There are no changes to attack detections, so this release is mostly a “drop-in” replacement for our former release 3.3.0. If you are already running v3.3.0, you can simply extract the files over your existing files.

The early blocking mode may improve performance, as it allows to block a request quickly before processing of rules in phase 2 takes place (however, most attack detections still take place in phase 2). To use this feature, enable the tx.blocking_early setting in crs-setup.conf. Please see the example configuration file for more details: https://github.com/coreruleset/coreruleset/blob/v3.3.1-rc1/crs-setup.conf.example#L320

Our desire is to see the Core Rule Set project used as a baseline security feature, effectively protecting from OWASP Top 10 risks with few side effects. As such we attempt to cut down on false positives as much as possible in the default install. This RC therefore offers an opportunity for individuals to provide feedback and to report any issue they face with this release. We will then try and fix them for the upcoming full release.

Please use the CRS GitHub (https://github.com/coreruleset/coreruleset), our slack channel (#coreruleset on owasp.slack.com), or the Core Rule Set mailing list to tell us about your experiences, including false positives or other issues with this release candidate.

We plan the release on Tuesday the 5th of January 2021.

We look forward to hearing your feedback!

Sincerely,
Walter Hop, release manager, on behalf of the Core Rule Set development team

Re: [mod-security-users] apache 2 mod_security iptables

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

Am 26.12.20 um 17:56 schrieb jin&hitman&Barracuda:
> Sorry to html mails but there is no chance to replace.
> 
> In the first mail 'djc...@gm... 
> <mailto:djc...@gm...>' mentioned that he/she needs for a 
> solution for pfsense. You didn't read it, did you ? (Please don't 
> answer, it's obvious)

that's why "iptables" is part of the subject?
"pfsense style firewall" - you emtioned the "style"?

> I never wanted to be the guy who have to argue with a Linux fanatic 
> which thinks systemd is a salvation. Nope, never and ever and God my 
> witness. God, i beg you to don't push me that hard, don't let me be that 
> guy.


disclaimer: this is a BSD guy and the subject is misleading: 
https://www.youtube.com/watch?v=o_AIw9bGogo

> By the way, it must be a miracle to have a dc fw that has 51 record. 
> Glorious...

idiot that's one out of 25 ipsets, the manual blocklist

IPSET - OVERVIEW

970  BLOCKED_FEED_IPV4              hash:net
208  BLOCKED_DYNAMIC_PORTSCAN_IPV4  hash:ip      timeout:45
161  PORTS_RESTRICTED               bitmap:port
131  OUTBOUND_BLOCKED_PORTS         bitmap:port
69   PORTSCAN_PORTS                 bitmap:port
63   HONEYPOT_PORTS                 bitmap:port
51   BLOCKED_IPV4                   hash:net
18   INFRASTRUCTURE_IPV4            hash:net
18   HONEYPOT_IPS_IPV4              hash:net
13   IANA_RESERVED_IPV4             hash:net
13   ADMIN_CLIENTS_IPV4             hash:net
11   OUTBOUND_BLOCKED_SRC_IPV4      hash:net
11   LAN_VPN_FORWARDING_IPV4        hash:net
8    EXCLUDES_IPV4                  hash:net
7    PORTS_MAIL                     bitmap:port
5    RESTRICTED_IPV4                hash:net
5    IPERF_IPV4                     hash:net
4    RBL_SYNC_IPV4                  hash:net
4    JABBER_IPV4                    hash:net
4    BAYES_SYNC_IPV4                hash:net
3    BLOCKED_MERGED_IPV4            list:set
2    DNS_PORTS                      bitmap:port
1    BLOCKED_DYNAMIC_MAIL_IPV4      hash:ip      timeout:60

-----------------------
RULES
-----------------------
264  IPV4  total
206  IPV4  filter
32   IPV4  mangle
18   IPV4  raw
8    IPV4  nat

-----------------------
CHAINS
-----------------------
65  IPV4  total
53  IPV4  filter
9   IPV4  mangle
2   IPV4  raw
1   IPV4  nat

> I sould have to thank you because you entertained me well. All of them 
> are just a joke but you know that you started this.

as said: you are an idiot

> On Sat, Dec 26, 2020, 18:20 Reindl Harald <h.r...@th... 
> <mailto:h.r...@th...>> wrote:
> 
>     firsat: may i ask you why you respond with html to plaintext mails?
> 
>     Am 26.12.20 um 16:00 schrieb jin&hitman&Barracuda:
>      > Hi,
>      >
>      > I'm not here to argue about iptables (or ipsets) and i did not
>     say that
>      > every and each address needs a iptables rule. I just said, a lot
>     easier
>      > than *iptables*. At the time ipsets introduced, there was some
>     design
>      > flaw like;
>      >
>      > - ipsets did not support to load host (/32) address and networks
>     into
>      > single table. It needs to be load i as separate tables
> 
>     not true! "Type: hash:net" has no problem with /32
> 
>     if you use "hash:ip" but want to mix: a fool with a tool is still a fool
> 
>     --------------------------
> 
>     real-world ipset from a datacenter firewall
> 
>     Name: BLOCKED_IPV4
>     Type: hash:net
>     Header: family inet hashsize 1024 maxelem 512
>     Size in memory: 3520
>     Number of entries: 51
> 
>     Members:
>     3.112.171.163
>     18.130.64.226
>     31.28.163.0/24 <http://31.28.163.0/24>
>     31.28.170.0/24 <http://31.28.170.0/24>
> 
>     --------------------------
> 
>      > - under same conditions and same hardware, ipsets was need more
>     time to
>      > load/reload sets/tables than pf
> 
>     how often do you reboot?
> 
>      > - When you need to use a file to load sample of addresses, you
>     need to
>      > specifically design that file because ipset doesn't support to
>     load a
>      > list of address from a simple text file. Each and every line
>     should be
>      > start with "add" key word and should continue with "<ipset_name>"
>     and
>      > "ip address". Also you have to add ipset create stanza on the very
>      > beginning of that file. On the contrary, pf can load address from a
>      > simple file and yet there is no need to add anything to that file or
>      > divide address list into host address and network address.
> 
>     hell, that's what save/restore is for
> 
>     a) ipset -file /etc/sysconfig/ipset restore
>          one time at reboot before restore
>          iptables/iptables-nft
>     b) ipset -file /etc/sysconfig/ipset save
>          each time you made changes which should
>          survive a reboot
> 
>     and when you want to load from a textfile you just loop trough the
>     textfile and so "ipset add IPSET_NAME VALUE" which is a 1-liner if
>     you want
> 
>      > I did not use ipsets after than rhel6, there must be some
>     improvements
> 
>     RHEL6 is a long time ago
>     AFAIK you needed redirection instead -file to begin with
> 
>      > but i doubt that it will be useful as pf does.
> 
>     jesus christ......
> 
>     and even if PF has some advantages nobody will switch to openbsd
>     because
>     of that and if it's only because there is no systemd, initscripts
>     are crap
> 
>      > On Sat, Dec 26, 2020 at 12:46 PM Reindl Harald
>     <h.r...@th... <mailto:h.r...@th...>
>      > <mailto:h.r...@th... <mailto:h.r...@th...>>>
>     wrote:
>      >
>      >
>      >
>      >     Am 26.12.20 um 10:11 schrieb jin&hitman&Barracuda:
>      >      > Hi,
>      >      >
>      >      > I've used failban for a bunch of smtp servers and it didn't go
>      >     well. But
>      >      > there is another project (crowdsec) and i guess that it is
>     worth to
>      >      > mention here. The project have many features which failban
>     don't
>      >     have. I
>      >      > haven't try it yet but i will soon. May be you'd like to
>     look at it.
>      >      >
>      >      > Crowdsec: A Fail2Ban alternative written in Go -
>      >      > https://github.com/crowdsecurity/crowdsec
>     <https://github.com/crowdsecurity/crowdsec>
>      >     <https://github.com/crowdsecurity/crowdsec
>     <https://github.com/crowdsecurity/crowdsec>>
>      >      > <https://github.com/crowdsecurity/crowdsec
>     <https://github.com/crowdsecurity/crowdsec>
>      >     <https://github.com/crowdsecurity/crowdsec
>     <https://github.com/crowdsecurity/crowdsec>>>
>      >      >
>      >      > By the way, while i was using failban, i had a script (which i
>      >     wrote) to
>      >      > add/remove ip adresses to openbsd firewall which is a lot
>     easier
>      >     than
>      >      > iptables.
>      >
>      >     you don't write iptables rules for each and every address
>      >
>      > https://ipset.netfilter.org/ <https://ipset.netfilter.org/>
>     <https://ipset.netfilter.org/ <https://ipset.netfilter.org/>> is your
>      >     friend
>      > https://ipset.netfilter.org/ipset.man.html
>     <https://ipset.netfilter.org/ipset.man.html>
>      >     <https://ipset.netfilter.org/ipset.man.html
>     <https://ipset.netfilter.org/ipset.man.html>>
>      >
>      >     * you have *one* iptables rule with the ipset match
>      >     * one command adds or removes and ip to the set
>      >     * it's dramatically faster -> hash-table
>      >     * you can block millions of ips without performance drop
>      >
>      >      > On Sat, Dec 26, 2020, 11:37 Jeffery Wilkins
>      >     <djc...@gm... <mailto:djc...@gm...>
>     <mailto:djc...@gm... <mailto:djc...@gm...>>
>      >      > <mailto:djc...@gm...
>     <mailto:djc...@gm...>
>      >     <mailto:djc...@gm...
>     <mailto:djc...@gm...>>>> wrote:
>      >      >
>      >      >     im looking for some people who host http servers
>      >     (apache/nginx) and who
>      >      >     are familiar with mod_security and iptables firewalls
>      >      >     the setup that I am after is if an IP address hits my
>     website and
>      >      >     does a
>      >      >     typical vuln scan my web server sends them back no
>     response
>      >     and they
>      >      >     silently get added to an iptables ipset blacklist that
>     lasts
>      >     for 1 week
>      >      >     I already have mod_security (OWASP RULES) on my apache 2
>      >     server at
>      >      >     (192.168.2.10) and a pfsense style firewall at
>     (192.168.2.1)
>      >      >     kind of like a web server honeypot if you will
>      >      >     my current setup is already pretty powerful if you
>     even send
>      >     a simple
>      >      >     TCP SYN packet to port 21,22 or even 23 you
>     automatically get
>      >     added to
>      >      >     my routers firewall and dropped for 7 days for both in and
>      >     outbound
>      >      >     forgive me for asking alot but I really want to buckle
>     down
>      >     on these
>      >      >     stupid automated vuln scanners and keep them off my
>     network
>      >      >     I have already looked into things like fail2ban but
>     that only
>      >     protects
>      >      >     the webserver itself and does not integrate with my
>     routers
>      >     firewall at
>      >      >     all protecting the network as a whole
>      >
>      >
>      >     _______________________________________________
>      >     mod-security-users mailing list
>      > mod...@li...
>     <mailto:mod...@li...>
>      >     <mailto:mod...@li...
>     <mailto:mod...@li...>>
>      > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>     <https://lists.sourceforge.net/lists/listinfo/mod-security-users>
>      >   
>       <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/rules/
>     <http://www.modsecurity.org/projects/commercial/rules/>>
>      > http://www.modsecurity.org/projects/commercial/support/
>     <http://www.modsecurity.org/projects/commercial/support/>
>      >     <http://www.modsecurity.org/projects/commercial/support/
>     <http://www.modsecurity.org/projects/commercial/support/>>

Re: [mod-security-users] apache 2 mod_security iptables

[jin&hitman&Barracuda <jin...@gm...>]

Sorry to html mails but there is no chance to replace.

In the first mail 'djc...@gm...' mentioned that he/she needs
for a solution for pfsense. You didn't read it, did you ? (Please don't
answer, it's obvious)

I never wanted to be the guy who have to argue with a Linux fanatic which
thinks systemd is a salvation. Nope, never and ever and God my witness.
God, i beg you to don't push me that hard, don't let me be that guy.

By the way, it must be a miracle to have a dc fw that has 51 record.
Glorious...

I sould have to thank you because you entertained me well. All of them are
just a joke but you know that you started this.

djc...@gm..., i'm really sorry to bother you because honestly i
just wanted to share something that could help you. Usually, i never poke
or push people to argue with me.



On Sat, Dec 26, 2020, 18:20 Reindl Harald <h.r...@th...> wrote:

> firsat: may i ask you why you respond with html to plaintext mails?
>
> Am 26.12.20 um 16:00 schrieb jin&hitman&Barracuda:
> > Hi,
> >
> > I'm not here to argue about iptables (or ipsets) and i did not say that
> > every and each address needs a iptables rule. I just said, a lot easier
> > than *iptables*. At the time ipsets introduced, there was some design
> > flaw like;
> >
> > - ipsets did not support to load host (/32) address and networks into
> > single table. It needs to be load i as separate tables
>
> not true! "Type: hash:net" has no problem with /32
>
> if you use "hash:ip" but want to mix: a fool with a tool is still a fool
>
> --------------------------
>
> real-world ipset from a datacenter firewall
>
> Name: BLOCKED_IPV4
> Type: hash:net
> Header: family inet hashsize 1024 maxelem 512
> Size in memory: 3520
> Number of entries: 51
>
> Members:
> 3.112.171.163
> 18.130.64.226
> 31.28.163.0/24
> 31.28.170.0/24
>
> --------------------------
>
> > - under same conditions and same hardware, ipsets was need more time to
> > load/reload sets/tables than pf
>
> how often do you reboot?
>
> > - When you need to use a file to load sample of addresses, you need to
> > specifically design that file because ipset doesn't support to load a
> > list of address from a simple text file. Each and every line should be
> > start with "add" key word and should continue with "<ipset_name>" and
> > "ip address". Also you have to add ipset create stanza on the very
> > beginning of that file. On the contrary, pf can load address from a
> > simple file and yet there is no need to add anything to that file or
> > divide address list into host address and network address.
>
> hell, that's what save/restore is for
>
> a) ipset -file /etc/sysconfig/ipset restore
>     one time at reboot before restore
>     iptables/iptables-nft
> b) ipset -file /etc/sysconfig/ipset save
>     each time you made changes which should
>     survive a reboot
>
> and when you want to load from a textfile you just loop trough the
> textfile and so "ipset add IPSET_NAME VALUE" which is a 1-liner if you want
>
> > I did not use ipsets after than rhel6, there must be some improvements
>
> RHEL6 is a long time ago
> AFAIK you needed redirection instead -file to begin with
>
> > but i doubt that it will be useful as pf does.
>
> jesus christ......
>
> and even if PF has some advantages nobody will switch to openbsd because
> of that and if it's only because there is no systemd, initscripts are crap
>
> > On Sat, Dec 26, 2020 at 12:46 PM Reindl Harald <h.r...@th...
> > <mailto:h.r...@th...>> wrote:
> >
> >
> >
> >     Am 26.12.20 um 10:11 schrieb jin&hitman&Barracuda:
> >      > Hi,
> >      >
> >      > I've used failban for a bunch of smtp servers and it didn't go
> >     well. But
> >      > there is another project (crowdsec) and i guess that it is worth
> to
> >      > mention here. The project have many features which failban don't
> >     have. I
> >      > haven't try it yet but i will soon. May be you'd like to look at
> it.
> >      >
> >      > Crowdsec: A Fail2Ban alternative written in Go -
> >      > https://github.com/crowdsecurity/crowdsec
> >     <https://github.com/crowdsecurity/crowdsec>
> >      > <https://github.com/crowdsecurity/crowdsec
> >     <https://github.com/crowdsecurity/crowdsec>>
> >      >
> >      > By the way, while i was using failban, i had a script (which i
> >     wrote) to
> >      > add/remove ip adresses to openbsd firewall which is a lot easier
> >     than
> >      > iptables.
> >
> >     you don't write iptables rules for each and every address
> >
> >     https://ipset.netfilter.org/ <https://ipset.netfilter.org/> is your
> >     friend
> >     https://ipset.netfilter.org/ipset.man.html
> >     <https://ipset.netfilter.org/ipset.man.html>
> >
> >     * you have *one* iptables rule with the ipset match
> >     * one command adds or removes and ip to the set
> >     * it's dramatically faster -> hash-table
> >     * you can block millions of ips without performance drop
> >
> >      > On Sat, Dec 26, 2020, 11:37 Jeffery Wilkins
> >     <djc...@gm... <mailto:djc...@gm...>
> >      > <mailto:djc...@gm...
> >     <mailto:djc...@gm...>>> wrote:
> >      >
> >      >     im looking for some people who host http servers
> >     (apache/nginx) and who
> >      >     are familiar with mod_security and iptables firewalls
> >      >     the setup that I am after is if an IP address hits my website
> and
> >      >     does a
> >      >     typical vuln scan my web server sends them back no response
> >     and they
> >      >     silently get added to an iptables ipset blacklist that lasts
> >     for 1 week
> >      >     I already have mod_security (OWASP RULES) on my apache 2
> >     server at
> >      >     (192.168.2.10) and a pfsense style firewall at (192.168.2.1)
> >      >     kind of like a web server honeypot if you will
> >      >     my current setup is already pretty powerful if you even send
> >     a simple
> >      >     TCP SYN packet to port 21,22 or even 23 you automatically get
> >     added to
> >      >     my routers firewall and dropped for 7 days for both in and
> >     outbound
> >      >     forgive me for asking alot but I really want to buckle down
> >     on these
> >      >     stupid automated vuln scanners and keep them off my network
> >      >     I have already looked into things like fail2ban but that only
> >     protects
> >      >     the webserver itself and does not integrate with my routers
> >     firewall at
> >      >     all protecting the network as a whole
> >
> >
> >     _______________________________________________
> >     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/
>

Re: [mod-security-users] apache 2 mod_security iptables

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

firsat: may i ask you why you respond with html to plaintext mails?

Am 26.12.20 um 16:00 schrieb jin&hitman&Barracuda:
> Hi,
> 
> I'm not here to argue about iptables (or ipsets) and i did not say that 
> every and each address needs a iptables rule. I just said, a lot easier 
> than *iptables*. At the time ipsets introduced, there was some design 
> flaw like;
> 
> - ipsets did not support to load host (/32) address and networks into 
> single table. It needs to be load i as separate tables

not true! "Type: hash:net" has no problem with /32

if you use "hash:ip" but want to mix: a fool with a tool is still a fool

--------------------------

real-world ipset from a datacenter firewall

Name: BLOCKED_IPV4
Type: hash:net
Header: family inet hashsize 1024 maxelem 512
Size in memory: 3520
Number of entries: 51

Members:
3.112.171.163
18.130.64.226
31.28.163.0/24
31.28.170.0/24

--------------------------

> - under same conditions and same hardware, ipsets was need more time to 
> load/reload sets/tables than pf

how often do you reboot?

> - When you need to use a file to load sample of addresses, you need to 
> specifically design that file because ipset doesn't support to load a 
> list of address from a simple text file. Each and every line should be 
> start with "add" key word and should continue with "<ipset_name>" and 
> "ip address". Also you have to add ipset create stanza on the very 
> beginning of that file. On the contrary, pf can load address from a 
> simple file and yet there is no need to add anything to that file or 
> divide address list into host address and network address.

hell, that's what save/restore is for

a) ipset -file /etc/sysconfig/ipset restore
    one time at reboot before restore
    iptables/iptables-nft
b) ipset -file /etc/sysconfig/ipset save
    each time you made changes which should
    survive a reboot

and when you want to load from a textfile you just loop trough the 
textfile and so "ipset add IPSET_NAME VALUE" which is a 1-liner if you want

> I did not use ipsets after than rhel6, there must be some improvements 

RHEL6 is a long time ago
AFAIK you needed redirection instead -file to begin with

> but i doubt that it will be useful as pf does.

jesus christ......

and even if PF has some advantages nobody will switch to openbsd because 
of that and if it's only because there is no systemd, initscripts are crap

> On Sat, Dec 26, 2020 at 12:46 PM Reindl Harald <h.r...@th... 
> <mailto:h.r...@th...>> wrote:
> 
> 
> 
>     Am 26.12.20 um 10:11 schrieb jin&hitman&Barracuda:
>      > Hi,
>      >
>      > I've used failban for a bunch of smtp servers and it didn't go
>     well. But
>      > there is another project (crowdsec) and i guess that it is worth to
>      > mention here. The project have many features which failban don't
>     have. I
>      > haven't try it yet but i will soon. May be you'd like to look at it.
>      >
>      > Crowdsec: A Fail2Ban alternative written in Go -
>      > https://github.com/crowdsecurity/crowdsec
>     <https://github.com/crowdsecurity/crowdsec>
>      > <https://github.com/crowdsecurity/crowdsec
>     <https://github.com/crowdsecurity/crowdsec>>
>      >
>      > By the way, while i was using failban, i had a script (which i
>     wrote) to
>      > add/remove ip adresses to openbsd firewall which is a lot easier
>     than
>      > iptables.
> 
>     you don't write iptables rules for each and every address
> 
>     https://ipset.netfilter.org/ <https://ipset.netfilter.org/> is your
>     friend
>     https://ipset.netfilter.org/ipset.man.html
>     <https://ipset.netfilter.org/ipset.man.html>
> 
>     * you have *one* iptables rule with the ipset match
>     * one command adds or removes and ip to the set
>     * it's dramatically faster -> hash-table
>     * you can block millions of ips without performance drop
> 
>      > On Sat, Dec 26, 2020, 11:37 Jeffery Wilkins
>     <djc...@gm... <mailto:djc...@gm...>
>      > <mailto:djc...@gm...
>     <mailto:djc...@gm...>>> wrote:
>      >
>      >     im looking for some people who host http servers
>     (apache/nginx) and who
>      >     are familiar with mod_security and iptables firewalls
>      >     the setup that I am after is if an IP address hits my website and
>      >     does a
>      >     typical vuln scan my web server sends them back no response
>     and they
>      >     silently get added to an iptables ipset blacklist that lasts
>     for 1 week
>      >     I already have mod_security (OWASP RULES) on my apache 2
>     server at
>      >     (192.168.2.10) and a pfsense style firewall at (192.168.2.1)
>      >     kind of like a web server honeypot if you will
>      >     my current setup is already pretty powerful if you even send
>     a simple
>      >     TCP SYN packet to port 21,22 or even 23 you automatically get
>     added to
>      >     my routers firewall and dropped for 7 days for both in and
>     outbound
>      >     forgive me for asking alot but I really want to buckle down
>     on these
>      >     stupid automated vuln scanners and keep them off my network
>      >     I have already looked into things like fail2ban but that only
>     protects
>      >     the webserver itself and does not integrate with my routers
>     firewall at
>      >     all protecting the network as a whole
> 
> 
>     _______________________________________________
>     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/>

Re: [mod-security-users] apache 2 mod_security iptables

[jin&hitman&Barracuda <jin...@gm...>]

Hi,

I'm not here to argue about iptables (or ipsets) and i did not say that
every and each address needs a iptables rule. I just said, a lot easier
than *iptables*. At the time ipsets introduced, there was some design flaw
like;

- ipsets did not support to load host (/32) address and networks into
single table. It needs to be load i as separate tables.
- under same conditions and same hardware, ipsets was need more time to
load/reload sets/tables than pf.
- When you need to use a file to load sample of addresses, you need to
specifically design that file because ipset doesn't support to load a list
of address from a simple text file. Each and every line should be start
with "add" key word and should continue with "<ipset_name>" and "ip
address". Also you have to add ipset create stanza on the very beginning of
that file. On the contrary, pf can load address from a simple file and yet
there is no need to add anything to that file or divide address list into
host address and network address.

I did not use ipsets after than rhel6, there must be some improvements but
i doubt that it will be useful as pf does.

On Sat, Dec 26, 2020 at 12:46 PM Reindl Harald <h.r...@th...>
wrote:

>
>
> Am 26.12.20 um 10:11 schrieb jin&hitman&Barracuda:
> > Hi,
> >
> > I've used failban for a bunch of smtp servers and it didn't go well. But
> > there is another project (crowdsec) and i guess that it is worth to
> > mention here. The project have many features which failban don't have. I
> > haven't try it yet but i will soon. May be you'd like to look at it.
> >
> > Crowdsec: A Fail2Ban alternative written in Go -
> > https://github.com/crowdsecurity/crowdsec
> > <https://github.com/crowdsecurity/crowdsec>
> >
> > By the way, while i was using failban, i had a script (which i wrote) to
> > add/remove ip adresses to openbsd firewall which is a lot easier than
> > iptables.
>
> you don't write iptables rules for each and every address
>
> https://ipset.netfilter.org/ is your friend
> https://ipset.netfilter.org/ipset.man.html
>
> * you have *one* iptables rule with the ipset match
> * one command adds or removes and ip to the set
> * it's dramatically faster -> hash-table
> * you can block millions of ips without performance drop
>
> > On Sat, Dec 26, 2020, 11:37 Jeffery Wilkins <djc...@gm...
> > <mailto:djc...@gm...>> wrote:
> >
> >     im looking for some people who host http servers (apache/nginx) and
> who
> >     are familiar with mod_security and iptables firewalls
> >     the setup that I am after is if an IP address hits my website and
> >     does a
> >     typical vuln scan my web server sends them back no response and they
> >     silently get added to an iptables ipset blacklist that lasts for 1
> week
> >     I already have mod_security (OWASP RULES) on my apache 2 server at
> >     (192.168.2.10) and a pfsense style firewall at (192.168.2.1)
> >     kind of like a web server honeypot if you will
> >     my current setup is already pretty powerful if you even send a simple
> >     TCP SYN packet to port 21,22 or even 23 you automatically get added
> to
> >     my routers firewall and dropped for 7 days for both in and outbound
> >     forgive me for asking alot but I really want to buckle down on these
> >     stupid automated vuln scanners and keep them off my network
> >     I have already looked into things like fail2ban but that only
> protects
> >     the webserver itself and does not integrate with my routers firewall
> at
> >     all protecting the network as a whole
>
>
> _______________________________________________
> 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/
>


-- 
*There is no place like "/home"*
*Tuco (Benedicto Pacifico Juan Maria) Ramirez*

Re: [mod-security-users] apache 2 mod_security iptables

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

Am 26.12.20 um 10:42 schrieb Reindl Harald:
> 
> 
> Am 26.12.20 um 10:11 schrieb jin&hitman&Barracuda:
>> Hi,
>>
>> I've used failban for a bunch of smtp servers and it didn't go well. 
>> But there is another project (crowdsec) and i guess that it is worth 
>> to mention here. The project have many features which failban don't 
>> have. I haven't try it yet but i will soon. May be you'd like to look 
>> at it.
>>
>> Crowdsec: A Fail2Ban alternative written in Go - 
>> https://github.com/crowdsecurity/crowdsec 
>> <https://github.com/crowdsecurity/crowdsec>
>>
>> By the way, while i was using failban, i had a script (which i wrote) 
>> to add/remove ip adresses to openbsd firewall which is a lot easier 
>> than iptables.
> 
> you don't write iptables rules for each and every address
> 
> https://ipset.netfilter.org/ is your friend
> https://ipset.netfilter.org/ipset.man.html
> 
> * you have *one* iptables rule with the ipset match
> * one command adds or removes and ip to the set
> * it's dramatically faster -> hash-table
> * you can block millions of ips without performance drop

forgot the most important feature:
it supports auto-expire
you only care about add abusers

[root@firewall:~]$  ipset -L BLOCKED_DYNAMIC_PORTSCAN_IPV4 | head -n 50
Name: BLOCKED_DYNAMIC_PORTSCAN_IPV4
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 timeout 45
Size in memory: 98504
References: 3
Number of entries: 266
Members:
68.183.38.8 timeout 28
222.161.223.54 timeout 44
91.231.254.219 timeout 31
51.159.185.247 timeout 11
51.158.186.43 timeout 23
37.46.150.2 timeout 3
42.191.21.171 timeout 40
51.158.168.219 timeout 9
151.115.60.156 timeout 29
123.17.99.37 timeout 37
51.15.139.1 timeout 37
51.158.101.159 timeout 41
151.115.34.215 timeout 43
74.120.14.73 timeout 4
80.82.65.74 timeout 1
46.73.126.93 timeout 21
182.61.19.225 timeout 21
74.120.14.80 timeout 8
45.129.33.154 timeout 10
45.129.33.162 timeout 19
94.102.51.28 timeout 28
188.166.82.19 timeout 23
49.51.244.189 timeout 28
71.6.233.196 timeout 15
182.73.150.18 timeout 18
151.115.50.105 timeout 33
71.6.233.244 timeout 23
167.248.133.65 timeout 11
163.172.139.239 timeout 26
92.63.197.61 timeout 41
167.248.133.93 timeout 25
194.26.25.108 timeout 32
162.142.125.92 timeout 20
1.202.11.206 timeout 5
5.63.151.112 timeout 16
51.158.119.240 timeout 16
87.103.208.30 timeout 22
192.35.169.33 timeout 18
51.158.100.175 timeout 35
151.115.44.238 timeout 13
45.129.33.166 timeout 20
223.31.231.202 timeout 29
[root@firewall:~]$

Re: [mod-security-users] apache 2 mod_security iptables

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

Am 26.12.20 um 10:11 schrieb jin&hitman&Barracuda:
> Hi,
> 
> I've used failban for a bunch of smtp servers and it didn't go well. But 
> there is another project (crowdsec) and i guess that it is worth to 
> mention here. The project have many features which failban don't have. I 
> haven't try it yet but i will soon. May be you'd like to look at it.
> 
> Crowdsec: A Fail2Ban alternative written in Go - 
> https://github.com/crowdsecurity/crowdsec 
> <https://github.com/crowdsecurity/crowdsec>
> 
> By the way, while i was using failban, i had a script (which i wrote) to 
> add/remove ip adresses to openbsd firewall which is a lot easier than 
> iptables.

you don't write iptables rules for each and every address

https://ipset.netfilter.org/ is your friend
https://ipset.netfilter.org/ipset.man.html

* you have *one* iptables rule with the ipset match
* one command adds or removes and ip to the set
* it's dramatically faster -> hash-table
* you can block millions of ips without performance drop

> On Sat, Dec 26, 2020, 11:37 Jeffery Wilkins <djc...@gm... 
> <mailto:djc...@gm...>> wrote:
> 
>     im looking for some people who host http servers (apache/nginx) and who
>     are familiar with mod_security and iptables firewalls
>     the setup that I am after is if an IP address hits my website and
>     does a
>     typical vuln scan my web server sends them back no response and they
>     silently get added to an iptables ipset blacklist that lasts for 1 week
>     I already have mod_security (OWASP RULES) on my apache 2 server at
>     (192.168.2.10) and a pfsense style firewall at (192.168.2.1)
>     kind of like a web server honeypot if you will
>     my current setup is already pretty powerful if you even send a simple
>     TCP SYN packet to port 21,22 or even 23 you automatically get added to
>     my routers firewall and dropped for 7 days for both in and outbound
>     forgive me for asking alot but I really want to buckle down on these
>     stupid automated vuln scanners and keep them off my network
>     I have already looked into things like fail2ban but that only protects
>     the webserver itself and does not integrate with my routers firewall at
>     all protecting the network as a whole

Re: [mod-security-users] apache 2 mod_security iptables

[jin&hitman&Barracuda <jin...@gm...>]

Hi,

I've used failban for a bunch of smtp servers and it didn't go well. But
there is another project (crowdsec) and i guess that it is worth to mention
here. The project have many features which failban don't have. I haven't
try it yet but i will soon. May be you'd like to look at it.

Crowdsec: A Fail2Ban alternative written in Go -
https://github.com/crowdsecurity/crowdsec

By the way, while i was using failban, i had a script (which i wrote) to
add/remove ip adresses to openbsd firewall which is a lot easier than
iptables.

On Sat, Dec 26, 2020, 11:37 Jeffery Wilkins <djc...@gm...>
wrote:

> im looking for some people who host http servers (apache/nginx) and who
> are familiar with mod_security and iptables firewalls
> the setup that I am after is if an IP address hits my website and does a
> typical vuln scan my web server sends them back no response and they
> silently get added to an iptables ipset blacklist that lasts for 1 week
> I already have mod_security (OWASP RULES) on my apache 2 server at
> (192.168.2.10) and a pfsense style firewall at (192.168.2.1)
> kind of like a web server honeypot if you will
> my current setup is already pretty powerful if you even send a simple
> TCP SYN packet to port 21,22 or even 23 you automatically get added to
> my routers firewall and dropped for 7 days for both in and outbound
> forgive me for asking alot but I really want to buckle down on these
> stupid automated vuln scanners and keep them off my network
> I have already looked into things like fail2ban but that only protects
> the webserver itself and does not integrate with my routers firewall at
> all protecting the network as a whole
>
>
> _______________________________________________
> 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] apache 2 mod_security iptables

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

Am 26.12.20 um 10:15 schrieb Jeffery Wilkins:
> im looking for some people who host http servers (apache/nginx) and who 
> are familiar with mod_security and iptables firewalls
> the setup that I am after is if an IP address hits my website and does a 
> typical vuln scan my web server sends them back no response and they 
> silently get added to an iptables ipset blacklist that lasts for 1 week
> I already have mod_security (OWASP RULES) on my apache 2 server at 
> (192.168.2.10) and a pfsense style firewall at (192.168.2.1)
> kind of like a web server honeypot if you will
> my current setup is already pretty powerful if you even send a simple 
> TCP SYN packet to port 21,22 or even 23 you automatically get added to 
> my routers firewall and dropped for 7 days for both in and outbound
> forgive me for asking alot but I really want to buckle down on these 
> stupid automated vuln scanners and keep them off my network
> I have already looked into things like fail2ban but that only protects 
> the webserver itself and does not integrate with my routers firewall at 
> all protecting the network as a whole

you need some log parsing and do it outside the webserver

modsec runs inside the webserver and if it would be possible to interact 
with iptables rules from a webserver process you would have a much 
larger problem

my httpd can't even access shells thanks to systemd

ProtectSystem=strict
ReadWritePaths=-/data/www
ReadWritePaths=-/data/xdebug
ReadWritePaths=-/run/httpd
ReadWritePaths=-/tmp
ReadWritePaths=-/var/log
ReadWritePaths=-/var/www/sessiondata
ReadWritePaths=-/var/www/uploadtemp

InaccessiblePaths=-/etc/anacrontab
InaccessiblePaths=-/etc/cron.allow
InaccessiblePaths=-/etc/cron.deny
InaccessiblePaths=-/etc/crontab
InaccessiblePaths=-/etc/crypttab
InaccessiblePaths=-/etc/fstab
InaccessiblePaths=-/etc/shadow
InaccessiblePaths=-/etc/shadow-

InaccessiblePaths=-/etc/nftables
InaccessiblePaths=-/etc/sysconfig/ip6tables-config
InaccessiblePaths=-/etc/sysconfig/ipset
InaccessiblePaths=-/etc/sysconfig/iptables
InaccessiblePaths=-/etc/sysconfig/iptables-config
InaccessiblePaths=-/etc/sysconfig/nftables.conf
InaccessiblePaths=-/etc/systemd/system/network-up.service
InaccessiblePaths=-/etc/systemd/system/vpn.service
InaccessiblePaths=-/etc/wireguard
InaccessiblePaths=-/usr/libexec/arptables-helper
InaccessiblePaths=-/usr/libexec/arptables-nft-helper
InaccessiblePaths=-/usr/libexec/initscripts
InaccessiblePaths=-/usr/libexec/iptables
InaccessiblePaths=-/usr/libexec/sudo
InaccessiblePaths=-/usr/libexec/udisks2
InaccessiblePaths=-/usr/sbin/arptables
InaccessiblePaths=-/usr/sbin/arptables-nft
InaccessiblePaths=-/usr/sbin/arptables-nft-restore
InaccessiblePaths=-/usr/sbin/arptables-nft-save
InaccessiblePaths=-/usr/sbin/arptables-restore
InaccessiblePaths=-/usr/sbin/arptables-save
InaccessiblePaths=-/usr/sbin/ebtables
InaccessiblePaths=-/usr/sbin/ebtables-nft
InaccessiblePaths=-/usr/sbin/ebtables-nft-restore
InaccessiblePaths=-/usr/sbin/ebtables-nft-save
InaccessiblePaths=-/usr/sbin/ebtables-restore
InaccessiblePaths=-/usr/sbin/ebtables-save
InaccessiblePaths=-/usr/sbin/ip6tables
InaccessiblePaths=-/usr/sbin/ip6tables-nft
InaccessiblePaths=-/usr/sbin/ip6tables-nft-restore
InaccessiblePaths=-/usr/sbin/ip6tables-nft-save
InaccessiblePaths=-/usr/sbin/ip6tables-restore
InaccessiblePaths=-/usr/sbin/ip6tables-restore-translate
InaccessiblePaths=-/usr/sbin/ip6tables-save
InaccessiblePaths=-/usr/sbin/ip6tables-translate
InaccessiblePaths=-/usr/sbin/ipset
InaccessiblePaths=-/usr/sbin/iptables
InaccessiblePaths=-/usr/sbin/iptables-apply
InaccessiblePaths=-/usr/sbin/iptables-nft
InaccessiblePaths=-/usr/sbin/iptables-nft-restore
InaccessiblePaths=-/usr/sbin/iptables-nft-save
InaccessiblePaths=-/usr/sbin/iptables-restore
InaccessiblePaths=-/usr/sbin/iptables-restore-translate
InaccessiblePaths=-/usr/sbin/iptables-save
InaccessiblePaths=-/usr/sbin/iptables-translate
InaccessiblePaths=-/usr/sbin/nfbpf_compile
InaccessiblePaths=-/usr/sbin/nft
InaccessiblePaths=-/usr/sbin/xtables-monitor
InaccessiblePaths=-/usr/sbin/xtables-multi
InaccessiblePaths=-/usr/sbin/xtables-nft-multi

InaccessiblePaths=-/usr/sbin/agetty
InaccessiblePaths=-/usr/sbin/alsactl
InaccessiblePaths=-/usr/sbin/anacron
InaccessiblePaths=-/usr/sbin/apachectl
InaccessiblePaths=-/usr/sbin/arp
InaccessiblePaths=-/usr/sbin/arpd
InaccessiblePaths=-/usr/sbin/arping
InaccessiblePaths=-/usr/sbin/auditctl
InaccessiblePaths=-/usr/sbin/blkdiscard
InaccessiblePaths=-/usr/sbin/brctl
InaccessiblePaths=-/usr/sbin/bridge
InaccessiblePaths=-/usr/sbin/cfdisk
InaccessiblePaths=-/usr/sbin/chkconfig
InaccessiblePaths=-/usr/sbin/consoletype
InaccessiblePaths=-/usr/sbin/crond
InaccessiblePaths=-/usr/sbin/ctstat
InaccessiblePaths=-/usr/sbin/cupsctl
InaccessiblePaths=-/usr/sbin/delpart
InaccessiblePaths=-/usr/sbin/devlink
InaccessiblePaths=-/usr/sbin/efibootdump
InaccessiblePaths=-/usr/sbin/efibootmgr
InaccessiblePaths=-/usr/sbin/ether-wake
InaccessiblePaths=-/usr/sbin/ethtool
InaccessiblePaths=-/usr/sbin/fdformat
InaccessiblePaths=-/usr/sbin/fdisk
InaccessiblePaths=-/usr/sbin/fping
InaccessiblePaths=-/usr/sbin/fsck
InaccessiblePaths=-/usr/sbin/fsfreeze
InaccessiblePaths=-/usr/sbin/fuser
InaccessiblePaths=-/usr/sbin/genhostid
InaccessiblePaths=-/usr/sbin/genl
InaccessiblePaths=-/usr/sbin/groupadd
InaccessiblePaths=-/usr/sbin/grub2-bios-setup
InaccessiblePaths=-/usr/sbin/grub2-install
InaccessiblePaths=-/usr/sbin/grub2-macbless
InaccessiblePaths=-/usr/sbin/grub2-mkconfig
InaccessiblePaths=-/usr/sbin/grub2-reboot
InaccessiblePaths=-/usr/sbin/grub2-rpm-sort
InaccessiblePaths=-/usr/sbin/grub2-switch-to-blscfg
InaccessiblePaths=-/usr/sbin/hwclock
InaccessiblePaths=-/usr/sbin/ifcfg
InaccessiblePaths=-/usr/sbin/ifconfig
InaccessiblePaths=-/usr/sbin/ifdown
InaccessiblePaths=-/usr/sbin/ifstat
InaccessiblePaths=-/usr/sbin/ifup
InaccessiblePaths=-/usr/sbin/insmod
InaccessiblePaths=-/usr/sbin/ip
InaccessiblePaths=-/usr/sbin/ipmaddr
InaccessiblePaths=-/usr/sbin/iptunnel
InaccessiblePaths=-/usr/sbin/lnstat
InaccessiblePaths=-/usr/sbin/logwatch
InaccessiblePaths=-/usr/sbin/lsmod
InaccessiblePaths=-/usr/sbin/lspci
InaccessiblePaths=-/usr/sbin/mii-diag
InaccessiblePaths=-/usr/sbin/mii-tool
InaccessiblePaths=-/usr/sbin/mkfs
InaccessiblePaths=-/usr/sbin/mkfs.btrfs
InaccessiblePaths=-/usr/sbin/mkfs.cramfs
InaccessiblePaths=-/usr/sbin/mkfs.exfat
InaccessiblePaths=-/usr/sbin/mkfs.ext2
InaccessiblePaths=-/usr/sbin/mkfs.ext3
InaccessiblePaths=-/usr/sbin/mkfs.ext4
InaccessiblePaths=-/usr/sbin/mkfs.f2fs
InaccessiblePaths=-/usr/sbin/mkfs.fat
InaccessiblePaths=-/usr/sbin/mkfs.minix
InaccessiblePaths=-/usr/sbin/mkfs.msdos
InaccessiblePaths=-/usr/sbin/mkfs.ntfs
InaccessiblePaths=-/usr/sbin/mkfs.udf
InaccessiblePaths=-/usr/sbin/mkfs.vfat
InaccessiblePaths=-/usr/sbin/mkfs.xfs
InaccessiblePaths=-/usr/sbin/mkswap
InaccessiblePaths=-/usr/sbin/modprobe
InaccessiblePaths=-/usr/sbin/nameif
InaccessiblePaths=-/usr/sbin/netreport
InaccessiblePaths=-/usr/sbin/netscsid
InaccessiblePaths=-/usr/sbin/nstat
InaccessiblePaths=-/usr/sbin/parted
InaccessiblePaths=-/usr/sbin/partprobe
InaccessiblePaths=-/usr/sbin/partx
InaccessiblePaths=-/usr/sbin/pidof
InaccessiblePaths=-/usr/sbin/ping
InaccessiblePaths=-/usr/sbin/ping6
InaccessiblePaths=-/usr/sbin/plipconfig
InaccessiblePaths=-/usr/sbin/poweroff
InaccessiblePaths=-/usr/sbin/rdma
InaccessiblePaths=-/usr/sbin/reboot
InaccessiblePaths=-/usr/sbin/rmmod
InaccessiblePaths=-/usr/sbin/rndc
InaccessiblePaths=-/usr/sbin/rndc-confgen
InaccessiblePaths=-/usr/sbin/route
InaccessiblePaths=-/usr/sbin/routef
InaccessiblePaths=-/usr/sbin/routel
InaccessiblePaths=-/usr/sbin/rsyslogd
InaccessiblePaths=-/usr/sbin/rtacct
InaccessiblePaths=-/usr/sbin/rtkitctl
InaccessiblePaths=-/usr/sbin/rtmon
InaccessiblePaths=-/usr/sbin/rtpr
InaccessiblePaths=-/usr/sbin/rtstat
InaccessiblePaths=-/usr/sbin/runuser
InaccessiblePaths=-/usr/sbin/service
InaccessiblePaths=-/usr/sbin/setcap
InaccessiblePaths=-/usr/sbin/setenforce
InaccessiblePaths=-/usr/sbin/setpci
InaccessiblePaths=-/usr/sbin/setquota
InaccessiblePaths=-/usr/sbin/setsebool
InaccessiblePaths=-/usr/sbin/sfdisk
InaccessiblePaths=-/usr/sbin/slattach
InaccessiblePaths=-/usr/sbin/smartctl
InaccessiblePaths=-/usr/sbin/smbios-battery-ctl
InaccessiblePaths=-/usr/sbin/smbios-keyboard-ctl
InaccessiblePaths=-/usr/sbin/smbios-state-byte-ctl
InaccessiblePaths=-/usr/sbin/smbios-thermal-ctl
InaccessiblePaths=-/usr/sbin/smbios-token-ctl
InaccessiblePaths=-/usr/sbin/smbios-upflag-ctl
InaccessiblePaths=-/usr/sbin/smbios-wakeup-ctl
InaccessiblePaths=-/usr/sbin/smbios-wireless-ctl
InaccessiblePaths=-/usr/sbin/smokeping
InaccessiblePaths=-/usr/sbin/ss
InaccessiblePaths=-/usr/sbin/sshd
InaccessiblePaths=-/usr/sbin/sushell
InaccessiblePaths=-/usr/sbin/swapon
InaccessiblePaths=-/usr/sbin/sysctl
InaccessiblePaths=-/usr/sbin/sys-unconfig
InaccessiblePaths=-/usr/sbin/tipc
InaccessiblePaths=-/usr/sbin/tunctl
InaccessiblePaths=-/usr/sbin/unhide
InaccessiblePaths=-/usr/sbin/unhide_rb
InaccessiblePaths=-/usr/sbin/unhide-tcp
InaccessiblePaths=-/usr/sbin/useradd
InaccessiblePaths=-/usr/sbin/usermod
InaccessiblePaths=-/usr/sbin/usernetctl
InaccessiblePaths=-/usr/sbin/wipefs
InaccessiblePaths=-/usr/sbin/zramctl

InaccessiblePaths=-/usr/bin/alsaloop
InaccessiblePaths=-/usr/bin/alsamixer
InaccessiblePaths=-/usr/bin/alsatplg
InaccessiblePaths=-/usr/bin/alsaucm
InaccessiblePaths=-/usr/bin/alsaunmute
InaccessiblePaths=-/usr/bin/attr
InaccessiblePaths=-/usr/bin/balooctl
InaccessiblePaths=-/usr/bin/bash
InaccessiblePaths=-/usr/bin/bootctl
InaccessiblePaths=-/usr/bin/busctl
InaccessiblePaths=-/usr/bin/chacl
InaccessiblePaths=-/usr/bin/chattr
InaccessiblePaths=-/usr/bin/cmp
InaccessiblePaths=-/usr/bin/coredumpctl
InaccessiblePaths=-/usr/bin/crontab
InaccessiblePaths=-/usr/bin/csh
InaccessiblePaths=-/usr/bin/dash
InaccessiblePaths=-/usr/bin/dd
InaccessiblePaths=-/usr/bin/df
InaccessiblePaths=-/usr/bin/diff
InaccessiblePaths=-/usr/bin/diff3
InaccessiblePaths=-/usr/bin/dmesg
InaccessiblePaths=-/usr/bin/dnf
InaccessiblePaths=-/usr/bin/dotty
InaccessiblePaths=-/usr/bin/dracut
InaccessiblePaths=-/usr/bin/evmctl
InaccessiblePaths=-/usr/bin/free
InaccessiblePaths=-/usr/bin/ftp
InaccessiblePaths=-/usr/bin/getfacl
InaccessiblePaths=-/usr/bin/getfattr
InaccessiblePaths=-/usr/bin/grotty
InaccessiblePaths=-/usr/bin/grub2-file
InaccessiblePaths=-/usr/bin/grub2-menulst2cfg
InaccessiblePaths=-/usr/bin/grub2-mkimage
InaccessiblePaths=-/usr/bin/grub2-mkrelpath
InaccessiblePaths=-/usr/bin/grub2-render-label
InaccessiblePaths=-/usr/bin/grub2-script-check
InaccessiblePaths=-/usr/bin/hostnamectl
InaccessiblePaths=-/usr/bin/htop
InaccessiblePaths=-/usr/bin/ipcmk
InaccessiblePaths=-/usr/bin/journalctl
InaccessiblePaths=-/usr/bin/keyctl
InaccessiblePaths=-/usr/bin/kill
InaccessiblePaths=-/usr/bin/killall
InaccessiblePaths=-/usr/bin/ksh
InaccessiblePaths=-/usr/bin/last
InaccessiblePaths=-/usr/bin/localectl
InaccessiblePaths=-/usr/bin/locate
InaccessiblePaths=-/usr/bin/loginctl
InaccessiblePaths=-/usr/bin/ls
InaccessiblePaths=-/usr/bin/lsattr
InaccessiblePaths=-/usr/bin/lsblk
InaccessiblePaths=-/usr/bin/lsb_release
InaccessiblePaths=-/usr/bin/lscpu
InaccessiblePaths=-/usr/bin/lsdiff
InaccessiblePaths=-/usr/bin/lsinitrd
InaccessiblePaths=-/usr/bin/lsipc
InaccessiblePaths=-/usr/bin/lslocks
InaccessiblePaths=-/usr/bin/lslogins
InaccessiblePaths=-/usr/bin/lsmem
InaccessiblePaths=-/usr/bin/lsns
InaccessiblePaths=-/usr/bin/lsof
InaccessiblePaths=-/usr/bin/lsscsi
InaccessiblePaths=-/usr/bin/lsusb
InaccessiblePaths=-/usr/bin/lua
InaccessiblePaths=-/usr/bin/lynis
InaccessiblePaths=-/usr/bin/mail
InaccessiblePaths=-/usr/bin/mkfifo
InaccessiblePaths=-/usr/bin/mkinitrd
InaccessiblePaths=-/usr/bin/mkisofs
InaccessiblePaths=-/usr/bin/mknod
InaccessiblePaths=-/usr/bin/mount
InaccessiblePaths=-/usr/bin/mountpoint
InaccessiblePaths=-/usr/bin/nc
InaccessiblePaths=-/usr/bin/netcap
InaccessiblePaths=-/usr/bin/netstat
InaccessiblePaths=-/usr/bin/netstat-nat
InaccessiblePaths=-/usr/bin/networkctl
InaccessiblePaths=-/usr/bin/nmap
InaccessiblePaths=-/usr/bin/nping
InaccessiblePaths=-/usr/bin/nsenter
InaccessiblePaths=-/usr/bin/pactl
InaccessiblePaths=-/usr/bin/panelctl
InaccessiblePaths=-/usr/bin/passwd
InaccessiblePaths=-/usr/bin/peekfd
InaccessiblePaths=-/usr/bin/pgrep
InaccessiblePaths=-/usr/bin/pidof
InaccessiblePaths=-/usr/bin/ping
InaccessiblePaths=-/usr/bin/pkill
InaccessiblePaths=-/usr/bin/pkttyagent
InaccessiblePaths=-/usr/bin/pmap
InaccessiblePaths=-/usr/bin/portablectl
InaccessiblePaths=-/usr/bin/prtstat
InaccessiblePaths=-/usr/bin/ps
InaccessiblePaths=-/usr/bin/pslog
InaccessiblePaths=-/usr/bin/pstree
InaccessiblePaths=-/usr/bin/pstree.x11
InaccessiblePaths=-/usr/bin/pulseaudio
InaccessiblePaths=-/usr/bin/pwdx
InaccessiblePaths=-/usr/bin/python
InaccessiblePaths=-/usr/bin/python2
InaccessiblePaths=-/usr/bin/python3
InaccessiblePaths=-/usr/bin/resolvectl
InaccessiblePaths=-/usr/bin/rkhunter
InaccessiblePaths=-/usr/bin/rpm
InaccessiblePaths=-/usr/bin/rsync
InaccessiblePaths=-/usr/bin/ruby
InaccessiblePaths=-/usr/bin/scp
InaccessiblePaths=-/usr/bin/screen
InaccessiblePaths=-/usr/bin/sdiff
InaccessiblePaths=-/usr/bin/setarch
InaccessiblePaths=-/usr/bin/setcifsacl
InaccessiblePaths=-/usr/bin/setfacl
InaccessiblePaths=-/usr/bin/setfattr
InaccessiblePaths=-/usr/bin/setpriv
InaccessiblePaths=-/usr/bin/setsid
InaccessiblePaths=-/usr/bin/setterm
InaccessiblePaths=-/usr/bin/setxkbmap
InaccessiblePaths=-/usr/bin/sftp
InaccessiblePaths=-/usr/bin/sh
InaccessiblePaths=-/usr/bin/skill
InaccessiblePaths=-/usr/bin/slabtop
InaccessiblePaths=-/usr/bin/snice
InaccessiblePaths=-/usr/bin/ssh
InaccessiblePaths=-/usr/bin/ssh-add
InaccessiblePaths=-/usr/bin/ssh-agent
InaccessiblePaths=-/usr/bin/ssh-copy-id
InaccessiblePaths=-/usr/bin/ssh-keyscan
InaccessiblePaths=-/usr/bin/strace
InaccessiblePaths=-/usr/bin/strace-log-merg
InaccessiblePaths=-/usr/bin/stty
InaccessiblePaths=-/usr/bin/su
InaccessiblePaths=-/usr/bin/sudo
InaccessiblePaths=-/usr/bin/systemctl
InaccessiblePaths=-/usr/bin/systemd-tty-ask-password-agent
InaccessiblePaths=-/usr/bin/tcl
InaccessiblePaths=-/usr/bin/tcptraceroute
InaccessiblePaths=-/usr/bin/tcsh
InaccessiblePaths=-/usr/bin/telnet
InaccessiblePaths=-/usr/bin/timedatectl
InaccessiblePaths=-/usr/bin/tload
InaccessiblePaths=-/usr/bin/top
InaccessiblePaths=-/usr/bin/tracepath
InaccessiblePaths=-/usr/bin/traceroute
InaccessiblePaths=-/usr/bin/traceroute6
InaccessiblePaths=-/usr/bin/tricklectl
InaccessiblePaths=-/usr/bin/tty
InaccessiblePaths=-/usr/bin/udisksctl
InaccessiblePaths=-/usr/bin/umount
InaccessiblePaths=-/usr/bin/updatedb
InaccessiblePaths=-/usr/bin/uptime
InaccessiblePaths=-/usr/bin/users
InaccessiblePaths=-/usr/bin/vmstat
InaccessiblePaths=-/usr/bin/vmtoolsd
InaccessiblePaths=-/usr/bin/vmware-checkvm
InaccessiblePaths=-/usr/bin/vmware-namespace-cmd
InaccessiblePaths=-/usr/bin/vmware-rpctool
InaccessiblePaths=-/usr/bin/vmware-toolbox-cmd
InaccessiblePaths=-/usr/bin/vmware-xferlogs
InaccessiblePaths=-/usr/bin/w
InaccessiblePaths=-/usr/bin/wall
InaccessiblePaths=-/usr/bin/watch
InaccessiblePaths=-/usr/bin/wdctl
InaccessiblePaths=-/usr/bin/wg
InaccessiblePaths=-/usr/bin/wget
InaccessiblePaths=-/usr/bin/who
InaccessiblePaths=-/usr/bin/whoami
InaccessiblePaths=-/usr/bin/zsh

InaccessiblePaths=-/boot
InaccessiblePaths=-/efi
InaccessiblePaths=-/media
InaccessiblePaths=-/run/media
InaccessiblePaths=-/run/mount

InaccessiblePaths=-/etc/cron.d
InaccessiblePaths=-/etc/cron.daily
InaccessiblePaths=-/etc/cron.hourly
InaccessiblePaths=-/etc/cron.monthly
InaccessiblePaths=-/etc/cron.weekly
InaccessiblePaths=-/etc/dbus-1
InaccessiblePaths=-/etc/modprobe.d
InaccessiblePaths=-/etc/modules-load.d
InaccessiblePaths=-/etc/postfix
InaccessiblePaths=-/etc/ssh
InaccessiblePaths=-/etc/sysctl.d
InaccessiblePaths=-/run/console
InaccessiblePaths=-/run/dbus
InaccessiblePaths=-/run/lock
InaccessiblePaths=-/run/systemd/generator
InaccessiblePaths=-/run/systemd/system
InaccessiblePaths=-/run/systemd/users
InaccessiblePaths=-/run/udev
InaccessiblePaths=-/usr/lib/.build-id
InaccessiblePaths=-/usr/lib/alsa
InaccessiblePaths=-/usr/lib/cpp
InaccessiblePaths=-/usr/lib/dracut
InaccessiblePaths=-/usr/lib/dtrace
InaccessiblePaths=-/usr/lib/firmware
InaccessiblePaths=-/usr/lib/gcc
InaccessiblePaths=-/usr/lib/grub
InaccessiblePaths=-/usr/lib/kernel
InaccessiblePaths=-/usr/lib/modprobe.d
InaccessiblePaths=-/usr/lib/modules
InaccessiblePaths=-/usr/lib/modules-load.d
InaccessiblePaths=-/usr/lib/rpm
InaccessiblePaths=-/usr/lib/sysctl.d
InaccessiblePaths=-/usr/lib/udev
InaccessiblePaths=-/usr/lib/vmware
InaccessiblePaths=-/usr/lib/vmware-installer
InaccessiblePaths=-/usr/lib/vmware-ovftool
InaccessiblePaths=-/usr/lib/vmware-vix
InaccessiblePaths=-/usr/lib64/dbus-1
InaccessiblePaths=-/usr/libexec/mlocate-run-updatedb
InaccessiblePaths=-/usr/libexec/openssh
InaccessiblePaths=-/usr/libexec/openssh/sftp-server
InaccessiblePaths=-/usr/libexec/openssh/sshd-keygen
InaccessiblePaths=-/usr/libexec/postfix
InaccessiblePaths=-/usr/local/scripts
InaccessiblePaths=-/var/db
InaccessiblePaths=-/var/lib/dbus
InaccessiblePaths=-/var/lib/dnf
InaccessiblePaths=-/var/lib/rpm
InaccessiblePaths=-/var/lib/systemd
InaccessiblePaths=-/var/spool/anacron
InaccessiblePaths=-/var/spool/clientmqueue
InaccessiblePaths=-/var/spool/cron
InaccessiblePaths=-/var/spool/exim
InaccessiblePaths=-/var/spool/hylafax
InaccessiblePaths=-/var/spool/lpd
InaccessiblePaths=-/var/spool/mail
InaccessiblePaths=-/var/spool/mqueue
InaccessiblePaths=-/var/spool/postfix
InaccessiblePaths=-/var/spool/squid
InaccessiblePaths=-/var/spool/uucp

[mod-security-users] apache 2 mod_security iptables

[Jeffery W. <djc...@gm...>]

im looking for some people who host http servers (apache/nginx) and who 
are familiar with mod_security and iptables firewalls
the setup that I am after is if an IP address hits my website and does a 
typical vuln scan my web server sends them back no response and they 
silently get added to an iptables ipset blacklist that lasts for 1 week
I already have mod_security (OWASP RULES) on my apache 2 server at 
(192.168.2.10) and a pfsense style firewall at (192.168.2.1)
kind of like a web server honeypot if you will
my current setup is already pretty powerful if you even send a simple 
TCP SYN packet to port 21,22 or even 23 you automatically get added to 
my routers firewall and dropped for 7 days for both in and outbound
forgive me for asking alot but I really want to buckle down on these 
stupid automated vuln scanners and keep them off my network
I have already looked into things like fail2ban but that only protects 
the webserver itself and does not integrate with my routers firewall at 
all protecting the network as a whole

[mod-security-users] modseccfg GUI (for Apache setups)

[mario <ma...@in...>]

So, this is probably not very interesting to professional users. But I
made a little tool to help with the initial setup of mod_security/CRS
rules. Specifically disabling potential conflicting rules.

It's a desktop GUI, not yet another web interface. But can be used
remotely nonetheless. It's fairly alpha still, but perhaps worth a
look:
https://pypi.org/project/modseccfg/

The log viewer isn't too useful yet. I'll probably add colorization
and filtering/search, or perhaps look for some log preprocessor
scripts to bundle. The JSON format at least seems workable to craft
some predictions from.
There's possibly also a [modify] dialog coming (SecRuleUpdateAction..),
even though I'm not sure if anyone would use a GUI for that. But it's
definitely never going to become a SecRule IDE. It's intended for
simpler needs really.

And let me quickly mention again that this is alpha quality.
Goes without saying, but DO NOT use it on production servers.

Re: [mod-security-users] Help configuring mod security

[Joshua J. <Jos...@uk...>]

Thankyou very much for this - I will give a go and let you know if I have any problems

-----Original Message-----
From: Ervin Hegedüs <ai...@gm...>
Sent: Tuesday, November 24, 2020 4:23 PM
To: mod...@li...
Subject: Re: [mod-security-users] Help configuring mod security

Hi Joshua,

On Tue, Nov 24, 2020 at 12:48:02PM +0000, Joshua Jenner wrote:
>
> I am using mod security with apache 2. It's working fine but I want to disable  one element of the rule MULTIPART_STRICT_ERROR. I want to just disable the Invalid quoting check. I've tried doing this by just deleting the line in my mod_security.conf file.

I'm afraid you can't do this - I mean, you can't "exclude" any item from the list below.

If you check the source, MULTIPART_STRICT_ERROR is a "cumulated"
variable:

https://github.com/SpiderLabs/ModSecurity/blob/v2/master/apache2/re_variables.c#L1582-L1596

if any variable from that list is set, the MULTIPART_STRICT_ERROR is also has a non-zero value.

> So just deleting the IQ line from here and restarting apache:
>
> SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
> "id:'200002',phase:2,t:none,log,deny,status:44,msg:'Multipart request
> body \ failed strict validation:
> PE %{REQBODY_PROCESSOR_ERROR}, \
> BQ %{MULTIPART_BOUNDARY_QUOTED}, \
> BW %{MULTIPART_BOUNDARY_WHITESPACE}, \ DB %{MULTIPART_DATA_BEFORE}, \
> DA %{MULTIPART_DATA_AFTER}, \ HF %{MULTIPART_HEADER_FOLDING}, \ LF
> %{MULTIPART_LF_LINE}, \ SM %{MULTIPART_MISSING_SEMICOLON}, \ IQ
> %{MULTIPART_INVALID_QUOTING}, \ IP %{MULTIPART_INVALID_PART}, \ IH
> %{MULTIPART_INVALID_HEADER_FOLDING}, \ FL
> %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

you can do that make a list of rules with all variables what you want to check. Eg:

SecRule REQBODY_PROCESSOR_ERROR|MULTIPART_BOUNDARY_QUOTED|MULTIPART_BOUNDARY_WHITESPACE|...|MULTIPART_FILE_LIMIT_EXCEEDED "!@eq 0" \
    "id:200002,\
    phase:2,\
    t:none,\
    log,\
    deny,\
    msg:'Multipart request body failed:
    PE %{REQBODY_PROCESSOR_ERROR}, \
    ....
    FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

and DO NOT put the MULTIPART_INVALID_QUOTING into the list of variables. (And don't forget to make a comment for original rule 200002, or add a unique id.)


Let me know if you have any question.



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/


This e-mail and any attachment are confidential and contain proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, please notify the author immediately by telephone or by replying to this e-mail, and then delete all copies of the e-mail on your system. If you are not the intended recipient, you must not use, disclose, distribute, copy, print or rely on this e- mail.

Whilst we have taken reasonable precautions to ensure that this e-mail and any attachment has been checked for viruses, we cannot guarantee that they are virus free and we cannot accept liability for any damage sustained as a result of software viruses. We would advise that you carry out your own virus checks, especially before opening an attachment.

EY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients.

The UK firm Ernst & Young LLP is a limited liability partnership registered in England and Wales with registered number OC300001 and is a member firm of Ernst & Young Global Limited. A list of members' names is available for inspection at 1 More London Place, London, SE1 2AF, the firm's principal place of business and its registered office. Associate Partners are not members of Ernst & Young LLP. Ernst & Young LLP is a multi-disciplinary practice and is authorised and regulated by the Institute of Chartered Accountants in England and Wales, the Solicitors Regulation Authority (authorisation number 614947), the Financial Conduct Authority (registration number 196203) and other regulators. Further details can be found at https://www.ey.com/en_uk/legal-statement