Thread: [mod-security-users] Possible to remove rules by multiple tags?
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users
|
From: Jamie B. <ja...@ib...> - 2020-06-16 22:58:53
|
Hi Is it possible to remove rules by more than one tag? For example, remove all “paranoia-level/2” “attack-sqli” CRS rules. This would be useful in situations where PL2 is in use, but certain groups of rules should not be at PL2. I was looking at doing this by ID range instead, but the IDs don’t seem facilitate ranges based on PL. Regards, Jamie |
|
From: Christian F. <chr...@ne...> - 2020-06-17 04:34:30
|
Hello Jamie, I have never throught about this, but it sounds like a cool idea. Unfortunately, it is not possible. On Tue, Jun 16, 2020 at 11:34:53PM +0100, Jamie Burchell wrote: > of rules should not be at PL2. I was looking at doing this by ID range > instead, but the IDs don’t seem facilitate ranges based on PL. The ids and the PL have no connection, that's correct. (And they can't since we are adding new rules from time to time and the concept of strict siblings would no longer work the way it does with the ID namespace) Ahoj, Christian > > > > Regards, > > 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/ |
|
From: Jamie B. <ja...@ib...> - 2020-06-17 07:58:40
|
OK, thank you. Is there a particular strategy or best practise for dealing with new untested rules that are added to the CRS? I'm thinking if you have tuned the rules, are running at PL2 and new ones are added in an update. It seems that any new rules would need to be identified and carefully managed in an existing setup, short of putting the whole install back in detection only mode and remonitoring. Thanks Jamie > On 17 Jun 2020, at 05:37, Christian Folini <chr...@ne...> wrote: > > Hello Jamie, > > I have never throught about this, but it sounds like a cool idea. > > Unfortunately, it is not possible. > >> On Tue, Jun 16, 2020 at 11:34:53PM +0100, Jamie Burchell wrote: >> of rules should not be at PL2. I was looking at doing this by ID range >> instead, but the IDs don’t seem facilitate ranges based on PL. > > The ids and the PL have no connection, that's correct. > > (And they can't since we are adding new rules from time to time and the > concept of strict siblings would no longer work the way it does with the > ID namespace) > > Ahoj, > > Christian > >> >> >> >> Regards, >> >> 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/ |
|
From: Christian F. <chr...@ne...> - 2020-06-17 08:47:42
|
You have a good way of asking the relevant questions Jamie. No, there is no established best practice for this very problem. I've been thinking about it quite some time, but I have not yet found an elegant solution (like the "executing paranoia level" solving the problem how to take a well-tuned system to a higher PL without also diluting your anomaly threshold setting). If you have something in mind, then please share. For me, the problem is related to the paradox, that when you write a rule exclusion against a false positive, you go blind on the false positive. And neither you, nor Schroedinger's cat can easily tell if wether the rule exclusion is still needed. It's like you want to see things that you do not want to see. Best, Christian On Wed, Jun 17, 2020 at 08:58:26AM +0100, Jamie Burchell wrote: > OK, thank you. Is there a particular strategy or best practise for dealing > with new untested rules that are added to the CRS? > > I'm thinking if you have tuned the rules, are running at PL2 and new ones > are added in an update. It seems that any new rules would need to be > identified and carefully managed in an existing setup, short of putting the > whole install back in detection only mode and remonitoring. > > Thanks Jamie > > > On 17 Jun 2020, at 05:37, Christian Folini <chr...@ne...> > > wrote: > > > > Hello Jamie, > > > > I have never throught about this, but it sounds like a cool idea. > > > > Unfortunately, it is not possible. > > > >> On Tue, Jun 16, 2020 at 11:34:53PM +0100, Jamie Burchell wrote: of rules > >> should not be at PL2. I was looking at doing this by ID range instead, > >> but the IDs don’t seem facilitate ranges based on PL. > > > > The ids and the PL have no connection, that's correct. > > > > (And they can't since we are adding new rules from time to time and the > > concept of strict siblings would no longer work the way it does with the > > ID namespace) > > > > Ahoj, > > > > Christian > > > >> > >> > >> > >> Regards, > >> > >> 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/ On Wed, Jun 17, 2020 at 08:58:26AM +0100, Jamie Burchell wrote: > OK, thank you. Is there a particular strategy or best practise for dealing with new untested rules that are added to the CRS? > > I'm thinking if you have tuned the rules, are running at PL2 and new ones are added in an update. It seems that any new rules would need to be identified and carefully managed in an existing setup, short of putting the whole install back in detection only mode and remonitoring. > > Thanks > Jamie > > > On 17 Jun 2020, at 05:37, Christian Folini <chr...@ne...> wrote: > > > > Hello Jamie, > > > > I have never throught about this, but it sounds like a cool idea. > > > > Unfortunately, it is not possible. > > > >> On Tue, Jun 16, 2020 at 11:34:53PM +0100, Jamie Burchell wrote: > >> of rules should not be at PL2. I was looking at doing this by ID range > >> instead, but the IDs don’t seem facilitate ranges based on PL. > > > > The ids and the PL have no connection, that's correct. > > > > (And they can't since we are adding new rules from time to time and the > > concept of strict siblings would no longer work the way it does with the > > ID namespace) > > > > Ahoj, > > > > Christian > > > >> > >> > >> > >> Regards, > >> > >> 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/ |
|
From: Jamie B. <ja...@ib...> - 2020-06-17 09:55:00
|
Thanks for your replies and time Christian, I appreciate it. I'm very new to the world of ModSecurity and CRS, so at this stage I have more questions than answers unfortunately! I've realised that actually this is extremely complicated and that the more you look at it, the more nuanced it is and I'm sporting a semi-permanent expression which is somewhere between wonderment and confusion. I initially just wanted to create a custom rate limiting rule to protect a few endpoints and also enable a specific PL2 rule for blocking scripting agents. I have come at this a bit backwards probably. Anyway, these rules have worked well, so I've been looking at enabling more of the CRS and reading through the documentation and also your tutorials on dealing with and filtering out false positives. You are spot on about not wanting to see things that you do. I enabled the rules to detect, for example, requests without an Accept header and without a User agent and these have now filled up the log, so it's almost impossible to "see past them". I want to log them, I want them to count towards the anomaly score, but the log is now unmanageable with them in place. For now I removed those rules. I started looking for some sort of GUI that could somehow sift through and summarise the entries that could then be drilled down in to, but have come up short, at least using the basic serial log. I have seen some of your posts where you summarise on the command line, these are helpful. The web server I'm experimenting on actually houses a few completely different virtual hosts, some web apps that are written by me and some third-party, so the setup is complex and of course now I'm faced with a huge log of false positives (and some true) from each different app, particularly in respect of XSS and SQLi against the admin area/back-end forms. And there are just too many places this sort of thing can crop up. For now, I started turning off the rule engine completely for the back-ends, which are IP protected, but that's almost certainly not the best way to handle things. Cheers Jamie > On 17 Jun 2020, at 09:50, Christian Folini <chr...@ne...> wrote: > > You have a good way of asking the relevant questions Jamie. > > No, there is no established best practice for this very problem. I've been > thinking about it quite some time, but I have not yet found an elegant > solution (like the "executing paranoia level" solving the problem how to take > a well-tuned system to a higher PL without also diluting your anomaly > threshold setting). > > If you have something in mind, then please share. > > For me, the problem is related to the paradox, that when you write a rule > exclusion against a false positive, you go blind on the false positive. And > neither you, nor Schroedinger's cat can easily tell if wether the rule > exclusion is still needed. It's like you want to see things that you do > not want to see. > > Best, > > Christian > > >> On Wed, Jun 17, 2020 at 08:58:26AM +0100, Jamie Burchell wrote: >> OK, thank you. Is there a particular strategy or best practise for dealing >> with new untested rules that are added to the CRS? >> >> I'm thinking if you have tuned the rules, are running at PL2 and new ones >> are added in an update. It seems that any new rules would need to be >> identified and carefully managed in an existing setup, short of putting the >> whole install back in detection only mode and remonitoring. >> >> Thanks Jamie >> >>> On 17 Jun 2020, at 05:37, Christian Folini <chr...@ne...> >>> wrote: >>> >>> Hello Jamie, >>> >>> I have never throught about this, but it sounds like a cool idea. >>> >>> Unfortunately, it is not possible. >>> >>>> On Tue, Jun 16, 2020 at 11:34:53PM +0100, Jamie Burchell wrote: of rules >>>> should not be at PL2. I was looking at doing this by ID range instead, >>>> but the IDs don’t seem facilitate ranges based on PL. >>> >>> The ids and the PL have no connection, that's correct. >>> >>> (And they can't since we are adding new rules from time to time and the >>> concept of strict siblings would no longer work the way it does with the >>> ID namespace) >>> >>> Ahoj, >>> >>> Christian >>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> 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/ > >> On Wed, Jun 17, 2020 at 08:58:26AM +0100, Jamie Burchell wrote: >> OK, thank you. Is there a particular strategy or best practise for dealing with new untested rules that are added to the CRS? >> >> I'm thinking if you have tuned the rules, are running at PL2 and new ones are added in an update. It seems that any new rules would need to be identified and carefully managed in an existing setup, short of putting the whole install back in detection only mode and remonitoring. >> >> Thanks >> Jamie >> >>>> On 17 Jun 2020, at 05:37, Christian Folini <chr...@ne...> wrote: >>> >>> Hello Jamie, >>> >>> I have never throught about this, but it sounds like a cool idea. >>> >>> Unfortunately, it is not possible. >>> >>>> On Tue, Jun 16, 2020 at 11:34:53PM +0100, Jamie Burchell wrote: >>>> of rules should not be at PL2. I was looking at doing this by ID range >>>> instead, but the IDs don’t seem facilitate ranges based on PL. >>> >>> The ids and the PL have no connection, that's correct. >>> >>> (And they can't since we are adding new rules from time to time and the >>> concept of strict siblings would no longer work the way it does with the >>> ID namespace) >>> >>> Ahoj, >>> >>> Christian >>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> 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/ > > > _______________________________________________ > 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/ |
|
From: Ervin H. <ai...@gm...> - 2020-06-17 09:56:03
Attachments:
crs_gettags.py
|
Hi Jamie,
as Christian wrote there isn't any solution to remove a rule by multiple
tags.
But there is an indirect solution: you can find all rules where the listed
tags exists.
There is a small tool, named msc_pyparser[1]. This Python library can parse
CRS rules and makes the AST (abstract syntax tree) in YAML or JSON format.
I attached a Python script which loads these rules and search all id where
the tags above listed. Before you run, you have to install that Python
library (it works only with Python3), it's available through PIP. First,
you have to build the AST files, then run script for each file, like:
for y in `ls -1 export/*.yaml`; do ./crs_gettags.py ${y}; done
and you'll see something like this:
SecRuleRemoveById 942110
SecRuleRemoveById 942120
SecRuleRemoveById 942130
SecRuleRemoveById 942150
SecRuleRemoveById 942180
SecRuleRemoveById 942200
SecRuleRemoveById 942210
SecRuleRemoveById 942260
SecRuleRemoveById 942300
SecRuleRemoveById 942310
SecRuleRemoveById 942330
SecRuleRemoveById 942340
SecRuleRemoveById 942361
SecRuleRemoveById 942370
SecRuleRemoveById 942380
SecRuleRemoveById 942390
SecRuleRemoveById 942400
SecRuleRemoveById 942410
SecRuleRemoveById 942470
SecRuleRemoveById 942480
SecRuleRemoveById 942430
SecRuleRemoveById 942440
SecRuleRemoveById 942450
SecRuleRemoveById 942510
Just paste these lines into your exceptions, and hope that will give you
what you want.
Regards,
a.
[1]: https://github.com/digitalwave/msc_pyparser
On Wed, Jun 17, 2020 at 1:01 AM Jamie Burchell <ja...@ib...> wrote:
> Hi
>
>
>
> Is it possible to remove rules by more than one tag? For example, remove
> all “paranoia-level/2” “attack-sqli” CRS rules.
>
>
>
> This would be useful in situations where PL2 is in use, but certain groups
> of rules should not be at PL2. I was looking at doing this by ID range
> instead, but the IDs don’t seem facilitate ranges based on PL.
>
>
>
> Regards,
>
> 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/
>
|
|
From: Jamie B. <ja...@ib...> - 2020-06-17 10:05:42
|
Hi
That's really useful, thank you.
Cheers
Jamie
> On 17 Jun 2020, at 10:58, Ervin Hegedüs <ai...@gm...> wrote:
>
>
> Hi Jamie,
>
> as Christian wrote there isn't any solution to remove a rule by multiple tags.
>
> But there is an indirect solution: you can find all rules where the listed tags exists.
>
> There is a small tool, named msc_pyparser[1]. This Python library can parse CRS rules and makes the AST (abstract syntax tree) in YAML or JSON format.
>
> I attached a Python script which loads these rules and search all id where the tags above listed. Before you run, you have to install that Python library (it works only with Python3), it's available through PIP. First, you have to build the AST files, then run script for each file, like:
>
> for y in `ls -1 export/*.yaml`; do ./crs_gettags.py ${y}; done
>
> and you'll see something like this:
>
> SecRuleRemoveById 942110
> SecRuleRemoveById 942120
> SecRuleRemoveById 942130
> SecRuleRemoveById 942150
> SecRuleRemoveById 942180
> SecRuleRemoveById 942200
> SecRuleRemoveById 942210
> SecRuleRemoveById 942260
> SecRuleRemoveById 942300
> SecRuleRemoveById 942310
> SecRuleRemoveById 942330
> SecRuleRemoveById 942340
> SecRuleRemoveById 942361
> SecRuleRemoveById 942370
> SecRuleRemoveById 942380
> SecRuleRemoveById 942390
> SecRuleRemoveById 942400
> SecRuleRemoveById 942410
> SecRuleRemoveById 942470
> SecRuleRemoveById 942480
> SecRuleRemoveById 942430
> SecRuleRemoveById 942440
> SecRuleRemoveById 942450
> SecRuleRemoveById 942510
>
> Just paste these lines into your exceptions, and hope that will give you what you want.
>
>
> Regards,
>
>
> a.
>
>
> [1]: https://github.com/digitalwave/msc_pyparser
>
>
>
>
>> On Wed, Jun 17, 2020 at 1:01 AM Jamie Burchell <ja...@ib...> wrote:
>> Hi
>>
>>
>>
>> Is it possible to remove rules by more than one tag? For example, remove all “paranoia-level/2” “attack-sqli” CRS rules.
>>
>>
>>
>> This would be useful in situations where PL2 is in use, but certain groups of rules should not be at PL2. I was looking at doing this by ID range instead, but the IDs don’t seem facilitate ranges based on PL.
>>
>>
>>
>> Regards,
>>
>> 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/
>
> <crs_gettags.py>
> _______________________________________________
> 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/
|
|
From: Ervin H. <ai...@gm...> - 2020-06-17 10:38:38
|
you're welcome - note, the list has been from CRS 3.3/dev, @c11baa.
Regards,
a.
On Wed, Jun 17, 2020 at 12:07 PM Jamie Burchell <ja...@ib...> wrote:
> Hi
>
> That's really useful, thank you.
>
> Cheers
> Jamie
>
> On 17 Jun 2020, at 10:58, Ervin Hegedüs <ai...@gm...> wrote:
>
>
> Hi Jamie,
>
> as Christian wrote there isn't any solution to remove a rule by multiple
> tags.
>
> But there is an indirect solution: you can find all rules where the listed
> tags exists.
>
> There is a small tool, named msc_pyparser[1]. This Python library can
> parse CRS rules and makes the AST (abstract syntax tree) in YAML or JSON
> format.
>
> I attached a Python script which loads these rules and search all id where
> the tags above listed. Before you run, you have to install that Python
> library (it works only with Python3), it's available through PIP. First,
> you have to build the AST files, then run script for each file, like:
>
> for y in `ls -1 export/*.yaml`; do ./crs_gettags.py ${y}; done
>
> and you'll see something like this:
>
> SecRuleRemoveById 942110
> SecRuleRemoveById 942120
> SecRuleRemoveById 942130
> SecRuleRemoveById 942150
> SecRuleRemoveById 942180
> SecRuleRemoveById 942200
> SecRuleRemoveById 942210
> SecRuleRemoveById 942260
> SecRuleRemoveById 942300
> SecRuleRemoveById 942310
> SecRuleRemoveById 942330
> SecRuleRemoveById 942340
> SecRuleRemoveById 942361
> SecRuleRemoveById 942370
> SecRuleRemoveById 942380
> SecRuleRemoveById 942390
> SecRuleRemoveById 942400
> SecRuleRemoveById 942410
> SecRuleRemoveById 942470
> SecRuleRemoveById 942480
> SecRuleRemoveById 942430
> SecRuleRemoveById 942440
> SecRuleRemoveById 942450
> SecRuleRemoveById 942510
>
> Just paste these lines into your exceptions, and hope that will give you
> what you want.
>
>
> Regards,
>
>
> a.
>
>
> [1]: https://github.com/digitalwave/msc_pyparser
>
>
>
>
> On Wed, Jun 17, 2020 at 1:01 AM Jamie Burchell <ja...@ib...> wrote:
>
>> Hi
>>
>>
>>
>> Is it possible to remove rules by more than one tag? For example, remove
>> all “paranoia-level/2” “attack-sqli” CRS rules.
>>
>>
>>
>> This would be useful in situations where PL2 is in use, but certain
>> groups of rules should not be at PL2. I was looking at doing this by ID
>> range instead, but the IDs don’t seem facilitate ranges based on PL.
>>
>>
>>
>> Regards,
>>
>> 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/
>>
> <crs_gettags.py>
> _______________________________________________
> 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/
>
|
|
From: Christian F. <chr...@ne...> - 2020-06-19 05:48:20
|
This is quite neat, Ervin! Thanks for sharing.
Christian
On Wed, Jun 17, 2020 at 11:55:19AM +0200, Ervin Hegedüs wrote:
> Hi Jamie,
>
> as Christian wrote there isn't any solution to remove a rule by multiple
> tags.
>
> But there is an indirect solution: you can find all rules where the listed
> tags exists.
>
> There is a small tool, named msc_pyparser[1]. This Python library can parse
> CRS rules and makes the AST (abstract syntax tree) in YAML or JSON format.
>
> I attached a Python script which loads these rules and search all id where
> the tags above listed. Before you run, you have to install that Python
> library (it works only with Python3), it's available through PIP. First,
> you have to build the AST files, then run script for each file, like:
>
> for y in `ls -1 export/*.yaml`; do ./crs_gettags.py ${y}; done
>
> and you'll see something like this:
>
> SecRuleRemoveById 942110
> SecRuleRemoveById 942120
> SecRuleRemoveById 942130
> SecRuleRemoveById 942150
> SecRuleRemoveById 942180
> SecRuleRemoveById 942200
> SecRuleRemoveById 942210
> SecRuleRemoveById 942260
> SecRuleRemoveById 942300
> SecRuleRemoveById 942310
> SecRuleRemoveById 942330
> SecRuleRemoveById 942340
> SecRuleRemoveById 942361
> SecRuleRemoveById 942370
> SecRuleRemoveById 942380
> SecRuleRemoveById 942390
> SecRuleRemoveById 942400
> SecRuleRemoveById 942410
> SecRuleRemoveById 942470
> SecRuleRemoveById 942480
> SecRuleRemoveById 942430
> SecRuleRemoveById 942440
> SecRuleRemoveById 942450
> SecRuleRemoveById 942510
>
> Just paste these lines into your exceptions, and hope that will give you
> what you want.
>
>
> Regards,
>
>
> a.
>
>
> [1]: https://github.com/digitalwave/msc_pyparser
>
>
>
>
> On Wed, Jun 17, 2020 at 1:01 AM Jamie Burchell <ja...@ib...> wrote:
>
> > Hi
> >
> >
> >
> > Is it possible to remove rules by more than one tag? For example, remove
> > all “paranoia-level/2” “attack-sqli” CRS rules.
> >
> >
> >
> > This would be useful in situations where PL2 is in use, but certain groups
> > of rules should not be at PL2. I was looking at doing this by ID range
> > instead, but the IDs don’t seem facilitate ranges based on PL.
> >
> >
> >
> > Regards,
> >
> > 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/
> >
> #!/usr/bin/env python3
>
> import sys
> import yaml
>
> class Transform(object):
> def __init__(self, data):
> self.data = data
> self.lineno = 1
> self.current_ruleid = 0
> self.chained = False
> self.chainlevel = 0
>
> def gettag(self):
> tags = []
> for d in self.data:
> if "actions" in d:
> aidx = 0
> if self.chained == True:
> self.chained = False
> while aidx < len(d['actions']):
> a = d['actions'][aidx]
>
> if a['act_name'] == "tag":
> tags.append(a['act_arg'])
>
> if a['act_name'] == "id":
> self.current_ruleid = int(a['act_arg'])
>
> if a['act_name'] == "chain":
> self.chained = True
> self.chainlevel += 1
> aidx += 1
>
> if self.chained == False:
> if "paranoia-level/2" in tags and "attack-sqli" in tags:
> print("SecRuleRemoveById %d" % (self.current_ruleid))
> self.current_ruleid = 0
> tags = []
>
>
>
> if __name__ == "__main__":
> if len(sys.argv) < 2:
> print("Argument missing!")
> print("Use: %s input" % (sys.argv[0]))
> sys.exit(-1)
>
> fname = sys.argv[1]
> try:
> with open(fname, 'r') as inputfile:
> if yaml.__version__ >= "5.1":
> data = yaml.load(inputfile, Loader=yaml.FullLoader)
> else:
> data = yaml.load(inputfile)
> except:
> print("Can't open file: %s" % (fname))
> sys.exit()
>
> t = Transform(data)
> t.gettag()
>
> _______________________________________________
> 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/
|
Thanks for helping keep SourceForge clean.
X