12-13-2011 11:35 AM
I have had a few instances where I've needed to allow certain files types through the data filter. One annoying case was native Office 2007/2010 documents that end in x. What I did was add it to my file blocking profile with the action of ALERT. This is now letting them in. Sometimes I actually have a FQDN or IPs that I can use to allow EVERYTHING in from certain sites, but sometimes that doesn't work. I have 2 examples where I am having issues with this.
First, Symantec AV updates. We have contracted employees working in my school district who have their employer-provided computers. As we don't manage them, their Symantec AV updates over the Web. However, these are ZIPs and are blocked. I tried allowing Symantec-AV-update, but that also depends on HTTP and FTP. I couldn't find a good way to use a policy to allow that. Especially as I don't have a FQDN or IP to allow stuff in explicitly. The servers I see getting blocked resolve to something like axx-xx-xx-xx.deploy.akamaitechnologies.com. I've seen other stuff using these exact same servers, so how do I deal with that? I don't know how many of these servers might be accessed by SAV, either. Anyone else dealt with this?
Finally, my latest is an uknown file type, used for educational software. Some of the blocks (ZIP, of course) show Akamai servers, but there are others also. This file type is as3a. As PA doesn't list that one, can't use my other file blocking technique to just allow all .as3a files either.
Thanks for any help you may have.
12-13-2011 07:06 PM
Hi...For Symantec updates, What do you mean by it depends on HTTP or FTP? Have you try allowing app=symantec-av-update because that should cover the download for Symantec updates.
For the other file types like .as3a, you can try to match on its file extension by creating a custom application.
Enclosed is a custom appID to look for .jpg images inside of HTTP traffic. This custom app was written for PAN-OS 3.1.x but you can reference its signature to create for version 4.0 or 4.1. The signature is looking in the URI path and matching on the string ‘\.jpg HTTP’ without the quote. Typically the web request would look like this:
GET /images/twitter_corp.jpg HTTP/1.1\r\n
GET /images/logo.jpg HTTP/1.1\r\n
You can import this appID into the PAN device and test. Once verified, you can clone the app and change the app to match extensions like .as3a, .scr, .pif, etc.
12-16-2011 10:05 AM
Thanks for the info. Actually, when I create a policy to allow the application symantec-av-updates and commit, the commit window tells me at the end that my policy depends on ftp and web.
I'll look into the suggestion for creating a custom app for file types. Maybe I'll need to do something similar to look for a specific string in the URI for SAV updates also? I had hoped that the application symantec-av-updates would handle the entire update requirement instead of having to add additional apps or services which makes it all the more difficult.
12-16-2011 11:32 AM
What you describe is application dependency. Since Symantec update is using web-browsing (HTTP) and FTP, we have to permit those parent apps in order to detect the child app.
Maybe you can ask Symantec to provide a list of destinations that represent their update servers, or a URL, etc. Then we can define a policy to match.
05-30-2012 11:42 AM
I am having the same problem trying to allow Symantec AV update (only) through. My default access level is BLOCKED. But I want to allow Symantec AV updates to work on machines otherwise blocked.
So to expand on rmonvon's comment, create a rule higher in your rulebase than the rule that normally allows web access to your LAN/trusted network (and perhaps from the DMZ too..)
The source is trusted / ANY while the destinations are untrusted and two FQDN host objects. Create one each for these;
The application becomes ANY and the service ANY.
Because this is higher in your rule base, it allows symantec-av-update to work just to these sites.
At least that is the theory. In practice, the traffic is still blocked. The HTTP/FTP connection sends out a SYN packet, which is blocked by the firewall.
Reading this post explains how FQDN works: https://live.paloaltonetworks.com/message/12006#12006
If I do an nslookup liveupdate.symantecliveupdate.com from my PC, I get an akamia.net address, followed by several ip addresses, and several aliases. If I perform the same lookup on different DNS server or just wait, the resulting IP addresses are completely different. There are a huge number of them.
By understanding the way PAs FQDN objects work, and what Symantec is doing, we can see that a FQDN rule will not work here.... That is.. Unless we modify the DNS.
If we are using DNS Proxy in the PA, we can point liveupdate.symantecliveupdate.com to a select few IP addresses that Symantec uses. Then we can modify our PA security rule to allow access to just those IP addresses (no reason to use FQDN here.) If we run our own DNS servers internally, such as bind or AD DNS, we can add the zone liveupdate.symantecliveupdate.com, and create A records for just a few IP addresses. We do not want to create a DNS zone for symantec.com, we want the ENTIRE name update.symantec.com, as we only want to control that part of the domain.
The downside of this is that you will need to check something like Google DNS 184.108.40.206 and make sure that your IPs are still valid. If you do not do this from time to time, you will find yourself blocking Live Update by blackholing it. So in my case, I've only took control over one of the three FQDNs that Symantec uses for live update. I've setup liveupdate.symantecliveupdate.com, which is the first name that the current version of live update tries. If that fails, it will try liveupdate.symantec.com. So if my trick quits working, I should see symantec-av-update failures against liveupdate.symantec.com. That should catch my eye as I monitor the PA logs.
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!