- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-27-2018 01:13 PM
Hi,
I have a security rule that's supposed to be only allowing traffic for URLs in a custom URL category. However, it appears that it's matching lots of other URLs that aren't in the category. Below are some screenshots. I'm running v8.0.6. Let me know what other info you might need and what I'm doing wrong. Thanks.
Matt
Security rule showing URL category specified:
Custom URL category:
Unified log showing other URLs not listed above matching security rule (e.g. first and last lines):
02-28-2018 09:52 AM
This is usually caused because you've allowed akamai.net as a URL. You only actually need to allow the following.
02-28-2018 01:30 PM
Hi @mprintz
What you actually have in this screenshot are connection attempts. In the screenshot there are no urls in the URL column in the monitor tab, so the firewall was not able to apply the url category. But this does not mean that these connections were successfullly established (also because of the app incomplete - I assume the bytes (received/sent) are only a few, not much more that a tcp handshake and a tls handshake).
The firewall has to allow some packets in order to get to the packet where it could allow/deny the traffic based on the actual url.
03-01-2018 05:59 AM
@Remo Thanks, that makes sense. I didn't realize the handshake is considered a different session than the data that follows it. I also moved the rule down in the list (as it's not as frequently used as others) so other rules are hit first.
02-28-2018 12:14 AM
Hi @mprintz,
I believe something went wrong when uploading the screenshots.
Cheers !
-Kiwi.
02-28-2018 05:35 AM - edited 02-28-2018 05:36 AM
Sorry about that, not sure what happened. I could even see them when I did the preview. Let's try again.
Matt
Security rule:
Custom URL category:
Log - in this case, lines 3, 6, & 11 showing the mismatched URLs:
02-28-2018 07:00 AM
Hello,
I'm not able to see the images.
Regards,
02-28-2018 07:18 AM
Wow, I don't know what's going on here with the pictures. I see them after posting, but then a few minutes later they don't show up. Let's try it via links instead of embedded photos.
Matt
Security Rule: http://www.harmelin.com/Palo/secrule.png
URL Category: http://www.harmelin.com/Palo/urlcat.png
Log: http://www.harmelin.com/Palo/log.png
02-28-2018 09:52 AM
This is usually caused because you've allowed akamai.net as a URL. You only actually need to allow the following.
02-28-2018 11:15 AM
As BPry said above, the 2 bottom IPs are probably going through something hosted by akamai. I see them listed as zscaler, they might be a cloud platform hosted on akamai.
https://technet.microsoft.com/en-us/library/bb693717.aspx
Same list as above
02-28-2018 11:25 AM
Funny enough while ZScaler is a competitor of some of the features that Akamai provides; they actually utilize akamai for ZEN lookup.
02-28-2018 01:00 PM
As proposed by @BPry and @Rags you should change the url category.
But did you also filter for the destination IPs of these 2 log entries. As this log shows a threat log entry with the subtype spyware these entries don't necessarily mean that this traffic was allowed - 3 log entries aren't enough to say that for sure. It could be that the antispyware feature logged this but after that the traffic was blocked because of the url not matching your custom url category.
(Do you log the theat for TLS evasions? Are these 2 entries such threats?)
02-28-2018 01:19 PM
I changed the Custom URL Category so that it only contains the URLs below, but I'm still seeing all sorts of other URLs in the logs (http://www.harmelin.com/Palo/log2.png). Any other ideas? Thanks.
@BPry We are using Zscaler, so it would make sense that some of the traffic would have been hitting that rule before, if it was destined for akamai and Zscaler uses their service.
Matt
*.update.microsoft.com
*.windowsupdate.com
*.windowsupdate.microsoft.com
download.microsoft.com
ntservicepack.microsoft.com
windowsupdate.microsoft.com
02-28-2018 01:21 PM
Are you decrypting traffic at all or not?
02-28-2018 01:29 PM
@BPry Yes, I am for that URL category and a handful of other URLs (none of the ones in the logs I've posted), as well as some non-HTTP services. However, that's a recent change I made to see if it would fix the problem, but it didn't.
Matt
02-28-2018 01:30 PM
Hi @mprintz
What you actually have in this screenshot are connection attempts. In the screenshot there are no urls in the URL column in the monitor tab, so the firewall was not able to apply the url category. But this does not mean that these connections were successfullly established (also because of the app incomplete - I assume the bytes (received/sent) are only a few, not much more that a tcp handshake and a tls handshake).
The firewall has to allow some packets in order to get to the packet where it could allow/deny the traffic based on the actual url.
03-01-2018 05:59 AM
@Remo Thanks, that makes sense. I didn't realize the handshake is considered a different session than the data that follows it. I also moved the rule down in the list (as it's not as frequently used as others) so other rules are hit first.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!