topic Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL? in Firewall and Security Management

Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Rob_Bush — Tue, 28 Apr 2020 15:58:07 GMT

Lately my firewalls have been getting slammed with Threat Emulation tasks whenever a client reaches out to the Microsoft servers for windows update. It appears my clients are using HTTP to grab files from http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice and the download is causing TE to kick in and try to emulate the files, which causes increase load on the firewall. I know that I can create a Threat Prevention rule with all the Microsoft IPs/Networks as the Protected Scope and then assign a TP profile with TE/AV turned off, but I really don't want to have to maintain the list of Microsoft's IPs just to have it bypass TE when the URL is very clearly showing in the logs. It doesn't appear you can create a TP profile based on URL's, only scope. I just upgraded to R80.40 on one of my firewalls so I just tried using the new Updatable Objects as part of this. The docs for the updatable objects uses HTTPS inspection exceptions as the example, but I was presuming it could also be used in the Protect Scope column of a TP rule? I tried this, but it is skipping right over my TP rule with TE/AV disabled and is hitting the next rule where TE is still kicking in just like always.

Is there any other way to handle this? I thought I've seen references to a CSV file you can use with URL's loaded in it, but I'm not sure how to do that. I'll I'd really like to do is just bypass TP entirely on selective URL's/domains.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Rob_Bush — Thu, 30 Apr 2020 17:30:42 GMT

Bump.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

TP_Master — Sun, 03 May 2020 10:16:40 GMT

Hi @Rob_Bush !

Yes you can definitely use the Updateable Objects in the Threat Prevention policy as you intuitively understood - in the Protected Scope, Source or Dest columns. You can also use a custom URL exception.

To help you it'd be great if you can share a screenshot of the policy in question - and I'll help you configure it. You can also do that via a DM but I'd rather it be public so that others can enjoy the question&answer.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Rob_Bush — Mon, 04 May 2020 16:54:28 GMT

Thank you so much for being willing to help!!

Attached is a screenshot of what I attempted. Unfortunately this Threat Prevention rule did not work as I still have TP being engaged on the Microsoft Update traffic (and just to be clear, I am also bypassing this same for HTTPS, but the TP is kicking in on non-HTTPS traffic to Microsoft update, which I'll include a screenshot of as well.)

The only thing I can think is that the "Microsoft - recommended HTTPS bypass" updatable object says it is grabbing all IP's related to "*.dl.delivery.mp.microsoft.com" and "*.delivery.mp.microsoft.com" (among the many url's) but this traffic that I'm seeing is "2.tlu.dl.delivery.mp.microsoft.com" so it's possible it's not matching because it's one level deeper ("tlu") than the deepest level shown on sk163595? I wasn't sure how the wildcard on the SK matched, and if would require the match to be to "*.tlu.dl.delivery.mp.microsoft.com" to work?

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Rob_Bush — Wed, 20 May 2020 21:21:47 GMT

@TP_Master - Bump.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

TP_Master — Sun, 24 May 2020 10:57:57 GMT

Hi @Rob_Bush let's try another way.

Create a custom site with your site

Then add an exception using this newly created object

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

HristoGrigorov — Sun, 24 May 2020 11:50:12 GMT

Just to mention that in this case there is another, more performance oriented way and it is to use the so called "Null TP Profile". It is essentially profile with all TP blades deactivated and it is described with details in @Timothy_Hall's Max Power book which I highly recommend.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Timothy_Hall — Sun, 24 May 2020 12:01:42 GMT

Creating an exception does not bypass the TP blades, it simply changes the final decision to Inactive or Detect. I suppose this approach could be construed as "bypassing" them since traffic matching the exception cannot be blocked, but that traffic still goes through all the relevant TP blades with the resulting overhead. As Hristo said a null TP profile is the best way to accomplish this.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Rob_Bush — Tue, 26 May 2020 14:44:04 GMT

Thanks all.

I'm not sure if you guys looked at the screenshots I put up? I think you'll see I'm attempting to use a Null profile with all blades turned off for the "Microsoft - recommended HTTPS bypass" updatable object. It is not working. (In my screenshot you'll see I named my null profile "Internal_All_Off".)

I'm not trying to handle this via exceptions as I already know that exceptions serve a different purpose.

I'm guessing you cannot use updatable objects in the "Protect Scope" column of TP profiles, otherwise this traffic would not be hitting the TP blades right now, and yet clearly it is. OR... as I wrote/questioned before...

"The only thing I can think is that the "Microsoft - recommended HTTPS bypass" updatable object says it is grabbing all IP's related to "*.dl.delivery.mp.microsoft.com" and "*.delivery.mp.microsoft.com" (among the many url's) but this traffic that I'm seeing is "2.tlu.dl.delivery.mp.microsoft.com" so it's possible it's not matching because it's one level deeper ("tlu") than the deepest level shown on sk163595? I wasn't sure how the wildcard on the SK matched, and if would require the match to be to "*.tlu.dl.delivery.mp.microsoft.com" to work?"

I don't have access to a good lab environment to test this out. Is there any chance anyone could try the same in a lab environment and tell me if you get it to work when using updatable objects? It doesn't even have to be the "Microsoft - recommended HTTPS bypass" updatable object, any one of the updatable objects will work just to prove it out.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Frank_Jacques — Wed, 18 May 2022 18:32:02 GMT

Ever got this to work ? it is still doing on 81.10... VERY annoying

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

r1der — Sat, 09 Dec 2023 00:05:15 GMT

I'm curious too if you got this to work. I'd still like TP to work but to create exceptions for Microsoft.

I'm getting a lot of logs for cab files to microsoft.com even though we've added a an Global exception.

I'm not using a Null profile though, since I don't want the server to completely bypass TP blade.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Chris_Atkinson — Sat, 09 Dec 2023 12:01:00 GMT

You just don't want to see the logs or there is another reason for the exception?

The verdict returned in those logs is "trusted source" or "file size exceeded" ...

Refer also:

https://community.checkpoint.com/t5/Threat-Prevention/Bypass-Windows-amp-Office-update-from-TP-AV-amp-Sandboxing/m-p/142870

sk114522: Threat Emulation Detect log shows "File exceeded size limit" when an exception is configure for specific traffic

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Timothy_Hall — Sat, 09 Dec 2023 14:29:54 GMT

Tagging @Rob_Bush @FrankK @TP_Master

The following blade-based global exception should do what you want. Unlike a protections-based exception which only changes the final verdict (Prevent/Detect) but still performs the full deep inspection, a blade-based exception with an Action of Inactive completely skips processing the matching traffic for the configured TP blades, thus saving large amounts of overhead.

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

r1der — Wed, 20 Dec 2023 16:47:20 GMT

I guess it's annoying me again because I looked at the Threat Prevention reports and was wondering why the amount of the logs is extremely high due to the Threat Emulation. I'll take a look at those threads/SKs again. Apparently, I've been on that thread too due to this activity. 😅

Re: Is it possibly to bypass the Threat Prevention/Emulation blade entirely via URL?

Chris_Atkinson — Wed, 20 Dec 2023 22:53:22 GMT

Understood, maybe there is a case for an RFE please raise it with your local SE.