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

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