Exclude device from IPS policy?

[david]

Assuming you're using FMC, how would you exclude a given IP address from a specific IPS alert?  For example, system traffic was blocked due to a specific malware definition but it was determined that the traffic was legitimate and you only want to exclude that particular system from being blocked?  I've looked in several places but cannot figure out how to do this?    

[Marvin Rhoads]

Whitelist the address in your Access Control Policy (under Security Intelligence tab).

[david]

Wouldn't that whitelist it for all IPS alerts?  I only want to whitelist if for a specific alert, a specific malware alert that it triggered.  

[Ilkin]

---

@david wrote:

Wouldn't that whitelist it for all IPS alerts?  I only want to whitelist if for a specific alert, a specific malware alert that it triggered.  

---

If the purpose is to suppress intrusion event notification (alert) for a specific host, then it is configured in the Intrusion Policy -> Suppression. It can be based on either source or destination addresses. This suppresses only notification, while the rule itself will be active.

If the purpose is to disable only a specific Snort rule (s) for a specific host(s), while leaving other rules enabled, then additional IPS policy with desired configuration can be created and applied in a separate access control rule.

There is one more way to configure dynamic state for an IPS rule, although dynamic state is not strictly for this purpose. It allows to change the state of the rule based on the number of rule matches per time period. The timeout field there defines how long the new state will be in force. If it is 0, then new state will always be in force. Dynamic state requires a rule to be fired at least once.

[Marvin Rhoads]

@david yes it would exclude the host for all IPS rules. @Ilkin 's solution is the more precise application of policy to achieve your stated goals.

[borutlape]

Hi Marvin,

Are you sure?

I need exactly this but I believe that adding a host to Security intelligence whitelist will not exclude it from IPS inspection.

At least according the documentation:

Traffic added to a Do Not Block list or monitored at the Security Intelligence stage is intentionally subject to further analysis with the rest of access control.

Reference URL: https://www.cisco.com/c/en/us/td/docs/security/firepower/660/configuration/guide/fpmc-config-guide-v66/security_intelligence_blacklisting.html#ID-2192-00000005

[david]

Thanks guys, is this documented anywhere?  I see where you're heading, but not sure of the steps to create new IPS policy to be used in access control rule.

My scenario is this > "If the purpose is to disable only a specific Snort rule (s) for a specific host(s), while leaving other rules enabled, then additional IPS policy with desired configuration can be created and applied in a separate access control rule."  

[Marvin Rhoads · Accepted solution]

First go to Policies > Intrusion Policy > Create a Policy. Create and edit a new one. Disable that one rule for this new policy. (Select the rule, click on Rule State and then Disable). Save the Intrusion Policy.

Then go into your Access Control Policy. Add a rule there for the host (or modify an existing one if such exists). Under the "Inspection" tab, choose the newly created intrusion policy. Save the ACP. 

Deploy the changes and test to verify.

[david]

Thanks Marvin, that was very helpful!  One final question, the alert was triggered by a single host behind a single SFR.  The current access control policy targets 100+ devices.  Is it cleaner to copy/rename both the current IPS and Access Control Policy, edit the copied IPS policy to disable rule state of offending snort rule, edit copied access control policy with a new rule that references edited IPS policy and then assign (Policy Assignment) only to the offending SFR?  or is it cleaner to insert a new access rule into the current Access Control Policy?  I'm not clear if doing the later forces me to deploy the change to all 100+ devices vs. deploying to a single device.  

[Marvin Rhoads]

If the ACP is targeting all those devices, any change will show as pending on all of them.

You can elect to deploy to only the one you need for now, but eventually something else (like Cisco's Snort Rule Update or new VDB) will likely trigger the mass deployment.

As to which is easier or better, you can make an argument either way. A lot depends on your operational model / practice. I'd definitely make the second IPS policy. If it were me, I would probably edit the overall ACP and just deploy it to the necessary sensor for now.

[Azlan.my07]

Hi Marvin,

I'm using FMC Version 7.2.4.1, I only can see option of Intrusion policy "No Active Rules" is it choose that one? as below, because i want to by pass my source IP being blocked by IPS, because we are currently perform vulnerability assessment.

[Marvin Rhoads]

Make a prefilter policy with a rule to fastpath the traffic from your source IP. That will bypass all of the Snort, SI, preprocessor etc. stages in the firewall.

https://community.cisco.com/t5/network-security/ngfw-policy-order-of-operations/td-p/3834389