CSA 5.1 & Rule 596

[astroman]

Rule 596 (Network Access Control) generates a TON of noise. Any best practices on tuning this one?

Obviously, cloning the module this one belongs to, "Rootkit Lockdown Module", and setting the new Network Access Control rule built inside to "Deny" instead of "Priority Deny" will allow exception rule creation, but...

Does anyone recommend anything different, such as simply adding Application Classes to the list of apps that this rule should not apply to?

Any suggestions are appreciated...

[tsteger1]

You are on the right track by changing it to a deny instead of priority deny.

Then you can create a deny and don't log rule to take precedence over the original rule for the noisiest traffic.

This should reduce the noise to bearable levels and alert you to any anomalous traffic.

Just an FYI, your rule 596 probably does not correspond to anyone elses rule 596 (I don't even have one).

Tom

[astroman]

Thanks for the reply Tom.

So after cloning and moving to "Deny" status, would you recommend adding application classes to the rule module for exception?

This rule is blowing up right now, in test mode. I've cloned the group with attached policies, and basically want to clone and modify the rule module that's making a lot of unnecessary noise.

[tsteger1]

I would only add the application classes to the exception list if you want to allow that traffic.

If you want to deny the traffic, but not log it, I would change the original rule to deny and then make another rule that denies the activity, does not log and takes precedence over other deny rules.

That way you'll still be protected but won't see all the noise.

You should also remember that it will always log in test mode, even if you have it set not to log.

Tom

[astroman]

I understand what you're saying. What I'm afraid of, is that if I do not create exceptions for some of these application classes, that normal application behavior is going to be denied.

The rule I'm referring to is a Network Access Control rule, which watches all client/server processes for both TCP/UDP.

For example, I don't want to deny Firefox from acting as a client on port 80.

I'm running a clean install of CSAMC 5.1.

[tsteger1]

You know, there were a couple of default rules in the more restrictive rule modules that I changed right away and that was one of them.

I changed mine to server only instead of client or server. I think that should work for what you want.

Otherwise you'll spend a ton of time trying to create every exception for client IP activity.

I mean after all, these are client PCs so they should act like clients, right? It's when they start acting like servers that you should be concerned.

Hope this helps..

Tom

[astroman]

I like the sound of that. Thanks Tom...

[pmccubbin]

Hi Tom,

Thanks for your insightful posts, as always.

When I saw this post I had to laugh because I was discussing this exact same rule number yesterday with a customer. You were correct to point out that when someone posts a question with a Rule Number it may not correspond with anyone else's Rule Number. Though in this case it did with my customer's recent implementation and the only reason this may have been the case was because it was a clean install of CSA 5.1. My guess is that if you have upgraded from a 4.x build your numbers will be different.

Thanks again for your post on reducing noise to a bearable level on Rule 596. I told my customer to visit the NetPro forum and keep an eye out for your name and rate the posts accordingly.

Cheers!

Paul

[tsteger1]

Thanks Paul, I think there was just enough information to make a guess as to which rule it was, so I hoped I got it right...

Enjoy the Holidays...

Tom

[mwong]

I just checked a fresh install of CSA 5.1 and rule 596 is a high priority deny for all ip traffic.

I do not agree with changing that rule to straight deny or to deny server only. The reason that rule kicks in is because your systems are "Set" as rootkit detected. If that is a true positive, you should clean the rootkits, not just do something to reduce the alerts. You can check this by going to Events > Status Summary and seeing how many hosts are listed in "Untrusted rootkit detected".

I recommend changing the "Set" Rootkit detected rule itself to monitor. This is one of the 2 set rules in the System Hardening module (or rule 46 in a fresh install). Then use event suppression to keep these alerts out of your main event view if there are too many of them (I'm guessing Symantec will come up). But remember, these are potentially rootkits we're talking about here so you still want to keep an eye on them even if you suppress the events.

I do not recommend changing rule 596 to straight deny or to deny server connections only. The rootkit lockdown module is meant for dealing with machines that have rootkits. This rule applies to servers as well so you can still see tons of alerts if CSA thinks your servers have rootkits.

[tsteger1]

Thanks Mark, that's good point about the rule in question. I would not change the set rule to monitor though because how would it ever trigger the NAC rule?

Instead I would create a list of trusted 'rootkits' to put in the exceptions list.

Tom

[mwong]

1) as tsteger1 said, you need to give more information on which rule is noisy. Rule ID's aren't sufficient. The rule module name and OS and description is usually sufficient to identify a rule.

2) This is my guess as to what's actually happening. When CSA sees something trying to modify the kernel after boot up (Symantec AV does this, for example), it "sets" the system state as "rootkit detected". Once CSA thinks there's a rootkit, it will actually DENY all inbound and outbound TCP and UDP traffic (that's why they call it rootkit lockdown). In Test mode, it doesn't actually take effect, but it certainly logs it back to the database, resulting in quite a few alerts.

To see if this is the case, see if there are machines with rootkit detected from your MC Summary page.