I'm currently running CSA 5.2 r238 with all systems in Test Mode. I keep seeing events for certain modules loading after startup, such as pdcrypt2.sys in a Citrix environment. I know these events are normal and don't care to have those events logged any more.
The events are being generated by Rule 50, a Kernel Protection rule with a monitor action in System Hardening Module [V5.2 r238]. I've copied this rule to a custom rule module and set it to priority allow and did not check the Log option.
I created a file set for pdcrypt2.sys as follows:
Directories Matching: **\Program Files\Citrix\system32\drivers but not <none>
Files matching: pdcrypt2.sys but not <none>
I'm still seeing events generated by rule 50. I know my rule is enforced by looking at an affected host and my rule appears to process beore Rule 50. Why am I still seeing events generated by rule 50?
Monitor rules are always checked, even in the presence of a higher priority enforcement rule.
You can either use an event suppression filter or create a custom file set that excludes those modules you don't wish to monitor any longer.
I did the second one and it is quiet now.
The event wizard has all options grayed out when I try to create an event suppression filter that way. I've manually tried to create a filter by copying the event generating the rule and creating a file set as shown above but I'm still seeing the events. Where do I go from here?
No, they don't. The hosts being affected all report Verbose Logging Mode as off. I also verified that all member groups have Verbose Logging Mode turned off. The host is in Test Mode, however. Would that override the suppression filter I created? I've been able to filter out other events even though the host is in Test Mode.
You're correct, being in Test Mode isn't the issue.
That is unless you have the logging turned on for the rule or verbose turned on, which you indicated you had turned off in both cases.
Are the hosts getting the updated policy? I have seen some hosts continue to send alerts until they get the updated policy.
You may need to follow Tom's suggestion and add the File Set to "exception" section in the rule(s) itself.
According to the CSA MC the affected hosts all have the most updated policy.
Above I did post the configuration of my file set for the module in question; does the file set appear to be formatted correctly?
I'd like to avoid modifying the base rule as that will not carry over during an upgrade.
They appear to be right.
I am on 6.0 but looking at a similar rule it states:
"By default, this field contains
Note that if you enter files sets which use "content-matching" constraints, via the Insert File Set link, the content-matching constraints are ignored"
But if you have the logging turned off it should not be logging these regardless of the rule setup.
Hi Michael, the modified file set in my rule has Directories matching:
I'm not sure why your event supression filter options are greyed out. Look at "View change history" for the rule to see if anything else may be affecting it.
Also, do you have "Always show suppressed events" checked in your Administrator preferences?
I'm just baffled. I changed my file set, AAA - Citrix pdcrypt2.sys, to look like yours does.
The change history for rule 50, which I based my rule off of, is blank.
The rule basically reads likes this:
Modules load after system startup is checked
File set contains: $AAA - Citrix pdcrypt2.sys
Based on my understanding of the rules and the previous posts in this thread it would seem that logging for these events should be suppressed, but that is obviously not the case. Does your modified file set exist in rule 50 (or the corresponding rule in another version) or did you clone rule 50 to create your suppression filter rule?
Mike, my modified file set exists in the primary kernel protection monitor rule and that is why I don't see them any more.
If you haven't modified what the primary monitor rule is looking for, that may be why you still see events.
I was hoping to avoid that as those changes don't carry over during an upgrade. But, it looks like it might be the only choice. The rule looks to be set up correctly, but for some reason doesn't work.
I'm going to open up a TAC case and I'll let you guys know what they say.
Thanks for all of your help!
In the end, Tom's first response was right. There is no way to suppress this event because it is triggered from a monitor rule. The only thing that can be done is to filter out what's seen in the interface, or to scrub it out of the logs when you farm them off to an LMS. Thanks again, Tom!