Create a Post
Showing results for 
Search instead for 
Did you mean: 

Exceptions on IPS Core Protections

I wanted to share with you a new SK about working with core protections and adding exceptions to them.

More than once I have seen issues with R80.x where exceptions "don't seem to apply". Remember that core protections are different animals from IPS Threat Cloud Protections, enforced on dedicated profiles and installed with access control policy.

4 Replies

Thanks for the new SK concerning IPS Core Protection exceptions, very helpful.  Can you elaborate on the "technical reasons" that cause the 39 IPS Core Protections to be configured separately from IPS ThreatCloud Protections and Inspection Settings?  I'm assuming it is related to the merging of the IPS blade into the main Threat Prevention policy under R80+, and the splitting out of some IPS protections into Inspection Settings (and a few other blades such as APCL and ABOT).

I seem to get asked this question in regards to my IPS Immersion class often, and always have to fall back on the murky "technical reasons" phrase.  Thanks!


New 2021 IPS/AV/ABOT Self-Guided Video Series
now available at
0 Kudos

Hi @Timothy_Hall

Threat Cloud Protections are enforced with the Pattern Matcher while core protections are implemented with the protocol parser and inspection settings in some lower levels of the NGTP engine. 

In R77.30 and earlier access control policy had to be pushed anyway to enforce IPS. So, I believe that when we moved IPS to be part of Threat Prevention, we actually moved only the Threat Cloud protections, but the core protections still stayed with the access control because they are enforced in a different place than the actual IPS signatures are.

Inspection Settings and Geo Policy are not actually part of the IPS (Inspection settings used to be called engine settings in R77.x) and also enforced with the access control policy.

This is my understanding, but as I'm not R&D I cannot answer in any more detailed why this kind of separation exists. If someone has better understanding, please comment. 🙂


From my point of view it is an disadvantage that core protections can only defined per gateway in opposite to the general IPS protections there you can define multiple profiles used on one gateway.

It is confusing that the core protections are located in one profile which is used for IPS protections as well. If there is a better segregation between them it would be helpful.

The next disadvantage is, that exceptions on core protections are only based on the entire protection, source ip, destination ip and service port but not for dedicated applications or at least based on an uri.

That means, currently you can not whitelist a core protection for a specific uri.


Hi Lari_Luoma,
Thanks for this SK.
What we're missing for a customer is the following:

Core Protection "Host Port Scan" ist set to Accept and Track with "Mail"
We can define for this Core Protection an exception, but how can we create an exception for the Track with Mail?

When the external scanning host is doing a host port scan we see only detect in the logs but many mails are created then.
We need to create an exception for Track - Mail.

0 Kudos