One of the big problems with the employee-as-empowered-computer-user philosophy that exists in corporate America...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
today is that users have way too many opportunities to muck up their machines. What help desk hasn't been flooded with calls from users who just couldn't resist adjusting some Control Panel switch or poking around in the registry? What network hasn't suffered because users downloaded some new game or tool from the Internet that turned out to be a Trojan horse? Where haven't virus and worms run amok because of code accompanying e-mail or embedded in Web pages?
There are also ways ordinary users can find out information they really don't need to know. Users can browse the application and system logs, view system services configuration, enumerate users and groups and determine network configuration. So who cares if users know these things? On Windows XP, mere users cannot change most critical settings, but anyone who can log on to a computer can find out all its intimate details and, armed with this inside knowledge, craft a malicious attack.
Let's suppose that known privilege escalation vulnerability exists in the xyz service. Knowing that this service is running on this computer allows a user to take advantage of this bug, potentially take over the computer and then move on to attack other systems in the network.
There are all kinds of potential attacks and acts of stupidity that are supported by the ability to go where nobody should have ever gone before. Windows XP Group Policy gives the savvy admin the ability to hide and prevent access to many, many Windows tools. But what about programs that you haven't approved? Windows XP Software Restriction Policies (also coming with .NET Server) can provide one solution. Best of all, every Windows XP system is already running it. Of course that policy says, 'everything is allowed' but it's a policy you can change.Laying down the rules
There are two Software Restriction Policy security levels: disallowed and unrestricted. Unrestricted is the default policy for Windows XP. Software runs on the XP system according to the built-in privileges you assign in combination with the configured file and registry permissions. This means that Bob, an administrator, can do anything while Sally, who is a user, is restricted. She cannot install drivers, configure the display, add users and do many things that Bob can do. But she can still get herself and her company in trouble.
To restrict Sally and Bob, your job is to decide if you want to write additional rules that remove the ability to run software, or if you want to change the mode to 'disallowed' and then write additional rules that allow specific software to run. But beware: Selecting the 'disallowed' mode, can damage a computer's ability to function. Using this mode requires careful use of additional rules to ensure that the computer can still do useful work. Even worse, it's possible to prevent the entire system from running.
Here's how it works. Open the group policy editor by selecting Run, then typing gpedit.msc. Open the Computer Configuration/Windows Settings/Security Settings/Software Restriction Policies. Opening Security Levels exposes the two policies, either of which can be set to default. For now, we'll leave the policy set to 'Unrestricted'.
Right clicking on the 'Additional Rules' container will allow you to select the type of rule you want to create. Each rule can also be set to 'unrestricted' or 'disallowed'. In our 'unrestricted' policy mode, you'll probably write rules which are designated 'disallowed'. Four rule types exist:
- Hash rules restrict software by comparing the hash (a fingerprint that uniquely identifies a file no matter its location) of the requested file to one present in a rule. If the has rule is set to disallowed, then the program will not run.
- Path rules restrict software depending on the path. If you 'disallow' files in the 'C:Hacker Tools' folder, then you've prevented a user from running them. However, if the tool can be found elsewhere, it will run.
- Internet zone rules apply to the Internet zone an application is downloaded from, but only if a windows installer package is used.
- Certificate rules control the execution of programs based on the availability of an appropriate certificate.
A good first trial rule is to select a path rule and configure the game of solitaire to be restricted. From within the 'path' rule dialog, browse to C:winntsystem32sol.exe (or wherever the system files are located on your machine). Then set the security level to 'disallowed' and click OK. This is a group policy, so take a minute to run 'gpupdate' from the command line. Next, attempt to run the solitaire program. You will get a popup which warns that the program can't run due to a software restriction policy.Getting it right
As sure as my belief that the sun will come up tomorrow, is my belief that a large number of you are going to jump right in and change the Software Restriction Policy to 'disallowed', then be astounded when you break your systems. So be forewarned: XP documentation takes great pains to indicate the folly of just selecting this policy and expecting to escape unharmed. Taking this step without some study and testing can be confusing, upsetting and downright career-unsettling. To avoid disaster, you need to have a healthy respect for the word, 'disallowed'. Without a firm understanding of the way these policies work, and knowledge of what files need to be tagged as 'unrestricted,' you're in for a pretty rough ride.
Then there are a few lesser issues to worry about. For example, if you have conflicting rules such as one that says files in a path are disallowed, and a hash rule which indicates they can; which rule wins? Is there any way to restrict some users and not others? Where do you get those certificates for certificate rules? Can you use a Software Restriction Policy to fight the spread of viruses and worms?
Whether there is a place for Software Restriction Policies on your network will depend on your understanding each of the rule types, your ability to figure out how to use them and how well you define and determine esoteric management rules and the right combination of rules and policy.About the author:
Roberta Bragg MCSE, CISSP, MCT, MCP is a well-known Windows security consultant, columnist and speaker. Her publishing credits include ISA Training Guide, MCSE Windows 2000 Network Security Design and Windows 2000 Security.