Disable Exe and Other File Types from being run/viewed

Archived from groups: microsoft.public.win2000.security (More info?)

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?
8 answers Last reply
More about disable file types viewed
  1. Archived from groups: microsoft.public.win2000.security (More info?)

    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.

    --
    Herb Martin


    "Arkane" <Arkane@discussions.microsoft.com> wrote in message
    news:D94B7FDA-7364-4D10-B06B-691378EAF7CE@microsoft.com...
    > 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?
  2. Archived from groups: microsoft.public.win2000.security (More info?)

    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


    "Arkane" <Arkane@discussions.microsoft.com> wrote in message
    news:D94B7FDA-7364-4D10-B06B-691378EAF7CE@microsoft.com...
    > 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?
  3. Archived from groups: microsoft.public.win2000.security (More info?)

    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.

    "Steven L Umbach" wrote:

    > 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
    >
    >
    > "Arkane" <Arkane@discussions.microsoft.com> wrote in message
    > news:D94B7FDA-7364-4D10-B06B-691378EAF7CE@microsoft.com...
    > > 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?
    >
    >
    >
  4. Archived from groups: microsoft.public.win2000.security (More info?)

    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).

    "Steven L Umbach" wrote:

    > 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
    >
    >
    > "Arkane" <Arkane@discussions.microsoft.com> wrote in message
    > news:D94B7FDA-7364-4D10-B06B-691378EAF7CE@microsoft.com...
    > > 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?
    >
    >
    >
  5. Archived from groups: microsoft.public.win2000.security (More info?)

    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.
  6. Archived from groups: microsoft.public.win2000.security (More info?)

    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).

    "EN" wrote:

    > 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.
    >
    >
    >
    >
  7. Archived from groups: microsoft.public.win2000.security (More info?)

    --
    Herb Martin


    "Arkane" <Arkane@discussions.microsoft.com> wrote in message
    news:3785CF93-E90F-4BE4-BE77-4EFB878E8E23@microsoft.com...
    > 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.
  8. Archived from groups: microsoft.public.win2000.security (More info?)

    Sure, email me at
    trusted@mail.com
    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.


    "Arkane" <Arkane@discussions.microsoft.com> wrote in message
    news:3785CF93-E90F-4BE4-BE77-4EFB878E8E23@microsoft.com...
    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).

    "EN" wrote:

    > 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.
    >
    >
    >
    >
Ask a new question

Read More

Security Windows