Slashdot Mirror
To Allow or Not Allow E-Mail Attachments?
t0pper311 asks: "I work for a pretty large utility company in the midwest and of course, security is a big concern. We use Trend Micro as a mail gateway to basically scan for virii and strip off most attachments like executables or VB script. Now with the Sobig.E virus on the loose, we need to ask ourselves if we should be blocking ZIP files. We got lucky this time and were not effected, but what about next time? What are other companies doing? If you do block ZIP files, how do you give the people who need to sends files the ability to do so? Do you allow any attachments at all?"
Pretty simple really.
Given that most users love to download crap via hotmail etc. , lets hope you have a virus scanner on their PC too.
The plural of "virus" is "viruses."
You mean "affected," not "effected."
would one have to block zip files? just scan the contents of the zip files for the virus, all of which have been stuff like .pif or other windows-ish things.
From what I can gather from the virus information, it's not an Outlook virus. It's a Windows virus that propogates through its own SMTP routines, harvesting email addresses from a variety of local files. In Outlook it requires the user to extract the executable and run it, just like any other mail client.
10 years ago, on BBS (bulletin board system), every time someone uploaded something, the system automatically unpacked the { zip | rar | arj } on a temp directory. Then the content of the archive were automatically checked for virii with *MANY* anti-virus like MacAfee, FProt and MSAV (if the BBS were DOS-based). If the archive passed the test, it was made available to download by other user. Then, the temp directory was cleaned.
Actually, the virus he talks about only works through social engineering. You have to manually open the zip file and click the .exe file.
The problem in this case is that some viruses don't actually need email to propogate. This particular one just needs someone to open it and run it. Doesn't matter if it came in via FTP, Email, or Kazaa.
- Muggins the MadScanmail has catches SoBig.E (since June 25th). It also looks inside .zip's.
I think the question refers to the additional levels of defence, what you need to do to minimise the risk in 'those hours' before the new signatures are released. It's a good question.
Make sure you have desktop protection as well, a different company would be a good idea.
Configure Outlook Security settings to force an explict 'save to disc' for riskier file types. This both makes sure that you've two independent checks and you get people to think a little before openning....
This is not a hard thing to do at all. I assume you are using ScanMail. This applies to ScanMail 6, but I recall from memory that older versions were basically the same. Open up the ScanMail Magement console. Click the 'Virus Scan' tab and then 'options'. Now, on the right, click the 'settings' button for 'advanced options'. Check the box 'Enable Compressed Attachement Scanning'. Have a nice day. -Tom
The chroot command should help.
Here's what I did with postfix.
/^(Content-(Type|Disposition):.*|\s*(file)?)name=( "[^"]*|\S*)\.(ade|adp|bas|shm|cmd|com|dll|hlp|js|j se|exe|com|chm|hta|jse|reg|shb|shs|vbe|vbs|vxd|scr |pif|bat|lnk|dll|vbs|js|mp*)\b/ REJECT
/^(Content-(Type|Disposition):.*|\s*(file)?)name=( \S*your_details)\.(zip)\b/ REJECT
in my main.cf created a line that says
body_checks = pcre:/etc/postfix/extensions
then created a file called extensions that looks like this:
The first line (yes it's all one line) blocks all executable files from entering the server. The second line block the only version of sobig that we received. Actually we received 2 modifications...one attachment was called your_details.zip, and the other was 'your_details.zip the ' allowed it to get around the filter, hence the wildcard.
The key is, to inform your users over and voer not to open things from people they don't know or aren't expecting. If you start blocking zip's you might as well block all attachments.
/* oops I accidentally made a comment, sorry */
Here's a simple solution used by a number of organisations down here in New Zealand.
If an email with a forbidden attachment type is received, bounce it back to the sender with a "Sorry, no go" message UNLESS it has a matching flag in the subject line.
So, to send a friend of mine a picture, I need to include [JPG] in the subject line, else it will bounce.
Simple, easy, and proof against viri because YOU choose the flag.
In your case, set it up to require [FUBAR] in the subject line to let a zip file through.
Sorry though, I don't know the software package they use.
Maybe I don't understand this problem in detail, but I thought the rationale for blocking attachments was either the real file type displayed was hidden or that the user doesn't know a specific attachment is an executable.
Why don't Microsoft display all attachments that would be executed in a unique way or have a dialog come up confirming execution? Or display the whole filename and not hide any file types?
I agree: new Outlook Express default policy is even more brain dead. One cannot even download and save attachments unless this virus option is turned off.
Sobig.E came out before the virus scanners had signature updates. When viruses spread so fast these days about all you can do is push your email through MessageLabs who have never let a virus through to a customer due to their custom AV scanner which uses heuristics instead of signatures.
Your point about not relying on any one point of access is well taken though - all entry points need to be protected in one way or another.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Here's what we do:
1. Use Symantec Antivirus for SMTP Gateways 3.1. Blocks spam by subject, sender, multiple RBLs and heuristic antispam and has whitelist support. Scans for viruses and attachments can be deleted by filename with wildcards. I block anything that is executable in a Windows environment (since we use Windows, Exchange and Outlook -- no flames, please). Any file deleted gets a .txt file added to the message stating that <filename> is not allowed for security reasons. This means that if anyone needs to send a .exe, .cmd, .bat, .vb?, .cpl, .dll, and a number of others must first call so I can temporarily disable the deletion.
2. Use another company's antivirus on the mail servers. We use Sybari with multiple scan engines. This saved us this past week when the new FortNight.E managed to get past SAV for SMTP because it didn't detect it yet and it was essentially a script embedded in an html. (I'd love to strip them, too, but too many legitimate emails come through as html.) Sybari caught it after Symantec missed it.
3. Use another antivirus package for clients and servers. We use SAV Corporate edition with a master server setup so that one server d/l's updates from Symantec nightly or when I force it. Each remote location's server d/l's from that server nightly or when I force it. Each workstation d/l's from their location's server every 4 hours.
Since starting this practice, we've had a total of 2 viruses make it into our network. One was on a laptop that, for some strange reason never got antivirus installed and it was infected at the user's home. The virus never got further than that, but it took a while to discover where the virus alerts were coming from when it attempted to infect other machines. The other one had a corrupt install of the desktop antivirus and the end user didn't let us know that something didn't look right on his client. He then fell for the e-card virus (Go to this URL to download the greeting card X sent you.). Again, never got further than this one workstation. This is all the infections we've seen in over 2 years. Not bad for a 1500 user network.
But why is the rum gone?
It depends on your umask AND the permissions the application requested for the file. Apps typically request 0666, and umask typically removes 002, 022, 027 or 077. In other words, apps typically request rw-rw-rw-, not rwxrwxrwx. Typical umasks will remove -------w-, ----w--w-, ----w-rwx, or ---rwxrwx.
In either case, the final permissions of the file tend to lack 'x' (execute permission) for user, group AND other, and it's not usually as a result of umask.
--JoeProgram Intellivision!