Disable Exe and Other File Types from being run/viewed

[Guest]

Here's the scenario we have :
We have several hundred W2K SP4 PCs, several hundred WXP Pro SP1a PCs.
Our network is NT4 but we will migrate to AD in-time.

I know that with AD Software Policies we can stop users from running
applications using policies - however while we currently don't have this
capability, does anyone have a good equivalent?

The "Don't Run Windows Programs" POLEDIT policy is not feasible as we'd have
to list vast arrays of files as it does not accept masks.

Using "Only allow following Windows Programs" is equally bad as the range of
applications we use really is vast, to track down all of their component .exe
files and other components (that must be able to be run) would be a massive
task.

This restriction, however applied - must work for Network and Removable
Drives - now if there's a setting I can put on Removable Drives (Like No Exec
on Linux filesystems), then I'd happily do that via a security policy.

I'm at my wits end with this one as we use a 'sweeper' which erases these
files from our servers, yet the users can still plug in their USB memory
sticks and run .exe files or whatever that may be on them. I work at a school
so security is something that's better off prevented first (stop them doing
something at the start), rather than run around and try and catch it later.

Any thoughts?

 

[Herb Martin]

You could approach it with a script that only allows
"Execute" on approved files.

If the list for this is long (or the opposite list is not
a better choice) then you will just have to use a LONG
batch file or any other method since they are all going
to be generally similar.

For instance, one command can fix all of the exe's in
the Program Files directory (by going down through
the subdirectories) but a separate command will then
have to be run for any exceptions in that directory tree.

Cacls.exe or Xcacls.exe are the obvious tooks, but
for truly sophisticated settings you might look at
SetAcl.exe free from SourceForge.net.

But note, just because SetAcl offers more flexibility
doesn't mean that it essentially changes the problem.

One advantage however is being able to set the defaults
for new files differently from the parent or from the
default for new subdirectories (containers.)

Many people think the above are just "one setting" but
they are technically distinct even though the built in
tools don't usually show those distinctions.

 

[Steven L Umbach]

From your options your best bet is probably to populate the "only allowed"
applications list. Programs such as filemon from SysInternals can help you
track down which executables are used for an application. If you don't want
them to have access to USB drives, consider disabling USB in the cmos for
the computer and password protecting the cmose settings which is not
foolproof but could be a major barrier to access the computers cmos. Also
keep in mind that Windows 2000 computers can not use Software Restriction
Policies. --- Steve

 

[Guest]

Thank you both for your responses here.
Lots of good ideas and practical advice, unfortunately the key issue is not
blocking .exe/etc... files from the local hard disk (as these are under our
control and everyone has READ access anyway), it would serve no purpose for
us to restrict the local hard disk anymore than it already is (no-one has any
kind of access except READ and only Domain Admins have FULL). I've thought of
writing aforementioned scripts to lock down those .exe files but as everyone
needs to be able to run them - it would be pointless to do so. Our users
cannot access explorer to navigate to any hard disks anyway as that's
restricted via policy, it's also a hidden drive letter and is also restricted
so they can't navigate to it even if they were really smart - the command
prompt and friends are also disabled. (However command-script processing is
not - so we can still use the login script - although if I were to use KiX,
would I still need this setting to be enabled?).

The problem lies entirely with USB drives/etc... we can't prevent their use
as it's a requirement for them.

If anyone else has any other good ideas or solutions I'd be more than happy
to listen/read. However, based on some research and poking around I may have
found a somewhat unsual solution (assuming my testing works).

You change the .exe (and whatever other filetype) file association to point
to a 'stub' program, a batch file or whatever, then you simply ask the batch
file to parse what it was given in terms of EXE file to run, if that file
lives on the C drive or a specific network drive, then we can simply run the
program - if it doesn't live there (as in must be a USB stick or somewhere
else, like a disk), then we just exit - no errors, no messages, just a clean
exit. (At least for now).

Failing that (if it doesn't work and I'm not sure why it wouldn't), then my
only other alternative is to populate the 'Users can only run following apps'
list... which is good for us as we can lock the students right down but the
staff and admins (us) will still have full control of what we can/can't run.

I have NO idea if my 'file-association' thing would work, we can push out
registry settings as admins or anything else as admins if needed - it's just
a case of how much hassle it all is...

I will test this tomorrow and will let you know if interested.

 

[Guest]

Something just to note - the USB drives/sticks are all FAT32 filesystems, so
xACL modification would fail on them, even if my script was able to detect
when they were plugged in.

One of these 'viruses' that intercepts all .exe execution and such would be
good for this - if only they weren't destructive and were configurable...
like a low-level I/O driver of sorts... am sure other people have had similar
problems.

Hopefully the file-association idea will work and will also allow us to deal
with a few other nuisance filetypes - as the users can't "run" files unless
they double-click - we have no media players or anything so they can't open
the files directly... which as far as I'm concerned, kills many problems with
a single solution... the trick will be making the batch file/parser-thing
intelligent enough to provide configuration and basic access control (so
admins/staff can run whatever w/o interruption).

 

[EN]

I work at a high school and this is something of a big problem for us.
We've found a product that works pretty well. Sure there are always
ways around them, but it does work 99% of the time.
It's called Fortres and you can check it out at
http://www.fortres.com
It's pretty inexpensive for a site license and you can deploy it
remotely.

Also, I think someone already mentioned it but even if you do
populate the do not run list, those exes can still be run, I think
the explanation on the GPO policy even tells you this.

 

[Guest]

I'm on the site now - our only problem in regards to desktop security is
these blasted .exe/.com/.bat filetypes etc... the typical 'chicken and egg'
problem where you have to give your users access to their home-drives to be
able to do their work, yet that same access permits them to run exes that
they find or can grab from places.

This 'fortres' system sounds like a client-app, so that it would need to be
used carefully alongside AD 2003, an option my management would not go for.
Ideally some kind of small 'agent' that intercepts I/O calls on a single PC
yet uses a network config file would work wonders, I'm a programmer but I'm
not THAT good.

I've maybe found a way to block out exe files - the initial testing looks
good, by modifying the file-type associations for a PC and then writing a
'pass-thru' app that lives on each PC, it can determine (due to hardcoded
rules) whether the app can be run or not. This will stop those exe files and
such, legit users it just 'passes thru' and lets them run it. It,
unfortunately cannot stop .com/.exe files from inside DOS, that's beyond it's
scope, but our users can't access DOS anyway.

EN : I'd be interested in talking directly (via E-Mail if you'd like) or to
anyone on these boards who manages an educational (UK secondary school or US
high-school or equivalents (where students are between Age 13 - Age 17
approx)) IT network to discuss your desktop security that you've implemented,
so perhaps we could pool resources and such. If interested, reply to this
post with a public E-Mail address (so we can obtain private ones later -
while also protecting against unsolicited mail).

 

[Herb Martin]

--
Herb Martin

I'm on the site now - our only problem in regards to desktop security is
these blasted .exe/.com/.bat filetypes etc... the typical 'chicken and egg'
problem where you have to give your users access to their home-drives to be
able to do their work, yet that same access permits them to run exes that
they find or can grab from places.

Arrange the permissions to disallow EXE.

You will have to mark the share a "change" so
they cannot "fix" those permissions on the files,
and this will prevent them from setting any specific
permissions on their own, but many people don't
need this feature anyway.

And if the Home is not on a share, you will have
to move it there. Although many users would never
figure out that they could just change the permissions,
it isn't really secure unless you actually block that
change (at the share) for files they own.

 

[EN]

Sure, email me at
(e-mail address removed)
then we'll take it from there.

Also, have you looked into the other sections of group policy, namely the
Computer Policy--->WIndows Setting--->Security Settings----> File System.
Although it's tedious, you can put what kind of access files have.



I'm on the site now - our only problem in regards to desktop security is
these blasted .exe/.com/.bat filetypes etc... the typical 'chicken and egg'
problem where you have to give your users access to their home-drives to be
able to do their work, yet that same access permits them to run exes that
they find or can grab from places.

This 'fortres' system sounds like a client-app, so that it would need to be
used carefully alongside AD 2003, an option my management would not go for.
Ideally some kind of small 'agent' that intercepts I/O calls on a single PC
yet uses a network config file would work wonders, I'm a programmer but I'm
not THAT good.

I've maybe found a way to block out exe files - the initial testing looks
good, by modifying the file-type associations for a PC and then writing a
'pass-thru' app that lives on each PC, it can determine (due to hardcoded
rules) whether the app can be run or not. This will stop those exe files and
such, legit users it just 'passes thru' and lets them run it. It,
unfortunately cannot stop .com/.exe files from inside DOS, that's beyond
it's
scope, but our users can't access DOS anyway.

EN : I'd be interested in talking directly (via E-Mail if you'd like) or to
anyone on these boards who manages an educational (UK secondary school or US
high-school or equivalents (where students are between Age 13 - Age 17
approx)) IT network to discuss your desktop security that you've
implemented,
so perhaps we could pool resources and such. If interested, reply to this
post with a public E-Mail address (so we can obtain private ones later -
while also protecting against unsolicited mail).