Project

General

Profile

Actions

Feature #5219

open

Task #4773: research: IPS behavior wrt resource limits

ips: add 'master switch' to enable dropping on traffic (handling) exceptions

Added by Victor Julien 8 months ago. Updated about 4 hours ago.

Status:
In Review
Priority:
High
Target version:
Effort:
Difficulty:
Label:

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.


Related issues 1 (1 open0 closed)

Related to Feature #5745: exceptions: allow setting via unix-socketNewOISF DevActions
Actions #1

Updated by Victor Julien about 1 month ago

  • Description updated (diff)
  • Priority changed from Normal to High
  • Target version changed from TBD to 7.0.0-rc1
Actions #2

Updated by Jason Ish about 1 month 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?

Actions #3

Updated by Victor Julien 10 days ago

  • Assignee changed from OISF Dev to Juliana Fajardini Reichow
Actions #4

Updated by Juliana Fajardini Reichow 10 days 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?

Actions #5

Updated by Victor Julien 10 days ago

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

Actions #6

Updated by Victor Julien 10 days 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?

Actions #7

Updated by Juliana Fajardini Reichow 10 days 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"?

Actions #8

Updated by Juliana Fajardini Reichow 10 days 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

Actions #9

Updated by Jason Ish 10 days 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.

Actions #10

Updated by Juliana Fajardini Reichow 9 days 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?

Actions #11

Updated by Victor Julien 9 days ago

  • Status changed from New to Assigned
Actions #12

Updated by Juliana Fajardini Reichow 2 days ago

  • Related to Feature #5745: exceptions: allow setting via unix-socket added
Actions #13

Updated by Jason Ish about 13 hours 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.

Actions #14

Updated by Juliana Fajardini Reichow about 4 hours ago

  • Status changed from Assigned to In Review
Actions

Also available in: Atom PDF