Do you filter out ZIP files from emails?

[Vorlin]

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.

[RoadClosed]

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

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.

[Tiger Shark]

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

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*

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

[RoadClosed]

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.

[ric-o]

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? ).

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.

[yourdeadin]

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

[RoadClosed]

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.