SSL decryption policy - strange behaviour

[S_Owoc]

Hello guys,

Recently I had a situation where Cisco Webex traffic was decrypted by policy - let's call them "URL_policy"

'URL_policy" was set to decrypt traffic based on the categorization of URL likes: drugs, extremism, gambling, adult, malware, nudity, etc - nothing business-related for sure.

Just after this policy was my "webex_do_not_decrypt" policy, based of destination IP

https://help.webex.com/en-us/article/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network?#id_...

For an unknown reason, Webex traffic hit the first rule, why?
Here you have examples of destination IP which belongs for Cisco Webex services:

( addr.dst in 170.72.131.16 )

170.72.0.0/16 170.72.0.1 - 170.72.255.254

( addr.dst in 209.197.208.182 ) and ( addr.dst in 209.197.208.148 )

209.197.192.0/19 209.197.192.1 - 209.197.223.254

NSLOOKUP shows:

Name: m09txmcs182.webex.com
Address: 170.72.131.16

while two others don't have DNS records assigned, but belong to Organization: Cisco Webex LLC (WEX)

I asked PA TAC and got the explanation that due to technical limitations on PANOS 9.1 there is no way to check why - really??!?

I know how to check reputation of URL (https://urlfiltering.paloaltonetworks.com/query/)

Help me please to understand why the traffic hit first policy

With regards

SLawek

[Remo]

Hi @S_Owoc 

Could you share some screenshots or config snippets of the rules and also screenshots from the URL and/or Traffic Log of that connection? Actually I do not really agree with TAC - maybe there was a misunderstanding - but there definately is a way to check why it hit rule 1.

[S_Owoc]

Hi @Remo 

Unfortunately, I can't share screenshots here, those policies are very basic (from inside to outside any any - and the only thing is that 'URL_policy" has some URL category assigned to it - nothing else.

What I can share is:

sowoc@FW01(active)> test decryption-policy-match from Inside source X.X.X.X destination 23.89.0.11
Matched rule: 'URL_policy' action: decrypt

and show session:

c2s flow:
source: X.X.X.X [Inside]
dst: 23.89.0.11
proto: 6
sport: 49496 dport: 443
state: DISCARD type: FLOW
src user: unknown
dst user: unknown
offload: Yes

s2c flow:
source: 23.89.0.11 [Outside]
dst: X.X.X.X
proto: 6
sport: 443 dport: 49496
state: DISCARD type: FLOW
src user: unknown
dst user: unknown
offload: Yes

Slot : 1
DP : 0
index(local): : 8206204
start time : Mon Apr 4 13:18:59 2022
timeout : 90 sec
time to live : 7 sec
total byte count(c2s) : 759
total byte count(s2c) : 6528
layer7 packet count(c2s) : 7
layer7 packet count(s2c) : 12
vsys : vsys1
application : ssl
rule : SEC-RULE
service timeout override(index) : False
session to be logged at end : True
session in session ager : True
session updated by HA peer : False
layer7 processing : enabled
URL filtering enabled : True
URL category : any
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
session terminate tunnel : False
captive portal session : False
ingress interface : ethernet1/5
egress interface : ethernet1/6
session QoS rule : N/A (class 4)
tracker stage firewall : proxy decrypt failure
end-reason : decrypt-error

Why the IP "23.89.0.11" is recognized as one of the "bad" urls?
according to https://urlfiltering.paloaltonetworks.com/query/
it has:

Category: Unknown Category: Medium Risk 

any tips how to understand PANOS behaviour here?

Regards

SLawek

[BPry]

@S_Owoc,

I find the way that your ordering those policies to be slightly suspect. I always recommend that any no-decrypt action entry goes above any decryption entry. URL categories can get screwed up for any number of reasons, for example if someone shared a malicious file through a Webex meeting, so exceptions should always go first to prevent this sort of issue. 

[Remo · Accepted solution]

I agree that the order is suspect from a best practice point of view (decrypt all and only create very specific exceptions). If the plan is to only decrypt the known bad categories, then the order somehow does make sense.

@S_Owoc the behavior is normal that you see because this IP is in unknown url category and I assume you decrypt this category right? The category is unknown as when you connect to this IP by https there is nothing shown to you so there is actiually nothing to categorize for PAN-DB. Another thing is if the url really is this IP or is there maybe something else? This you might see in the URL log or if this is not the case then at least in the TLS handshake you might find it.

[S_Owoc]

Hello guys

I agree with you that any no-decrypt action entry goes above any decryption entry, but in my case decrypt rules are applied only to "bad" traffic based on URL filtering.

@Remoyes, I've doublechekced and unknown url category is under 'URL_policy' which in my opinion is the explanation of this mystery. Thank you for pointing it out.

regards

SLawek