-
Notifications
You must be signed in to change notification settings - Fork 701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDPS: replace current ruleset filter option with policy editor #4445
Labels
feature
Adding new functionality
Comments
AdSchellevis
added a commit
that referenced
this issue
Nov 5, 2020
AdSchellevis
added a commit
that referenced
this issue
Nov 6, 2020
o page render performance improvements o layout rules section
AdSchellevis
added a commit
that referenced
this issue
Nov 8, 2020
AdSchellevis
added a commit
that referenced
this issue
Nov 9, 2020
With this commit policies functionally work, but there's still some refactoring todo. o migrate download filters to a policy o remove download filter option o point to policies in the download section o (maybe) move single rule overwrites to policies as well.
AdSchellevis
added a commit
that referenced
this issue
Nov 23, 2020
…cy option. migrates exsting filters to policies while there. for #4445
AdSchellevis
added a commit
that referenced
this issue
Nov 23, 2020
AdSchellevis
added a commit
that referenced
this issue
Nov 28, 2020
…cy option. migrates exsting filters to policies while there. for #4445
AdSchellevis
added a commit
that referenced
this issue
Nov 28, 2020
AdSchellevis
added a commit
that referenced
this issue
Dec 8, 2020
o feedback matched policy so we can easily find affective choice in the rule tab o remove installed_action, installed_status since these values aren't valid anymore o while here, set <pre/> tag width to a maximum to avoid overflow in alert page Since values need to be persisted in order to return on query requests, single rule edits can lead to a bit odd behaviour (not toggling until after apply), since modifications are advised to be performed using policies, we will keep this for now. (the alternative is to hook apply after these changes, which also isn't a great solution)
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
o page render performance improvements o layout rules section
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
With this commit policies functionally work, but there's still some refactoring todo. o migrate download filters to a policy o remove download filter option o point to policies in the download section o (maybe) move single rule overwrites to policies as well.
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
…cy option. migrates exsting filters to policies while there. for opnsense/core#4445
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
…cy option. migrates exsting filters to policies while there. for opnsense/core#4445
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
oshogbo
pushed a commit
to DynFi/opnsense-core
that referenced
this issue
Mar 3, 2022
…ore#4445). o feedback matched policy so we can easily find affective choice in the rule tab o remove installed_action, installed_status since these values aren't valid anymore o while here, set <pre/> tag width to a maximum to avoid overflow in alert page Since values need to be persisted in order to return on query requests, single rule edits can lead to a bit odd behaviour (not toggling until after apply), since modifications are advised to be performed using policies, we will keep this for now. (the alternative is to hook apply after these changes, which also isn't a great solution)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem description
Suricata rules can contain metadata, which can identify the intended audience and purpose of rules (such as expected performance impact, cve's and applications involved, etc, etc).
Although you can already change policies on a per rule basis, this is often rather labor extensive and doesn't cope well with future changes. Using the metadata in the rules should ease maintenance.
While adding these policies it would be practical to move the existing "filter" construction available in the rulesets as well, to avoid confusion on what to set where (in which case as policy would just turn into a filter and action to perform).
Planned change
A new form containing a grid which contains policies in which case someone can select rules from one or multiple rulesets and a planned action to perform.
An example could be select all threads aimed at
Adobe flash
withcritical severity
anddrop
traffic when hit.Since the current "drop" filter rules would evaluate as select all
alert
rules infile
anddrop
traffic, it should be a rather easy migrationThe text was updated successfully, but these errors were encountered: