Presentation on theme: "Application Support This is an excerpt from a section of the course that explains a new area of group policies called “Software Restricion Policies”"— Presentation transcript:
Application Support This is an excerpt from a section of the course that explains a new area of group policies called “Software Restricion Policies”
Software Restriction Policies n Basically it’s a list of programs that can and can’t run n You pick which ones run and which don’t n But there are thousands of EXEs etc on your system, so you wouldn’t enjoy having to name every single EXE file that your system knows… n … Disabling every EXE would keep your system from booting!
How You Control SW Policies n A program is either “disallowed” (you can’t run it) or “unrestricted” (you can run it, assuming that there’s nothing else stopping you) n One rule (“Security Levels”) specifies the default value for all programs – disallowed or unrestricted n Another rule (“Enforcement”) excludes administrators from SW restriction policies n Typically you set the default to “unrestricted” and then restrict particular programs
How To Restrict Programs n Four kinds of rules: – Certificates: refer to a code-signing cert to allow (or, I suppose, disallow) an app – Hash: GPEDIT actually computes a “fingerprint” that identifies a particular program and then uses it to allow or disallow an app – Internet Zone: lets you control running apps directly from an URL – File and Directory Path: allow/disallow everything in a directory and its subdirectories, or a particular file or wildcard pattern n Examples coming!
Getting Started n First, create a software policy and start from an all-open, “safe” point of view, then lock it down n Open gpedit.msc, look in Computer Configuration/Windows Settings/Security/Software Restriction Policies
Initial SW Policy – No Objects
Create A Basic Policy n Right-click SW Restrictions Policy, “create new policy” n Now a policy exists, but it basically does not stop anyone from doing anything that they couldn’t do before n First question: disallow all apps by default, or allow all apps by default? In the Security Levels folder; allowed by default
Folders Created in SW Policy
Now let’s disallow Solitaire n Again, there are four ways to identify an app – its Authenticode cert, its hash, its URL or its filename/location n Let’s disallow Solitaire; rt-click Additional Rules folder and choose “New Path Rule…” n Fill in path %windir%\system32\sol.exe n Choose “disallowed” rather than “allowed”
Defining a Path
Now turn the screws I mean, let’s apply the rule n gpupdate /force typically isn’t enough n Restrictions seem to need a logoff/logon n Then try to start Solitaire n If it doesn’t work, then reboot; you’ll see
But the users aren’t dumb… n So they copy sol.exe to another directory, run it, and they’re back to Solitaire n So let’s try for a better approach – zap sol.exe itself; create a new “Hash” rule n Point to sol.exe and the system will compute a “fingerprint” that will identify sol.exe no matter where it is n Result: Solitaire is dead
A Hash Rule
We hope that looked useful… We cover that and a WHOLE lot more in the Powerpoint. If you’re interested, visit to purchase the entire 279-slide book. Thanks for downloading and examining our sample!