Hardening Windows XP with Software Restriction Policies

• Author
• Recent Posts

Kyle Beckman

Kyle Beckman works as a systems administrator in Atlanta, GA supporting Office 365 in higher education. He has 17+ years of systems administration experience.

Latest posts by Kyle Beckman (see all)

• Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
• Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
• Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016

In my previous article, I discussed strategies for protecting a Windows XP system from network and malware threats, but those protections can only go so far. Definition/Pattern-based malware detection engines are having a harder and harder time dealing with threats. The people writing this code continue to improve their malware to evade the rules in definitions released by all of the major antivirus vendors.

Preventing unauthorized applications from running through application whitelisting/blacklisting is a tool that should be in your arsenal to protect your XP systems. And, if you’re going to have offline/disconnected XP systems, you’ll need a way to protect those systems from malicious software that could come in through removable media since they won’t have access to antimalware updates.

If you can avoid giving admin rights to users on your remaining XP systems, you should. Whether your XP users have admin privileges or not, Software Restriction Policies (SRP) can prevent unauthorized executables from running. SRP can be accessed in Group Policy (or the standalone editor) in Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies.

Personally, I like to use a standalone GPO for SRP so I can separate SRP from other policies that apply to systems in an OU. Start with a GPO that isn’t linked to an OU. SRP has the ability to completely lock down a computer if you’re not careful. Keeping the policy unlinked keeps it from accidentally applying to systems before you’re done creating and testing the policy.

To create a new set of policies, right-click Software Restriction Policies and choose New Software Restriction Policies.

New Software Restriction Policies

In the Additional Rules area, right-click under the pre-created rules and choose New Path Rule.

New Path Rule

Enter %WINDIR% for the Path and change the Security Level to Unrestricted. Click OK. You can also use C:\Windows here, but using %WINDIR% ensures that SRP uses the local system’s information for locating the Windows folder in the event someone decided to do something wacky.

Security Level  Unrestricted

Repeat the process, adding %PROGRAMFILES% and the paths to any custom apps you may have that reside outside of those two folders. When you’re done, it should look something like this:

%PROGRAMFILES%

Next, you’ll want to go back up to the top Software Restriction Policies section to review the file types that are restricted by SRP. The default list of file types may contain some file types that will cause problems for your end users. The biggest is .LNK files (shortcuts). Double-click Designated File Types. When the Designated File Types window opens, scroll down to “LNK - Shortcut,” click Remove, and then click OK.

Designated File Types

Next, you’ll need to go to the Security Levels section. Right-click Disallowed and choose “Set as default.” When prompted, accept the warning by clicking Yes.

Security Levels

Last, you’ll need to link the GPO to an OU and test your settings. Run a quick gpupdate so the client updates Group Policy, and then try running an executable outside an allowed location.

Program prevented by Software Restriction Policies

A few words of warning: when it comes to Software Restriction Policies, it is incredibly easy to lock down a box to the point of being unusable. Make sure you test, test, and test some more before rolling this out to end user systems. Also, this strategy I’ve outlined here is a very baseline “low-hanging fruit” strategy that only allows executables to run from preapproved locations.

There’s definitely a lot of room for you to lock things down further if you or your organization needs additional lockdown on XP boxes. These settings will prevent unsuspecting and even well-meaning users from either accidentally or intentionally running executables that could harm potentially vulnerable XP systems.