IPS exception not working

[ED]

Hi,

IPS is preventing a protection even if I have an exception for that under Threat Prevention layer:

Under protected Scope is the server initiating the backup job. Action is set to inactive but still it's getting prevented. I don't get a hit on this rule. 

I used the add exception option:

What am I missing here? 

[Timothy_Hall]

Version of gateway? (not management)  Also please provide a screenshot of the actual Prevent log card with sensitive information such as IP addresses redacted.

[ED]

R80.10 GW's.

Here is the prevent log:

I used the "Add exception" on this log but it's still being prevented. 

[KennyManrique]

Threat Prevention Policy Date shows 06 Mar 2019 at 14:21.

When was your exception created? Is there any chance that you forgot to install Threat Prevention policy after exception's creation?

[Timothy_Hall]

Kenny is correct: being a ThreatCloud IPS Protection with an R80.10+ gateway, the Threat Prevention policy must be reinstalled for the exception to take effect.  Here is a handy table from my IPS Immersion course that I created:

[ED]

I wish that it was that easy but I have installed Threat Prevention policy several times while clearing IPS staging mode. That was just a random log. I really don't undestand why I don't get a hit on that exception rule when I used the "Add exception" for that particular log. 

[JanVC]

I've had similar issues in the past when using the protected scope option
you can add the source/destination colums in the view and build your exception that way

[ED]

I tried to move the server from protected scope to source column but still no hit on that exception. 

[ED]

It seems like it helped to move the server from Protected Scope to the Source column. The Track column is set to Log. I highlight the exception under Threat Prevention but don't see any logs there. I can find the traffic in Logs & Monitor when I search for it. Is that expected behaviour?

[Michael_Golub]

---

@ED wrote:

It seems like it helped to move the server from Protected Scope to the Source column. The Track column is set to Log. I highlight the exception under Threat Prevention but don't see any logs there. I can find the traffic in Logs & Monitor when I search for it. Is that expected behaviour?

---

If action is "Inactive" the log column is ignored. No attempt to enforce the protection is made so there is nothing to log. If action is "Detect" you will see log. Detect action is not supported in exceptions for R77.X BC gateways.

[ED]

Hi @Michael_Golub 

Thanks for claryifing that and it makes sense but it is also confusing. When you use the exception option from logs "Add Exception.." it automatically sets the Track column to Log. That blindfolded me and made me look at the "Logs" tab right below the exception rule without thinking like you explained. Track should be set to "- None" when using the exception option where action is set to inactive. 

[G_W_Albrecht]

Looks like when clicking Exception from Log detail, protection is atomatically set to inactive, but should be set to detect to make the exception work (all examples, R77.30 or R80.xx, show that the protection is set to detect) - has anyone experienced a similar issue ? We just found that after a customers Anti-BOT exception did not work at all, regardless of scope or source settings...

[Timothy_Hall]

Strange, it may be that setting Inactive on an exception for this signature causes it not be honored while Detect works.  DCE/RPC and firewalls have always been a bit wonky, maybe the two-stage nature (request port number for UUID and portmapper returns port number, then connect to that ephemeral port) prohibits setting for "Inactive" in the associated exception?  Perhaps since it might hinder further inspection of future DCE/RPC session traffic by other IPS signatures or even impede the "pinholing" open of the assigned ephemeral port? 

@ED SecureXL is not supposed to interfere with portmapper traffic at all, but it might be worth a shot to disable SecureXL for the IP address specified in the exception and see if that makes a difference in the proper handling of your exception:

sk104468: How to disable SecureXL for specific IP addresses

[G_W_Albrecht]

Customer explained that this has worked in R77.30 - and in R80.20, after defining an exception with Action "Detect", when some GWs still are running R77.30 you will see:

So this seems to have changed with R80.xx...

[Timothy_Hall]

That makes sense, in R77.30 and earlier when defining an IPS exception you aren't allowed to set an action for the exception and it presumably just sets "Inactive" for you.  With an R80.10+ gateway you are allowed to select an action of Detect, Inactive, and even Prevent right in an exception so that is definitely a change in the gateway code.

[G_W_Albrecht]

With an R80.10+ gateway you are allowed to select an action of Detect, Inactive, and even Prevent right in an exception ---> I can not see any sense in this fact !

1. If action is Inactive, Exception does not work, but no warning appears

2. If action is Detect, R80.xx Exception works, but warning appears for Pre-R80.xx GWs

3. If action is Prevent, i would assume a warning appears for Pre-R80.xx GWs, but also otherwise it would not differ from the case when action is Detect !

To find a match for a protection exception you have to find a match for the protection (using detect or prevent) - this seems the big difference to R77.xx GWs.

[KennyManrique]

Hi @G_W_Albrecht , I experienced a similar issue with ABOT exceptions.

When they are detected by firewall (and logs) there is certain combinations of uppercase and lowercase on the protection name: for example, the protection is Malware.ABC.XYZ. When you try to create an specific exception under Threat Prevention Policy, is listed on SmartConsole as Malware.abc.xyz (notice the lowercase difference).

I Opened a TAC case at the end of 2018, they requested a lot of logs and debugs more than once, without any succesfull result. Theoretically should be resolved on any upcoming update of engine/database.

What I did to create the exception was to modify the action under Threat tools - Protections; where it was listed correctly as Malware.ABC.XYZ. The only issue is that on this way, it affects globally to the specific protection

[Timothy_Hall]

Very interesting! I seem to recall that all objects became case-sensitive starting in the R80 management release, I would assume due to the abandonment of Windows as an SMS platform.  This meant that two objects named "blah" and "BLAH" were no longer the same and could exist in the configuration concurrently in R80+, but you were blocked from creating two objects named like this in R77.30 and earlier.

Wonder if this IPS exception limitation is an offshoot of that, and the log card  IPS exception generation code needs to be updated to reflect this case-sensitivity change?  Most of the IPS-related code has been around a very long time relatively speaking, so it is certainly plausible...

[Mikel_Aanstoot]

Hi, not sure if you came from an upgrade but I find it that after the upgrade to R80.X it looks like the exceptions are all over the place. From your screenshot it looks like you are using the global Exceptions out of the box ?

We use 2 specific profiles for IPS. One for main office, one for remote office gateways. When you go to Exceptions you may see Global exceptions, your specific ISP profile exceptions and  additional Core Protections Exceptions. I am not sure if this is the correct way but it works for us, I open the Core Protections Exceptions: create a new exception for the profile I want to use, which protection and depending on situation specific source and destination and service and on what gateway I want to install this exception. Then policy push threat and exception is added and working. Management and main gateways on R80.10, SMB 1400 series on R77.20.85

kind regards,

Mikel