Threat Protection Whitelisted Rules

Twitch
A model citizen

Threat Protection Whitelisted Rules

Morning everyone. I have a question for the crew:

 

We are currently fighting a CryptoMining malware attack on one of our servers. In the process of fighting it and adding rules to the firewall to block IPs/ports, I noticed that on the Threat Protection page there is a series of Whitelisted Rules under Intrusion Detection and Prevention. I did not configure this MX, but I am responsible for it now due to a former co-worker's termination. 

 

I am trying to determine why these rules are whitelisted and what that means in terms of analyzing traffic. To me, when an item is whitelisted, that generally means it is allowed to come through, but based on the names of these rules, it appears that the traffic should be blocked instead. Here are some rule names:

 

- Exploit-Kit Magnitude exploit kit embedded redirection attempt

- Server-Webapp DrayTek Multiple command injection attempt

- Server-Webapp Zeroshell Linux Router command injection attempt

 

Will traffic related to these whitelisted rules bypass security, or do these rules serve some other purpose? The documentation I read didn't really provide much of an explanation of behavior. 

 

Should I leave this rules, or delete them? My concern is they were added by two former employees who are no longer with the company. 

 

Thanks for any help you can offer. 

 

Twitch 

 

2 Replies 2
KarstenI
Kind of a big deal
Kind of a big deal

Whitelisting of rules is a part of a process named "IPS tuning". Typically it is done (not a complete list) when a rule causes a false positive and or processing the rule is a waste of resources because they are not relevant in the environment.

All whitelisted rules, the same as with firewall rules, should be evaluated from time to time to see if they are still implemented correctly.

At least I have seen lots of whitelisting that was added when troubleshooting problems. Based on "oh, there is an event in the IPS dashboard, let's disable this rule" the rule was disabled, but regardless if this was the problem or not, the whitelisting stayed in the config.

 

Given that the MX-IPS is meant to be more or less a "black box" without extensive tuning possibilities, I would look up the rules in the Snort documentation and enable them if it is likely that they will not harm you.

 

Another approach (but with more risk), switch from Prevention to Detection, and delete the whitelist. If no events will show up, you can go back to Prevention. If Events still show up, it will get harder if it is traffic that is needed for operation. But then, there are no easy rules on how to proceed.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
MerakiDave
Meraki Employee
Meraki Employee

Your interpretation is correct, the items in that allow list on the Threat Protection page are related to the AMP engine, so any sites you explicitly allow there get excluded from malware scanning.  But agreed, the items you listed certainly look like you would want them blocked, not allowed.  Look up whatever the URLs happen to be.  That's for the AMP piece, and the same concept for the IPS basically applies, but it's possible there was something legitimate being blocked which prompted them to put something in the allowed list. 

 

Also, just a thought, see if you can go back in the change log, see if or what else was changed around the same time, and also see if you can correlate the changes with anything you might see in a Security Center report if it was within the last couple weeks.  You might be able to go back further if there were Security Center email reports configured, as long as you can retrieve those emails.

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels