1

We are trying to prevent the execution of certain system related executables by regular users on our network (mmc, cmd, ldp, etc.). I have suggested the use of software hashing rules but I am concerned that there might be unintended impacts from enforcing software restriction via GPO instead of changing permissions on the executables via the GPO.

What will change on the network when I switch from unrestricted to the use of software restrictions via GPO? We have a very small standalone network that doesn't see much traffic. Hashing rules should be effective, but I don't want to cause other problems by setting them up.

Shrout1
  • 363
  • 2
  • 7
  • 18

1 Answers1

1

Software restriction is a powerful tool, and also a fun topic:

First, to directly answer your question, there should be virtually no impact on the network itself. Software restriction is enforced entirely on the client side. The only network traffic appears when the client initially downloads the rules from the server. This is performed as part of the standard Group Policy refresh process, which would happen anyway, software restriction or not.

As for the effects on your users, it depends very much on how much testing you've done beforehand. If you spend one day collecting hashes from all the executables you can think of, throw them into a software restriction policy, and flip the switch - you're going to have a very bad day. There will always be things you don't think of: applications that copy executables into strange locations, applications that automatically apply updates (which will change your hashes), application executable that self-modify (usually as part of archaic licensing schemes, also changes the hash), etc. In a small network, the easiest way to go about rolling out software restrictions is to pick a guinea pig user (intern, etc.) and deploy the restrictions to them. You'll find 80% of your errors right off the bat.

Microsoft has a ton of literature on the topic as well. It's very dry, but a wealth of knowledge. Check out the topic on TechNet.

tfrederick74656
  • 1,452
  • 1
  • 13
  • 29
  • Thanks for answering! From the reading I've done, new versions break hashes but changing the location of the software should have no impact yes? I see a lot of system 32 duplicate applications in "winsxs" and want to be sure that a single hash will block both (provided they are the same version) – Shrout1 Oct 01 '14 at 20:37
  • No problem. You're correct about the location - the hash will be the same no matter where the file is located. I was more referring to a setup where you 'whitelist', as opposed to 'blacklist'. In that case, you have to ensure that you are aware of all the application executables, and sometimes applications store them in strange places (i.e. application 'X' has some component stored in the Windows directory that you're unaware of.) If you have the time, you might want to look at a whitelist setup - you only allow what you need to run instead of blocking what you don't want. – tfrederick74656 Oct 01 '14 at 22:31