filename rules questions/suggestions

[Bob Jones]

Hey all.  We're running the latest version of MailScanner and love the
results so far.  However, today a user had a problem that got my boss
and I looking more deeply at the filename blocking ruleset.  The problem
was that the user tried to send a doc named something.mld.doc and this
was rejected because of the .mld in the filename.

This got us to thinking about why this was dropped.  Since .mld is not a
defined bad extension, why block it.  The current ruleset is this:

deny    \.[a-z][a-z0-9]{2,3}\s*\.[a-z0-9]{3}$

This means to deny any attachment with a . followed by a character in
the a to z ranger followed by exactly 2 or 3 more characters in the a to
z or 0 to 9 range, then any number (including 0) of spaces, followed by
another . and exactly 3 characters in the range of a to z or 0 to 9
which must be the end of the filename.

What we got to thinking about was how could we make this only block the
"hidden" file extensions which are known to be bad, not all "hidden"
extensions.  We (mostly my boss who knows more about regular expressions
than I do) came up with 2 options that we would like to see somehow
added to MailScanner.

# Option 1

This option depends on the ability to define a variable in this ruleset
file.  The variable would look something like this:

BADEXT="(bat|exe|scr|vbs|shs|lnk|pif|dll|js|com)"

Essentially, it's just a string that contains any bad extension we are
interested in blocking.  It would be longer than above simply because
MailScanner blocks more, this is just a list for example.

If we had this ability, then we would change the filename ruleset so
that instead of:

deny    \.exe   (etc.)
deny    \.bat   (etc.)

on and on to one line:

deny    %BADEXT%        (etc.)

The above would be optional, we could leave it the same as it is now but
it would just be more work in keeping up with the bad extensions in 2
different places.

Now, the part it would really help is with the "hidden" extension area.
  We could put something like the following in place:

deny    \%BADEXT%\s*\.[^.]{3}$

There are a couple of changes here.  The first is replacing checking for
just any combo of letters in a hidden extension, we check specifically
for known bad ones.  Also, we replace just looking for numbers and
letters at the end of the file to checking for any character that's not
a . so that we catch potential workarounds for this check.

# Option 2

Now, this second option is if we can't or don't want to add the BADEXT
variable above.  This solution involves two things.  The first is
totally removing the extra deny for hidden strings and include it in the
  regular checks for bad extensions.  Here's an example:

deny    \.exe(\s*\.[^.]{3})?$

Now, what this does is check for the .exe at the end of the filename and
for an *optional* string consisting of any number of spaces, a . and
then any 3 characters that are not periods.  This way you would catch
attachments with names like virus.exe and virus.exe.twq or virus.exe.#3u

So, there could very easily be something that we're missing here in
either our logic or regular expression formatting, so feel free to
respond with any problems/suggestions.

Oh, one last thing.  From what we can tell the regular expression
checking isn't worried about case.  However, if this is true then why
does the CLSID check reg. expressions look like:

  deny    \{[a-hA-H0-9-]{25,}\}$

including the a-hA-H?

Thanks,
--
Bob Jones
OIIT
The Board of Regents, The University System of Georgia