Allow download of file types that show as ZIP

[gsvarney]

Hello,

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.

Geoff

[rmonvon]

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.

[gsvarney]

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.

[rmonvon]

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.

Thanks.

[EdwinD]

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;

liveupdate.symantecliveupdate.com
liveupdate.symantec.com

update.symantec.com

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 8.8.8.8 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.

[mikand]

What about something like:

srczone: internal

sourceip: any (or just your updateserver so not all clients must reach internet)

dstzone: external

dstip: any

appid: symantec-av-update, web-browsing (due to dependency for web-browsing - hopefully this is fixed in PANOS 5.x)

service: application-default (could also be narrowed down to just TCP80)

option: url-category: Symantec

Where your custom url-category Symantec contains:

liveupdate.symantecliveupdate.com
liveupdate.symantec.com

update.symantec.com

and configure your symantec clients to only use http/https (well at least not ftp) for updates (or for that matter direct your clients to a local server and only allow this particular server to sync its db with symantec on the internet)?

[EdwinD]

That fails to install.  It says that FTP is required for symantec-av-update.  I like the idea of using the Web filter to confine the destination, but that would result in blocked FTP events in my firewall logs as you allude to.   For my environment, my method keeps the blocked logs clean.

>>and configure your symantec clients to only use http/https (well at  least not ftp) for updates (or for that matter direct your clients to a  local server and only allow this particular server to sync its db with  symantec on the internet)?

I can point my managed machines to use internal live update or just use HTTP, that's not a problem.  I'm already using internal update servers (GUP, Management server..)  and I have a live update server installed but not in use.  I can't point unmanaged laptops to my internal live update server, though.

I suppose I could point the live update DNS IP address to my internal live update server.   However, then I would have to configure my internal live update server to download everything that Symantec offers through live update.  That includes Backup Exec updates, System Recovery 2011 updates, Brightmail updates.   We are talking many hundreds of GB of updates.  If I don't, then those products will no longer update.   We do run those products.