Feature #5219
closedTask #4773: research: IPS behavior wrt resource limits
ips: add 'master switch' to enable dropping on traffic (handling) exceptions
Description
In IPS mode for new setups we should default to "drop-pkt/drop-flow" on all policies. However for smooth upgrades we should probably only do it in a new config. Wonder if we should add a warning in 7 that in 8 this will be enabled also for configs that are not setting the option.
Updated by Victor Julien about 2 years ago
- Description updated (diff)
- Priority changed from Normal to High
- Target version changed from TBD to 7.0.0-rc1
Updated by Jason Ish about 2 years ago
This creates an interesting problem...
If we only want this to happen in upgrades, it means adding an enabled
field in the configuration file which turns this on. But the default would still be disabled, however we want this to be the default for new installs. This breaks the idea that a configuration file missing this field would have this enabled by default.
Could we add a "generated by" field to the suricata.yaml
and use that to determine what some defaults should be?
Updated by Victor Julien about 2 years ago
- Assignee changed from OISF Dev to Juliana Fajardini Reichow
Updated by Juliana Fajardini Reichow about 2 years ago
Jason Ish wrote in #note-2:
Could we add a "generated by" field to the
suricata.yaml
and use that to determine what some defaults should be?
Should we have a ticket for this?
Updated by Victor Julien about 2 years ago
Updated by Victor Julien about 2 years ago
Jason Ish wrote in #note-2:
This creates an interesting problem...
If we only want this to happen in upgrades, it means adding an
enabled
field in the configuration file which turns this on. But the default would still be disabled, however we want this to be the default for new installs. This breaks the idea that a configuration file missing this field would have this enabled by default.Could we add a "generated by" field to the
suricata.yaml
and use that to determine what some defaults should be?
Would it make sense to only make it a default yaml kind of default, but add a warning that the built-in default will change in 8?
Updated by Juliana Fajardini Reichow about 2 years ago
Victor Julien wrote in #note-6:
Jason Ish wrote in #note-2:
This creates an interesting problem...
If we only want this to happen in upgrades, it means adding an
enabled
field in the configuration file which turns this on. But the default would still be disabled, however we want this to be the default for new installs. This breaks the idea that a configuration file missing this field would have this enabled by default.Could we add a "generated by" field to the
suricata.yaml
and use that to determine what some defaults should be?Would it make sense to only make it a default yaml kind of default, but add a warning that the built-in default will change in 8?
Does this mean that, for now:
i) we would add the master switch in the yaml file, with "enabled: true" by default
ii) search for the value in the yaml and, if it's enabled there, enable it, with the warning that this will be the built-in default from 8 onwards?
iii) if not present in the yaml file, we interpret as if "enabled: false"?
Updated by Juliana Fajardini Reichow about 2 years ago
Victor Julien wrote in #note-5:
Juliana Fajardini Reichow wrote in #note-4:
Jason Ish wrote in #note-2:
Could we add a "generated by" field to the
suricata.yaml
and use that to determine what some defaults should be?Should we have a ticket for this?
Yes
Not sure if I got it right, but: https://redmine.openinfosecfoundation.org/issues/5719
Updated by Jason Ish about 2 years ago
One option is to make this the new default in 7. To keep the old behaviour you have to add a new configuration field.
By warning in 7, we "smooth" the upgrade to 7. But still create a breaking change in 8.
Updated by Juliana Fajardini Reichow about 2 years ago
If we make this the default in 7 and the old behavior requires adding the field, then that means that in the absence of the field, we have the new behavior enabled by default, right?
Is the break that you refer to here related to the fact that, in 8, if the field is not present, without any warnings the default is to drop everything?
Updated by Juliana Fajardini Reichow about 2 years ago
- Related to Feature #5745: exceptions: allow setting via unix-socket added
Updated by Jason Ish about 2 years ago
Juliana Fajardini Reichow wrote in #note-10:
If we make this the default in 7 and the old behavior requires adding the field, then that means that in the absence of the field, we have the new behavior enabled by default, right?
Is the break that you refer to here related to the fact that, in 8, if the field is not present, without any warnings the default is to drop everything?
What I'm getting at is at some point in the future we make the change breaking one.. Or maybe better said a new default. Why delay til 8. Just break in 7. Document.
Updated by Juliana Fajardini Reichow about 2 years ago
- Status changed from Assigned to In Review
PR for review: https://github.com/OISF/suricata/pull/8266
Updated by Juliana Fajardini Reichow about 2 years ago
- Related to Bug #5765: exceptions: midstream flows are dropped if midstream=true && stream.midstream-policy=drop-flow added
Updated by Juliana Fajardini Reichow almost 2 years ago
- Status changed from In Review to Resolved
Merged PR: https://github.com/OISF/suricata/pull/8310
Updated by Victor Julien almost 2 years ago
- Status changed from Resolved to Closed
- Priority changed from High to Normal
Updated by Victor Julien almost 2 years ago
- Status changed from Closed to Resolved
Updated by OISF Ticketbot almost 2 years ago
- Label deleted (
Needs backport to 6.0)
Updated by Victor Julien over 1 year ago
- Status changed from Resolved to Closed
Updated by Juliana Fajardini Reichow over 1 year ago
- Related to Bug #6169: exceptions: master switch not applied to midstream added