block exe-files?
Björn Hansson
This is probably a FAQ, but I can't find a good solution. I want to block .e=
xe,
.pif, .scr-files, ans so on - what in the BEST solution? I have played aroun=
d
with some regexps, but they doesn't catch that much.
I run postfix 2.0.7-20030319, if that matters. Can upgrade if something was
changed.
Any good suggestions?
Best regards,
Bj=F6rn
Magnus Bäck
Bj=F6rn Hansson <bhan...@netera.se> wrote:
> This is probably a FAQ, but I can't find a good solution. I want to
> block .exe, .pif, .scr-files, ans so on - what in the BEST solution? I
> have played around with some regexps, but they doesn't catch that
> much.
I use the regexps below as body_checks. They are not at all optimal, but
they work pretty good. Since you're running 2.0.7, you can put them in
mime_header_checks and avoid the (few) false positives that arise from
HTML constructions like
<a name=3D"foo" href=3D"bar">Download you cool .exe files here</a>
but such aren't too common.
/ (file)?name=3D(.*)\.exe$/ REJECT
/ (file)?name=3D(.*)\.exe / REJECT
/ (file)?name=3D"(.*)\.exe"/ REJECT
/ (file)?name=3D(.*)\.exe$/ REJECT
/ (file)?name=3D(.*)\.exe / REJECT
/ (file)?name=3D"(.*)\.exe"/ REJECT
--=20
Magnus B=E4ck
mag...@dsek.lth.se
Harry Hoffman
/name=3D\".*\.(vbs|exe|scr|pif)"$/ REJECT We do not accept these attachments
Cheers,
Harry
Quoting Magnus B=E4ck <mag...@dsek.lth.se>:
*> On Thu, May 22, 2003 at 09:59:05PM +0200,
*> Bj=F6rn Hansson <bhan...@netera.se> wrote:
*>=20
*> > This is probably a FAQ, but I can't find a good solution. I want to
*> > block .exe, .pif, .scr-files, ans so on - what in the BEST solution? I
*> > have played around with some regexps, but they doesn't catch that
*> > much.
*>=20
*> I use the regexps below as body_checks. They are not at all optimal, but
*> they work pretty good. Since you're running 2.0.7, you can put them in
*> mime_header_checks and avoid the (few) false positives that arise from
*> HTML constructions like
*>=20
*> <a name=3D"foo" href=3D"bar">Download you cool .exe files here</a>
*>=20
*> but such aren't too common.
*>=20
*> / (file)?name=3D(.*)\.exe$/ REJECT
*> / (file)?name=3D(.*)\.exe / REJECT
*> / (file)?name=3D"(.*)\.exe"/ REJECT
*> / (file)?name=3D(.*)\.exe$/ REJECT
*> / (file)?name=3D(.*)\.exe / REJECT
*> / (file)?name=3D"(.*)\.exe"/ REJECT
*>=20
*> --
*> Magnus B=E4ck
*> mag...@dsek.lth.se
*>=20
--=20
Harry Hoffman
ITSS Systems Team Leader
University of Auckland
hhof...@auckland.ac.nz
hhof...@ip-solutions.net
STANDARD DISCLAIMER:
**********************************************
*This universe shipped by weight, not volume.*
*Some expansion may have occured in shipping.*
*********************************************
-------------------------------------------------
This mail sent through IpSolutions: http://www.ip-solutions.net/
John Anthony Kazos Jr.
>How about:
>/name=\".*\.(vbs|exe|scr|pif)"$/ REJECT We do not accept these attachments
Wouldn't that fail if another attachment were listed after, or if there
were trailing whitespace after the file's name, or if it were not enclosed
in quotation marks?
Magnus Bäck
Harry Hoffman <hhof...@ip-solutions.net> wrote:
> How about:
> /name=3D\".*\.(vbs|exe|scr|pif)"$/ REJECT We do not accept these attach=
ments
Nope, won't be enough. The filename is not guaranteed to be surrounded
by quotation marks, and there might be whitespace at the end of the
line. Something like
/name=3D"?.*\.(vbs|exe|scr|pif)"? *$/ REJECT
should however work just fine with about the same risk of false
positives (which should be about zero if one's Postfix is new
enough for mime_header_checks).
--=20
Magnus B=E4ck
mag...@dsek.lth.se
Matt Thoene
Thursday, May 22, 2003, 12:59:05 PM, Bj=F6rn Hansson wrote:
> This is probably a FAQ, but I can't find a good solution. I want to blo=
ck .exe,
> .pif, .scr-files, ans so on - what in the BEST solution? I have played =
around
> with some regexps, but they doesn't catch that much.
> I run postfix 2.0.7-20030319, if that matters. Can upgrade if something=
was
> changed.
I use the following with great success. In main.cf:
mime_header_checks =3D pcre:/etc/postfix/mime_header_checks
And in mime_header_checks..
/^\s*Content-(Disposition|Type).*name\s*=3D\s*"?(.*\.(
ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
inf|ins|isp|js|jse|lnk|mde|mdt|mdw|msc|msi|msp|mst|nws|
ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))"?\s*$/x
REJECT Mailserver does not accept potentially executable viruses - Pleas=
e zip your file and resend.
Add/remove extensions at your discretion...
--=20
Matt=20
Greg A. Woods
> Subject: block exe-files?
>
> This is probably a FAQ, but I can't find a good solution. I want to blo=
ck .exe,
> .pif, .scr-files, ans so on - what in the BEST solution? I have played =
around
> with some regexps, but they doesn't catch that much.
The following Extended-REGEX, which I have compiled from several
sources, does catch most attachments which are apparently directly
executable on M$ systems:
^[ ]*Content-(Disposition|Type).*name[ ]*=3D[ ]*"?(.*\.(ade|adp|bas|ba=
t|chm|cmd|com|cpl|crt|dll|eml|exe|hlp|hta|inf|ins|isp|js|jse|lnk|mdb|mde|=
mdt|mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|s=
wf|url|vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))"?[ ]*$
I've only used it with "egrep" to scan through mailboxes....
--=20
Greg A. Woods
+1 416 218-0098; <g.a....@ieee.org>; <woods@roboha=
ck.ca>
Planix, Inc. <wo...@planix.com>; VE3TCP; Secrets of the Weird <woods@weir=
d.com>
*Hobbit*
actual *content* that's going to hurt you.
## exe "MZ" header, which varies a bit. base64 and uuencode versions
/^TV[nopqr]....[AB]..A.A....*AAAA...*AAAA/i REJECT
/^M35[GHIJK].`..`..*````/i REJECT
If you start with a policy that you don't accept EXECUTABLES, then
don't accept EXECUTABLES, period, regardless of what some idiot
trying to attack you calls it this week. Make the regex broad enough
to handle potential exe-header variants, as well. We will probably
need to deal with newer exe formats as time goes on, too, and the
regexes covering those should be broad. The above were derived from
base64-ing everything in a standard winbloze distribution and some
other stuff thrown in, and finding all the common parts. When people
start writing their own loaders and mangling exe headers, the
expressions will have to become more broad.
Not that you shouldn't also deal with names, of course, esp. things like
.scr and .pif and .bat and stuff that may not necessarily have an exe
header, but y'know, it seems like the vast majority of worms come with
some name or other and *still* contain an executable regardless.
_H*
Harry Hoffman
That's probably the most comprehensive listing I've ever seen. How well do=
es
it work?
--Harry
Quoting "Greg A. Woods" <wo...@weird.com>:
*> [ On Thursday, May 22, 2003 at 21:59:05 (+0200), Bj=F6rn Hansson wrote: ]
*> > Subject: block exe-files?
*> >
*> > This is probably a FAQ, but I can't find a good solution. I want to blo=
ck
*> .exe,
*> > .pif, .scr-files, ans so on - what in the BEST solution? I have played
*> around
*> > with some regexps, but they doesn't catch that much.
*>=20
*> The following Extended-REGEX, which I have compiled from several
*> sources, does catch most attachments which are apparently directly
*> executable on M$ systems:
*>=20
*> ^[ =09]*Content-(Disposition|Type).*name[ =09]*=3D[
*>=20
]*"?(.*\.(ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|eml|exe|hlp|hta|inf|ins|is=
p|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr=
|sct|shb|shs|shm|swf|url|vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))"?[
*> =09]*$
*>=20
*> I've only used it with "egrep" to scan through mailboxes....
*>=20
*> --
*> =09=09=09=09=09=09=09=09Greg A. Woods
*>=20
*> +1 416 218-0098; <g.a....@ieee.org>; =20
*> <wo...@robohack.ca>
*> Planix, Inc. <wo...@planix.com>; VE3TCP; Secrets of the Weird
*> <wo...@weird.com>
Jay Maynard
> Unless you keep up with the format-of-the-week and the window of
> opportunity therein, you're wasting your time. (You might even be wasting
> it anyway.) The final answer is users becoming intelligent. The day we see
> corporations firing employees who infect office systems, or ISPs who
> suspend service to subscribers whose computers start spamming viral emails
> out, is the day we see people wising up.
Bloody optimist. What color is the sky on your planet?
This is about as likely as seeing Al Sharpton tell a bunch of homeless
people sleeping under a bridge, "Get a job, you lazy bums!"
Wietse Venema
It's unkind to blame individual users for faults in their software
that they don't have control over anyway. The "solution" requires
a more structural approach.
Imagine the following dialog:
Q: When will you guys stop producing such crappy software?
A: Very soon after you guys stop buying our crappy software.
Wietse
Graham Hillstomer
dangerous not the file type but if want to
go that route here is a list of executable
types to block.
.386
.acm
.ade
.adp
.app
.asp
.awx
.ax
.bas
.bat
.bin
.cdf
.chm
.class
.cmd
.cnv
.com
.cpl
.crt
.csh
.dll
.dlo
.doc
.dot
.drv
.exe
.flt
.fot
.hlp
.hta
.ini
.inf
.ins
.isp
.js
.jse
.lnk
.mdb
.mde
.mod
.msc
.msi
.msp
.mst
.nws
.obj
.ocx
.olb
.osd
.ovl
.pcd
.pdr
.pgm
.pif
.pkg
.pot
.ppt
.pps
.prg
.reg
.rpl
.rtf
.scr
.script
.sct
.sh
.sha
.shtml
.shs
.swf
.sys
.tlb
.tsp
.ttf
.vb
.vlm
.vxd
.vxo
.wiz
.wll
.wwk
.pdr
.url
.vb
.vbe
.vbs
.wsc
.wsf
.wsh
.xla
.xlb
.xlc
.xld
.xlk
.xll
.xlm
.xls
.xlt
.xlv
.xlw
.xnk"
Graham
--=20
---
Graham Hillstomer II
Senior System Admin *BSD, HP-UX, Solaris
Quality of Service Response Team=20
Antivirus Solution Manager / SPAM Control Team Assistant
ghill...@postmaster.co.uk
John Anthony Kazos Jr.
I see a succeeding dialog with that questioning user.
Q: When will you guys stop buying their crappy software?
A: When your good software stops interfacing with their crappy software.
I see one way the true field of computer science is going to clean its own
house, and the only way it'll work is that we remain outside commercial
influence; no company trying to keep its customers (for money or otherwise)
could do this, which is why the good ones don't and the bad ones stick around.
Make software, and make it refuse to work around bugs. (Fine and good to
work around things which simply are different, but *not* fine or good to
work around things which are specified to be elsewise than they are, and
simply haven't been fixed.) At this point, a great number (if not the vast
majority) of people will refuse to use your software because it "doesn't work".
Now, make your software better. Then make it better still. Keep up the
software development cycle, no matter how few users you have, and no matter
how few systems your software works on. Make your software so good it even
rivals the other "broken" solutions (if you are making a competitive
product) or else is so useful and wonderful that it's frustrating to do
without (if you are making something that fills a new or uncommon need). No
matter how much people beg for you to make it work on their system, don't
do it if it would mean compromise.
There's only several paths it could take from here. You could "sell out"
and add the bugfixes, in which case you could've saved yourself the
headaches and done that in the first place. You could keep this up forever
and ever, and nobody will ever use your software. Or...people will actually
start to think about how all these people are making this great software
and enjoying it, maybe hear about people who use it (on non-broken
systems), and actually start to understand why they need to take control of
their own machines. And at that point, the bugs get fixed.
And for everything that's not a bug, but just personal choice, there's
autoconf. :-)
John Anthony Kazos Jr.
>[ On Friday, May 23, 2003 at 22:38:34 (+1200), Harry Hoffman wrote: ]
> > Subject: Re: block exe-files?
> >
> > Wow,
> > That's probably the most comprehensive listing I've ever seen. How
> > it work?
>
>I stopped working with M$ products sometime in about 1987 or so and I've
>no idea how complete that list of extensions is for more modern M$
>systems. I've collected it from from various sources who know more
>about such things than I do. If I wanted it to err on the side of
>safety then I'd probably want to reject any filename with any two or
>three-letter extension.
Or you could whitelist it instead of blacklist it, and say accept only
.zip, .tar, .gz, .bz2, .Z, .sit, et cetera, and add some if anybody
complains and it's not a problematic format.
Graham Hillstomer
That translates to allowing ZIP files that
contain virus into your Email environment
and exposing yourself. A good virus scanner
at the gateway would resolve this.
As an example take ANY network spreading
virus and zip it and email to a end user. He
can simply open the ZIP and run the virus
and have it spread over your network.=20
Sure it **may** stop some viruses at the
gateway that are spreading using common file
extensions but overall it is a flawed
approach to virus protection.=20
Also this flawed approach has no way to
determine what is good and what is bad and
kills the good with the bad.=20
Much better to use a strong virus scanner to
let the good in and keep the bad out!
Graham
>> > Wow,
>> > That's probably the most comprehensive listing I've ever seen. How=
=20
>> well does
>> > it work?
>>
>>I stopped working with M$ products sometime in about 1987 or so and I'v=
e
>>no idea how complete that list of extensions is for more modern M$
>>systems. I've collected it from from various sources who know more
>>about such things than I do. If I wanted it to err on the side of
>>safety then I'd probably want to reject any filename with any two or
>>three-letter extension.
>
>Or you could whitelist it instead of blacklist it, and say accept only=20
>.zip, .tar, .gz, .bz2, .Z, .sit, et cetera, and add some if anybody=20
>complains and it's not a problematic format.
>
>
--=20
Greg A. Woods
> Subject: Re: block exe-files?
>
> Whitelisting does not work to stop viruses.
> That translates to allowing ZIP files that
> contain virus into your Email environment
> and exposing yourself. A good virus scanner
> at the gateway would resolve this.
Now that I think about it I would suggest that whitelisting will
actually work better than just a plain virus scanner, given the human
factors involved, provided of course that any vulnerable platforms in
use are used only by educated users who take great care with all files
the retrieve or receive, regardless of how they get them.
> Much better to use a strong virus scanner to
> let the good in and keep the bad out!
The problem is that there is no such thing as a strong virus scanner
that's also a perfect first-time virus scanner -- it's a logical
impossibility.
All executable content of any and every kind must be banned in order to
prevent initial outbreaks of new undetectable threats.
--
Greg A. Woods
+1 416 218-0098; <g.a....@ieee.org>; <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com>; VE3TCP; Secrets of the Weird <wo...@weird.com>
Linc Madison
<wo...@weird.com> wrote:
> > Much better to use a strong virus scanner to let the good in and
> > keep the bad out!
>
> The problem is that there is no such thing as a strong virus scanner
> that's also a perfect first-time virus scanner -- it's a logical
> impossibility.
>
> All executable content of any and every kind must be banned in order
> to prevent initial outbreaks of new undetectable threats.
In particular, as long as you have idiot e-mail client programs that
allow things like auto-executing a script in an e-mail when the user
merely previews the message, you have to block executables.
The most important thing, though, is that it's not an either-or case.
You should block all executables AND have a virus scanner that can look
into the ZIP files and other compressed archive formats for infected
files.
Stephen Satchell
>As an example take ANY network spreading
>virus and zip it and email to a end user. He
>can simply open the ZIP and run the virus
>and have it spread over your network.
The key here is that the *user* has to extract the file and run it -- there
is (currently) no way for Outlook or other MUAs to be tricked into doing
that automatically. It's the automatic running of virus code that is a
major problem. You can teach users not to run/execute nasty code. It
takes some work to teach Outlook the same thing, so it's simpler to block
incoming mail with viral MIME blocks that would be automatically executed.
>Sure it **may** stop some viruses at the
>gateway that are spreading using common file
>extensions but overall it is a flawed
>approach to virus protection.
It prevents virus software from using the "features" of certain MUAs from
being the vector.
>Also this flawed approach has no way to
>determine what is good and what is bad and
>kills the good with the bad.
Tough. If someone wants to send me a Microsoft Word or, worse, a
PowerPoint file, let him zip it up and send it to me. I'll look at it if I
want to, after my anti-virus software has cast its eye over it, but there
is no way that my MUA is going to open a zip file for me without my
command. Even if the damn program unzips the file, it still give the virus
checker (which checks all files being created) a chance to catch and
quarantine the bugger before the MUA does something worse.
>Much better to use a strong virus scanner to
>let the good in and keep the bad out!
That is precisely what I'm doing, except the virus scanner is on the
end-user's system rather than the mail gateway (which has enough to do,
thank you) so that viruses are caught whether they are e-mail, ftp, or even
on a CD or (shudder) floppy disk.
Besides, if you are going to send me, or my users, files in proprietary
format, I'm not sure my definition of "good" and "bad" agrees with
yours. I have blacklisted sending addresses that present .doc files with
macros -- ANY macros. I have had to bow out of a consulting group because
they insist on sending work notices using .doc, and those files were
infected with some nasty ones. I would much rather see a .pdf, which (up
until Acrobat 5) could not carry a virus. Or, bluntly, plain text.
--
Q: What is the fibula?
A: A small lie.
-- Detroit MI, UMich SAT tests, 2000
Graham Hillstomer
id.net> wrote:
>At 08:34 PM 5/23/03 +0100, Graham Hillstomer wrote:
>>As an example take ANY network spreading
>>virus and zip it and email to a end user. He
>>can simply open the ZIP and run the virus
>>and have it spread over your network.
>
ere=20
>is (currently) no way for Outlook or other MUAs to be tricked into doing=
=20
>that automatically. It's the automatic running of virus code that is a=20
>major problem. You can teach users not to run/execute nasty code. It=20
>takes some work to teach Outlook the same thing, so it's simpler to bloc=
k=20
>incoming mail with viral MIME blocks that would be automatically execute=
d.
Depending on a last line of defense is=20
risky. Most malware spreads from the end
user. Viruses like Klez, Yaha, and other turn
off the real-time virus protection by killing
the process so the end user is the last
resort for protection and not reliable.
Virus scanning at the MTA prevents the end
user 100% dependency for email virus
scanning.
I mean depending on your environment you
could whitelist senders and acceptable file
types and then virus scan those file types.
Graham
>>Sure it **may** stop some viruses at the
>>gateway that are spreading using common file
>>extensions but overall it is a flawed
>>approach to virus protection.
>
>It prevents virus software from using the "features" of certain MUAs fro=
m=20
>being the vector.
>
>>Also this flawed approach has no way to
>>determine what is good and what is bad and
>>kills the good with the bad.
>
>Tough. If someone wants to send me a Microsoft Word or, worse, a=20
>PowerPoint file, let him zip it up and send it to me. I'll look at it i=
f I=20
>want to, after my anti-virus software has cast its eye over it, but ther=
e=20
>is no way that my MUA is going to open a zip file for me without my=20
>command. Even if the damn program unzips the file, it still give the vi=
rus=20
>checker (which checks all files being created) a chance to catch and=20
>quarantine the bugger before the MUA does something worse.
>
>>Much better to use a strong virus scanner to
>>let the good in and keep the bad out!
>
>That is precisely what I'm doing, except the virus scanner is on the=20
>end-user's system rather than the mail gateway (which has enough to do,=20
>thank you) so that viruses are caught whether they are e-mail, ftp, or e=
ven=20
>on a CD or (shudder) floppy disk.
>
>Besides, if you are going to send me, or my users, files in proprietary=20
>format, I'm not sure my definition of "good" and "bad" agrees with=20
>yours. I have blacklisted sending addresses that present .doc files wit=
h=20
>macros -- ANY macros. I have had to bow out of a consulting group becau=
se=20
>they insist on sending work notices using .doc, and those files were=20
>infected with some nasty ones. I would much rather see a .pdf, which (u=
p=20
>until Acrobat 5) could not carry a virus. Or, bluntly, plain text.
>
>
>--=20
>Q: What is the fibula?
>A: A small lie.
> -- Detroit MI, UMich SAT tests, 2000
>
>
--=20