You can use the Yoyo lists in two EDL types, Domain and URL.
With the Domain type, you can block access to the Ads when there is a DNS query to resolve the IP of the server hosting the Ads.
With the URL type, you can block access to the Ads when the host already has a cached IP for the domain, and submits a Client Hello with a matching SNI, or matching the HTTP GET. For HTTPS sessions you need to combine this solution with SSL Decryption to be able to pick up on the HTTP GET message inside the encrypted session.
The way that I implemented this is:
EDL as a Domain list 'Yoyo Ads - Domains':
EDL as an URL list 'Yoyo Ads - URL':
I configured 'Yoyo Ads - Domains' under my Anti-Spyware profile to block:
Note that the drawback of this solution is that the Threat logs will still get filled up with 'Suspicious DNS query' drop alerts for TID 12000000 - I couldn't find a way to create a logging exception.
The next step was to configure a Security Policy that precedes my 'Internet access' rule to block any Client Hello messages containing a matching SNI. This will take care of HTTPS sessions that got as far as resolving to an IP and attempting to initiate an SSL session to the Ad servers in the list.
You could remove the checkbox for 'Log at Session End' to reduce logging in the Traffic logs if you're not interested in logging for this.
Finally the last step is, if any clear text or decrypted HTTP makes it through, we block the Ad with URL filtering, which profile is tied to our Internet access security rule.
Note that this should be combined with SSL decryption to extend coverage for encrypted HTTP(S) traffic. To make SSL Decryption effective for Chrome browsers, configure a security policy that precedes these rules to Deny 'quic' traffic.
Finally my Security policy set looks like this:
(The Sinkhole rule ties to the sinkhole action for Palo Alto Networks DNS Signatures in the Anti-Spyware profile, you can alternatively choose to sinkhole your 'Yoyo Ads - Domains', but as a result, that will mix your Traffic log entries for compromised host detection, as both, an infected host, or a host browsing to an advertisement will result in a 'subsequent' connection to the Sinkhole IP - so instead - using block for Ads will help you prevent the unintended Traffic log pollution).
If you have better ways to implement this please feel free to pitch in.
I set this up as you describe and it appears to be working great. I see the denies in the various logs.
Your post is over a year old. Do you have any words of wisdom to add to it since then?
My commit alert is telling me I need to enable certificates. Will look into that next.
With the release of PAN-OS 8.0, there are a couple things to add. Even though you won't be able to except TID 12000000 from writing to the Threat Logs, you can actually define a log forwarding filter to prevent these from propagating to Panorama or Splunk (Syslog).
For a tutorial see:
Also, if there happens to be any domain that needs to be excepted, you can now search and Except domains directly from the EDL's.
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 Live Community as a whole!
The Live Community thanks you for your participation!