Do you filter out ZIP files from emails?

My question is:

Does your company remove (filter out) ZIP file attachments from emails?

I'm being asked by my company to review our policy on this and need data regarding other companies.
Thanks in advance.

Currently, we do not, but I too am in the process of taking at look at our current policies and revising as needed. I haven't made a decision as of yet regarding .ZIPs, but certainly we will continue to block any executable (.EXE, .COM, etc.). The problem with the .ZIPs is that there is some malware that is transferred via password protected .ZIP files in which some AV scanners couldn't pry into...

We remove only password protected .zip files.

Our antivirus gateway will scan within zip files, if it's a virus, it's gone, if not, it is passed on to its destination. Like cacosapo said, if its password protected its also deleted because the gateway can't open it to scan it.

Cheers:

We strip zip files only when they are password protected or a file inside them is infected.

We also strip all file types that are potential problems... dll, reg, exe, com, pif, etc

We strip Zips, (password protected or not), because I prefer to see the raw files themselves anyway. Generally this does not present a size issue for my company because most attachments are small(ish) Office docs.

We also block all executable content. Should executable content be required we will issue a login/passowrd combination to the FTP server in the DMZ and the user can place it there.

Same here..

zips are stripped and contents scanned..
MS executables (including but not limited to .exe .pif .scr .bat .cmd) are removed..

We remove zips, unless specific notice is given, we have never had people send us zips intentionally, if I worked at a place where we used zips more frequently, then I probably would work out a stripping solution like stated above. But since we dont use them 99.9% of the time, its just one less thing to have to support at the moment.

Hi ric-o, the general consensus seems to be removing the zip file. Or at a minimum the password protected files since virus scanners can't open them. I side on removing only password protected zips. We've gone back an forth on the issue since some customers have asked for information in a zip format. If I was going to decide to block zips today it could be done in seconds but could hurt the enterprise because of the way exchange and the virus scanning engine interact. Once that decision is made ALL messages, even those that have been setting in someone's inbox for months get cleaned. I would make an effort to see who uses them and in what aspect as well as the security aspect of monitoring files as they cross the mail servers.

[Harping on]

AV is reactive..... Blocking only Zips that are password protected and scanning the rest is no guarantee whatsoever that the enclosed code is not malicious.... Only that it is not recognized as malicious. Any Zip file can be self executing. If the AV product could also block self executing Zips then part of the battle would be won. Even if it could there will always be the trivially socially engineered user that will still click on the executable content of a zip file if it is delivered to them.

If your users are sophisticated enough to comprehend _executable_ content and zip files then they are easily able to comprehend passing files through a password protected FTP site which instantly mitigates email-borne threats. If they aren't then they don't need them anyway. If the sender sends a zip then they will be competent enough to unpack the file and send it in clear at the request of the recipient if it is only a jpg, tiff, word/excel/powerpoint doc. Since these are no longer common vectors the AV can pick them up easily and if the App is patched or more up to date then the auto-running macros can be prompted for or denied anyway.

Even if you are a shop that requires executable content to pass between a sender and a recipient there are less vulnerable methods of doing it. Why risk any exposure when none is necesary in a corporate environment?

[/Harping on]

We don't allow zip files, exe files, bat files, com files, scr files, reg files, etc... The only zip files we allow are ones with JCP_ in the name. Everything else is deleted explicitly.

Tiger Shark has the luxury of a not for profit environment. :D

Antivirus is reactive to all vulnerabilities in email attachments. JPG and the MS GDI exploit are a prime example. I did reactively block JPGs for a day. My god the heat I got for that was amazing. Deals were actually put on hold while I made sure the GDI hole was fixed. In one case I had to let a jpg in from a customer. Besides a user that has the ability to comprehend an exe or a zip will just rename it anyway. ;) Like I said we have gone back and forth many times on the zip issue. Business needs in this case dictate risk versus vulnerability. Even at the reactive stance. The only proactive measure that is fool proof is denying all attachments and forcing customers to use secure gateways and in many cases the critical nature of our relationship demands it. But not for every one we interface with depending on who a customer has as their own interfaces. It's very dynamic.

There is a "user" point of view and then there is a "customer" point of view. At least for me. If the zip is malicious how does the FTP server determine with more accuracy that the payload is malicious? It's the same file and in my case the same scan engine. If I am missing the obvious outside of someone testing every file the comes in from customers, "known" customers, then bonk me on the head. Because that interaction isn't going to happen based on statistical risk and a history of the few infections I have had in the past. Although that is a good idea if I can get them all to accept it, in all their diversity and technical levels. It's easy to say you don't need them, when if fact we do. ;)

Quote:

---

There is a "user" point of view and then there is a "customer" point of view. At least for me. If the zip is malicious how does the FTP server determine with more accuracy that the payload is malicious?

---

The FTP server _proves_ that the sender _is_ the sender and that they _really_ want to send the .zip

Quote:

---

It's the same file and in my case the same scan engine. If I am missing the obvious outside of someone testing every file the comes in from customers, "known" customers, then bonk me on the head.

---

*BONK*

Quote:

---

Because that interaction isn't going to happen based on statistical risk and a history of the few infections I have had in the past. Although that is a good idea if I can get them all to accept it, in all their diversity and technical levels. It's easy to say you don't need them, when if fact we do.

---

I blocked .jpg's for 4 days until it became apparent that there was no serious email-borne attempt to exploit it.... When I unblocked it I also implemented Snort rules to pick it up in HTTP and left the AV to remove IFRAME issues in mail, (a more likely attempt to exploit the issue). But I got heat too in those four days, (we have PR depts etc.), but there is a workaround on my system... and on yours too I'm sure...

Rather than make senders jump through a bunch of hoops just have them rename the zip file to .txt before they send it..... My firewall reacts on the extension..... .txt is not blocked.... The recipient simply has to rename it to .zip as they save it..... Even that little "bit of authentication" gets rid of the generic rubbish that gets passed around.... works for me....

:D

Lol, no offense to say somone in a construction business but after about 7 phone calls on "how do you raname the file, where are they stored after I take the pictures, what is my computer, this is BS I'll just go over to the other place." I opened up jpgs after the first day and just watched a little closer.

Bonk taken.
The FTP server would ID the person. Wish they were smart enough to use it, plus that would add another Risk by opening up an FTP server. I don't use one currently on said netwrok. So risk of FTP exlpoits and an open server where there isn't one on I-net versus someone clicking on a non password protected zip file that is self executable, and contains malicious code not detectable by VS. Bonk Bonk Bonk. :)

Thanks for all the great replies everyone!

If you haven't figured it by my message, my company blocks ZIP files on emails - ALL ZIP files - per MY policy. This is our practice of DEFENSE-IN-DEPTH with AV.

The reasoning is similar to others: threat of infection from the thousands of encrypted ZIP files sent by worms. The threat is VERY prevalent: in a 3 month period 96% (yes 96 PERCENT) of the ZIP files we received were virus-ladden. EEEK!

One argument presented here as well by our management is to allow ZIP files to be delivered and just let the local AV sitting on the desktop handle the scanning and blocking of infected files. My policy is to never allow a virus to be delivered to the mailbox in the first place...why give the user an opportunity to open the file (naw, they never do that? :eek: ).

Now I would like to just filter out encrypted and password protected ZIP files which will take out all those critters, as some of you do today (lucky dogs), but unfortunately our AV software on our mail server can't do this...we are looking into content filtering software add-on which we will do this.

So for now I'm building my case FOR this filtering to present to management and will include this very non-scientific, security-biased albeight, poll data as a data point. I fear that

Thanks again for all the good comments.

Quote:

---

We strip zip files only when they are password protected or a file inside them is infected

---

well ive a scenerio what happen if you have a zip files whic contains data which is confidential and large tooo. do you delate it .?? i mean yess we need security but isn;t it kinda missing the point of internet?i may be wrong.

zip files are only dangerous when they are opned , may be we can have a Antivirus which can brute force the zip file and then scan it ?yes this would eat up a lot of time , but then this is both security and convergence

ric-o,

Since you are already blocking the zip files there is no real business case to take the risk. It's good that you are taking a continued look at the process and reafirming decision made in the past. It's good business.