Weird Content Filtering Issue

Wargot_ironport · ‎04-17-2008

I have had a weird issue come up with our content filtering today, and am wondering if anyone else has come accross it.

We have a number of Content Filters setup. One of these it looking for various media files including .wmv files (We have used a "Attachment-filename == "\\.wmv"" to look for them).

This works as required. However this morning out outbound Media File content filter trapped a message containing a wmv file going out that had been received by the user the night before.

this message last night was processed by the IronPort, the wmv was not hidden or re-named in any way. It was just not stopped by the content filter.

I have checked everything I can think of and I can see no reason why the message wasn't stopped. WMV's are being stopped OK as I type this.

Has anyone else come accross or noticed this.

This is on a C650 Appliance running 5.5.1

kluu_ironport · ‎04-18-2008

I may have to test this on my machine but it may be that the filename that got pass the filter was in uppercase maybe and that's how it sneaked through. Your filter looks for only lowercase filenames that end with ".wmv".

The only thing that is case-insensitive by default is the "mail-from" and "rcpt-to". Almost everything else (subject, message-body, other-headers, filenames) are case sensitive. To make these things case insensitive, you'll want to prepend your filter with this:

Attachment-filename == "(?i)\\.wmv"

or

Attachment-filename == "(?i)\\.(exe|bat|com|sh)"

(?i) --> means ignore the case on whatever follows this regex. You pretty much want to use this in most cases to be safe since match whether it's upper or lowercase. Performance-wise, it should be okay.

By the way, Ironport filters use Python regex.

Again, I'll have to test this on my side.

I have had a weird issue come up with our content filtering today, and am wondering if anyone else has come accross it.

We have a number of Content Filters setup.  One of these it looking for various media files including .wmv files (We have used a "Attachment-filename == "\\.wmv"" to look for them).

This works as required.  However this morning out outbound Media File content filter trapped a message containing a wmv file going out that had been received by the user the night before.

this message last night was processed by the IronPort, the wmv was not hidden or re-named in any way.  It was just not stopped by the content filter.

I have checked everything I can think of and I can see no reason why the message wasn't stopped.  WMV's are being stopped OK as I type this.

Has anyone else come accross or noticed this.

This is on a C650 Appliance running 5.5.1

Wargot_ironport · ‎04-18-2008

thanks for that, I didn't think about the case of the file extension.

However looking at the message header the extension was is lower case, it is funny aswell that the message was stopped going out again when the user tried to forward it to an external address.

It was trapped by a different appliance to the one that processed it originally.

Good point about the case though I will change the config of the filters to ignore the case, (I might combine them into an OR statement as well).

kluu_ironport · ‎04-18-2008

I forgot add the $ to the end of the statement.

I believe the system will do it automatically for you if select "ends with" in the pull-down menu when you're creating the filter.

Attachment-filename == "(?i)\\.wmv$"

or

Attachment-filename == "(?i)\\.(exe|bat|com|sh)$"

---------------

And on a side note, you can add this filter so that it will display the attachment filenames in the mail_logs

Add attachment file names to the logs

The IronPort does not log filenames by default. However, there is an easy way to enable this feature.

You can add either a message filter or a content filter that will add a header to the message. You could name the header something like X-Attachment and the value will be $filenames. Then on the System Administration > Log Subscription > Global Settings page, add the new header name to the Headers (Optional) section. This tells the IronPort to log the new header in the mail_logs.

You will see the following lines in the mail_logs:
for a message with no attachment -
Fri Nov 30 08:26:57 2007 Info: Message done DCID 72791 MID 110081 to RID [0] [('X-Attachment', 'None')]

for a message with an attachment -
Fri Nov 30 08:27:28 2007 Info: Message done DCID 72792 MID 110083 to RID [0] [('X-Attachment', 'test.doc')]

victor.blanco_ironport · ‎04-23-2008

sorry posted something by mistake, please ignore... :(