Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
the_rock
Legend
Legend
Jump to solution

Content awareness issue

Hey guys,

I hope someone can clarify this for me, though Im pretty sure how it works, but need to see if there is any way around it. So, to make long story short, customer has https inspection enabled, vpn, url and app control, as well as IA and monitoring.

They want to block certain machines from being able to download any exe file off the Internet. Now, this does work, but ONLY if source in content awareness ordered layer is set to any, not if you use specific PC or subnet. Also, if that specific machine is set to bypass google services in https inspection policy, then content awareness does not take place at all.

I replicated this in the lab and its exact same issue and we even have TAC case as well for this. Here are my questions:

1) Considering https inspection takes place before regular policy, does this mean once this traffic is bypassed it wont check anything else after?

2) If 1 is indeed true, is there ANY way to get around this?

Also, I attached 2 screenshots from my lab. If I disable bypass rule for inspection policy, then all exe files are blocked on windows 10 I use behind the fw.

Tx as always!

0 Kudos
1 Solution

Accepted Solutions
the_rock
Legend
Legend

Had call with escalations and here is what DOES work. So, we disabled bypass rule to updatable objects in https inspection policy and then added rule to ALLLOW them in app / urlf ordered layer and that works fine, as it allows content awareness layer to work, since inspection happens. Otherwise, when bypass is there, then content awareness wont take effect.

Please see below:

Screenshot_1.png

View solution in original post

0 Kudos
9 Replies
the_rock
Legend
Legend

Issue solved after working with TAC escalations. Key is to NOT have specific updatable objects bypassed in https inspection, but rather allow in ordered url / app control layer. If they are bypassed in https inspection, then it will never hit last ordered layer, in our case content awareness, since https traffic would have already been processed.

Update from TAC:

 

Inspection allows the firewall to go inside the packet and view the unencrypted data thereby classifying the file type, file name etc which is downloaded/uploaded. More on content awareness, after these attributes are identified the usermode processes verify if such content is allowed or blocked. The decision/verdict is provided to the rule base execution engine and the final enforcement block/accept is enforced accordingly. 

The reason why this is not in the document is due to the fact that this is only relevant for HTTPS service and not other services like FTP. 

I understand their is a concern with the Google Services which will be more clear after discussion with the customer, however until that point please feel free to test the content awareness for  HTTPS connections with inspection enabled and let us know if their are any issues. 

 

PS...I thought this was the solution until I had to reboot my mgmt server and then it did not work at all...makes no logical sense. Then when I rebooted gw and windows lab machine, it worked for maybe 30 mins and stopped again. I will update once I talk to escalations again.

Sorin_Gogean
Advisor

hey @the_rock ,

 

Could you get the expected behavior if you had combine the Content Awareness with Firewall blade, and with App & URL Filtering ?

That way your packets would have hit the Firewall policy and then the Content Awareness part...

Capture.JPG

 

 

Ty,

 

 

0 Kudos
the_rock
Legend
Legend

We tried, but no luck...:- (

the_rock
Legend
Legend

@Sorin_Gogean ...just to add something else...and I will speak today to same escalation person in TAC about it. What I find super odd is that google chrome behaves totally inconsistent with this content awareness feature. So, say if I reboot my lab gateway where windows lab test pc sits behind doing https inspection, exe files will NOT be blocked, but they WILL be blocked in IE and mozilla. I dont get it...maybe its related to below CP sk, but already did that and still same issue

 

 HTTPS traffic to Google services (over QUIC) from Chrome cannot be inspected by HTTPS inspection rul...

 

But, even with IE and mozilla, thats not consistent all the time. I really have a feeling this blade does not work right at all when it comes to CP. If I cant have it working right in simple lab, I have no confidence to ask the customer to implement it fully in production.

0 Kudos
Marcel_Gramalla
Advisor

Have you checked the HTTPS Inspection settings regarding Background/Hold Mode:

 

And we also block QUIC (udp/443) in order to achieve what we want. And after a lot of tweaking we are pretty happy with Content Awareness etc.

0 Kudos
the_rock
Legend
Legend

Thanks @Marcel_Gramalla ...we did implement below, but no luck

HTTPS traffic to Google services (over QUIC) from Chrome cannot be inspected by HTTPS inspection rul...

If you are referring to setting under blades -> app control and urlf -> advanced settings -> its set to background, but I tried other ones too, same issue.

0 Kudos
Marcel_Gramalla
Advisor

Unbenannt.PNG

 

Huh..the screenshot got lost. I mean this setting above in the good old HTTPS Inspection Dashboard.

0 Kudos
the_rock
Legend
Legend

O yea, tried that before, no change.

0 Kudos
the_rock
Legend
Legend

Had call with escalations and here is what DOES work. So, we disabled bypass rule to updatable objects in https inspection policy and then added rule to ALLLOW them in app / urlf ordered layer and that works fine, as it allows content awareness layer to work, since inspection happens. Otherwise, when bypass is there, then content awareness wont take effect.

Please see below:

Screenshot_1.png

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events