Re: [mod-security-users] Possible to remove rules by multiple tags?
Brought to you by:
victorhora,
zimmerletw
|
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/ |