VOF dilemma - will stripping EXE's etc. hurt VOF?

[tedski_ironport]

Dilemma - since VOF (Virus Outbreak Filters) are the last step in the message pipeline, do you hurt VOF performance by stripping attachments with filters? Specifically for attachment types you never would allow in anyway (EXE, COM, etc)?

Scenario One
Message or Content filter removes EXE
Outbreak occurs, VOF rule set to trigger on specific size EXE
Since a filter removed EXE, VOF has nothing look for, and you get pounded with thousands of "remnants" - virus messages without attachment. No virus attachment therefore no client damage, but helpdesk buried with support calls/complaints about suspicious but harmless messages.

Scenario Two
No filter to remove EXE
Outbreak occurs, VOF kicks in and stops most messages.
But before VOF kicks in, 15 messages with EXE's get through and infect clients. You are at greater risk since you didn't stop EXE's in the first place with a filter.

Are these scenarios correct? Any best practice suggestions?

[shannon.hagan]

Add a content filter to strip the exes.

This way, you can check for viruses and only take action if the message remains - it won't get to vof. Not a perfect solution but might be more of what you are looking for.

Where I work there are a whole batch of file extensions that are not allowed. We don't strip them in message filters since if they are a virus then the virus checker wouldn't find them. We have a content filter that looks for dictionary match in the X-IronPort-AV header for a dictionary of mass mailers that we know of and drop the message. If it gets past that content filter and still has a prohibited attachment, we drop the attachment.

NOTE: if you are doing it with scenario 1 and don't have some spare capacity then I wouldn't recommend letting them go to brightmail/ipas, and virus scanning.

You can configure in the cli with policyconfig->filters or in the gui under mail policies - incoming content filters. After adding the filters in the guii, you need to goto incoming mail policies to enable it for the for the default policy.

Filter Name: Drop_Mass_Mailers

Conditions:
header-dictionary-match("MassMailers","X-IronPort-AV")

Actions:
drop()

Description:
Drop mass mailers from the system



Filter Name: Drop_Prohibited_Attachments

Conditions (All of the following must match):
attachment-filename ==
"(?i)\\.(com|exe)$"

Actions:
drop-attachments-by-name("(?i)\\.(com|exe)$", "Attachment not allowed")
strip-header("Subject")
insert-header("Subject", "[Content Warning - Attachments Removed] $Subject")

[Erich_ironport]

Idea #1.

As a defined in RFC 2821 & RFC 3463 could the IronPorts do something like this...

Use a SMTP status code of 5.7.1 (for refusal of restricted attachment types) Example:
DATA
I: 354 -> data -> S: 250
E: 571

This would require body content scanning during the SMTP conversation. Now you can tell me I'm insane. :shock:

But limit the body content scanning to only SBRS above 2 or so, (to compensate for some of the load of doing this during the conversation).

Combine this with a message filter or content filter rule to drop of all messages (the whole message not just the attachment) with restricted attachments types which would catch all messages below 2 and above our minimum allowed SBRS.

Idea #2:

Create a message filter or content filter rule to drop of all messages (the whole message not just the attachment) with restricted attachments types generate post conversational bounces only for senders with SBRS above 2 or so. The bounce message would explain which attachment types are restricted and that they need to contact the intended recipient for approved file transmission methods for restricted content.

Enhancement to above: Only generate bounces for senders from an authenticated source: SPF/Sender ID, Domain Key/DKIM, successful.

Idea #3:

Same as #2, but don't send a bounce or a message to anyone.

Erich

[tminchin_ironport]

our "solution" was to strip EXE's on the internal mail servers (Exchange bridgeheads) rather than the Ironport's. I suspect that would only work for a few styles of organisations though.

[tedski_ironport]

Thanks all for the great suggestions! Believe it or not, I think a sendmail + milter for A/V solution actually keeps the connection open with the sending MTA during the AV scan, allowing a 550 back to the sending MTA when a virus is found. For most viruses, the sending MTA is the SMTP engine of the mass mailer virus, so you avoid "garbage" bounces to the spoofed FROM addresses, but still can notify the 1 in 1 million senders of a infected Word doc that their email was rejected.

If only VOF sat in front of Content Filters we could do exactly what we want - only strip EXE's that made it past VOF.