It appears that Oinkmaster is set to change the action on all rules downloaded to 'drop' in the latest versions. This is incorrect. As an example there are a number of rules in emerging-info.rules that detect PDF files. The purpose of these rules is to set a flowbit which is then used later by other rules which look for particular PDF-related vulnerabilities (you can think of the flowbit mechanism as being similar in purpose to subroutines in a program - to avoid duplicating code). If you leave these and similar rules set to 'drop' they will prevent a lot of routine activity, however disabling the rule will stop later rules that rely on the flowbits set in these rules for detecting malware in that type of file. I know that some of the Talos VRT rules have metadata that specify the action to be taken when in IPS mode, however I don't know how the ET rules specify this (possibly based on the classtype - e.g. not-suspicious).
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.