Project

General

Profile

Actions

Feature #5219

closed

Task #4773: research: IPS behavior wrt resource limits

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

Added by Victor Julien over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
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 3 (1 open2 closed)

Related to Suricata - Feature #5745: exceptions: allow setting via unix-socketNewOISF DevActions
Related to Suricata - Bug #5765: exceptions: midstream flows are dropped if midstream=true && stream.midstream-policy=drop-flowClosedJuliana Fajardini ReichowActions
Related to Suricata - Bug #6169: exceptions: master switch not applied to midstreamClosedJuliana Fajardini ReichowActions
Actions #1

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
Actions #2

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?

Actions #3

Updated by Victor Julien about 2 years ago

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

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?

Actions #5

Updated by Victor Julien about 2 years 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 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?

Actions #7

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"?

Actions #8

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

Actions #9

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.

Actions #10

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?

Actions #11

Updated by Victor Julien about 2 years ago

  • Status changed from New to Assigned
Actions #12

Updated by Juliana Fajardini Reichow about 2 years ago

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

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.

Actions #14

Updated by Juliana Fajardini Reichow about 2 years ago

  • Status changed from Assigned to In Review
Actions #15

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
Actions #16

Updated by Victor Julien almost 2 years ago

  • Label Needs backport to 6.0 added
Actions #17

Updated by Juliana Fajardini Reichow almost 2 years ago

  • Status changed from In Review to Resolved
Actions #18

Updated by Victor Julien almost 2 years ago

  • Status changed from Resolved to Closed
  • Priority changed from High to Normal
Actions #19

Updated by Victor Julien almost 2 years ago

  • Status changed from Closed to Resolved
Actions #20

Updated by OISF Ticketbot almost 2 years ago

  • Subtask #5935 added
Actions #21

Updated by OISF Ticketbot almost 2 years ago

  • Label deleted (Needs backport to 6.0)
Actions #22

Updated by Victor Julien over 1 year ago

  • Subtask deleted (#5935)
Actions #23

Updated by Victor Julien over 1 year ago

  • Status changed from Resolved to Closed
Actions #24

Updated by Juliana Fajardini Reichow over 1 year ago

  • Related to Bug #6169: exceptions: master switch not applied to midstream added
Actions

Also available in: Atom PDF