Bug 12086

It looks like a good first step would be to set rules containing the string 'flowbits:noalert' back to alert.

Longer term it would probably be a good idea if the WUI was able to set the state of each rule to one of:

- Disabled
- Alert suppressed
- Alert
- Drop

This would enable policy rules (for example) to be set to 'alert' so that the use of certain applications could be checked.

After a bit of digging, the Talos VRT rules (including the community rules) contain metadata of the form "policy <name>-ips <action>", where <name> is one of: connectivity (over security), balanced (between connectivity and security), security (over connectivity) and max-detect.  In IPS mode, rules which include the metadata for the selected policy should be enabled and the action set to action specified in the metadata.  If the metadata string is not found the rule should be disabled.  Rules are distributed enabled and disabled according to the default policy of balanced, but set up for IDS mode rather than IPS mode.

There appears to be no equivalent for the Emerging Threats community rules, so using "flowbits:noalert" seems to be the best solution at this time.

For reference, in the community.rules, the statistics are:

connectivity-alert     1
connectivity-drop     19
balanced-alert        15
balanced-drop        875
security-alert         4
security-drop       1074
max-detect-alert      33
max-detect-drop      935

enabled             1047
disabled            2840

I think the following directives should work:

  # Convert all rules to drop
  modifysid * "^(#?)alert" | "${1}drop"

  # Convert flowbits:noalert rules back to alert
  modifysid * "^(#?)drop(.*flowbits:noalert)" | "${1}alert${2}"

  # For Talos VRT rules use the metadata
  modifysid * "^#?drop(.+policy balanced-ips alert)" | "alert${1}"
  modifysid * "^#?alert(.+policy balanced-ips drop)" | "drop${1}"

This should work for both ET and Talos VRT rules, but there's the possibility of leaving some Talos VRT rules enabled which are unnecessary in the policy.  This is especially likely if used for a policy other than balanced, for example it wouldn't disable the many rules not in connectivity - it would however work better for security.

For just the Talos VRT rules, the following should work better, for any policy:

  # Disable all rules that aren't already disabled
  modifysid * "^[^#]" | "#"

  # Convert all rules to drop
  modifysid * "^(#?)alert" | "${1}drop"

  # Convert flowbits:noalert rules back to alert
  # With the previous rule this should give a sensible default if a rule that
  # is not in the active policy is enabled by the user
  modifysid * "^(#?)drop(.*flowbits:noalert)" | "${1}alert${2}"

  # Set rules according to policy
  modifysid * "^#?drop(.+policy balanced-ips alert)" | "alert${1}"
  modifysid * "^#?alert(.+policy balanced-ips drop)" | "drop${1}"

For the ET rules these directives would leave everything disabled.

Since the enablesid and disablesid directives are executed after modifysid, changes made by the user should be preserved, but new rules set according to the policy.

I've not tried these suggestions yet, but I intend to modify oinkmaster-modify-sids.conf with the first set of directives and see how they work over the next few days.  They're offered in case anyone else wants to try them but use at your own risk - if I've made a mistake in syntax or logic you could drop all traffic and make the system unusable.

Hey Tim,

I have been monitoring this ticket for some time and I think that we are indeed dropping things that we probably shouldn't:

> https://bugzilla.ipfire.org/show_bug.cgi?id=12078

I am not sure if you can confirm or deny that.

However, if Stefan approves, would you send this in as a patch that we can get this into Core Update 133? I think it this is all okay, we should ship it as fast as possible.

I'm not going to get a chance to submit a patch today - hopefully tomorrow.

The first set of directives work on ET community rules, so I need to check against the Talos VRT rules.

I'd just noticed that the URL filter hadn't updated for 64 days (set to update weekly and build with Suricata installed 61 days ago).  It's just successfully performed a manual update, so that would appear to confirm that at least some of the problems will be fixed with the patch.

Patch has been submitted to the development mailing list

https://patchwork.ipfire.org/patch/2276/

Fix has been shipped with core 133.