Need Recommendation on Software Restriction Template

[razor]

Hello--noob here

I finally got our CEO to agree to harden our network and allow me to restrict the clients from using their computers as toys and then complaining about their computers being slow/down. :x

I started creating a Policy restricting all software, and then creating exceptions, but we just use plumb too many programs here.

I'm open to suggestions for best practices, but what I would like to do is allow all software and then just start a list of restricted software. I can add to it as I go, as we have Pest Parrol and it shows me what I need to restrict if I miss anything.

Mostly what Pest Patrol finds that I need to restrict right away, are file sharing programs (P2P), ala, Bear Share, kaaza, xolox, etc. and Instant Messanger, ala, AOL and MSN.

If anyone can help me out here, again, I need to restrict P2P and IM right away, per our CEO.

[AdamV]

Welcome!

You can probably stop a lot of the programs you mentioned from doing much of any use by restricting traffic at the firewall as well. But not entirely, so as a defence in depth measure, software restriction is not a bad idea. I know what you are up against - I managed a Windows 98 policy for software restriction once, the only policy option was to allow by whitelist (if it's not on the list, it won't run). Really hard to catch everything that all users might need, but once it's working you don't have to worry about anything new that comes along because it won't work!

Carefully consider some of the following group policy options (they may all be useful but plan carefully, expecially make sure you have suitable exceptions such as admins not being restricted):
disabling start > run
disabling command prompt altogether (read the small print - this will stop logon scripts from running)
restrict common installation programs such as install.bat, setup.exe, etc.
maybe restrict access to removable media if that is a concern for users installing stuff.
make sure users are not running with admin rights. If they have been doing so for a long time you will need to do some careful testing on a representative sample group of users to make sure everything works (especially older or bespoke apps). If you need more ammunition to get this approved, read Aaron Margosis' Blog


If you have the resource, my suggestion would be to start by rebuilding all (or at least most) machines to a standard build. That way you control what applications are installed on day 1, and through good policies you can prevent users installing things thereafter (or at least make it very hard).

Another site to check for lots of good information on security in a windows and AD environment (not as detailed on GP specifically as this one though!) is Security Forums Dot Com

[razor]

Thanks for the insights. I'll keep those in mind. Unfortunately we have at least one application that will not function properly unless the user is designated as the local computer administrator, so I can't go that route.

Rebuilding the workstations is not a viable option either.

I am studying in my MCSA book and the author makes mention of being able to restrict specific programs like Instant Messanger from running on client workstations via a GPO and that there are many good templates out there that would work. I just don't know where to go for those templates.

Any ideas? Anyone else know of a good software restriction GPO template?

[AdamV]

in terms of local admins, some advice I gave in this thread:

http://www.gpanswers.com/community/viewtopic.php?t=595

may be useful to you too (particularly the bit in bold for a quick way to still leave them as admins but far more secure against malware such as worms)

I understand your frustration with apps that don't work unless users have admin rights - been there! Usually this is caused by badly written apps trying to store user-specific data in the registry under HKLM or in ini files (contrary to guidlines since about 1985!). So you can often get roudn these problems by identifying exactly where the problem lies and then applying specific permissions to fix the problem.

Two very useful tools to try and work out what is going on are filemon and regmon - you install them and run, then (try and) do something - they will show what files and registry entries are accessed (or attempted). This may be all you need to give suitable permissions to the "authenticated users" group (ideally not "everyone") so that things work.

If you still can't fix them all, then you should at least try to make the systems as secure (especially against malware) as possible by making sure that users only have admin rights on their own local system and not across to other systems. To do this, add the NT\Interactive user to the local admins group rather than a domain-level group such as Auth Users. So they only have rights on the machine they log in to and no other. Damage limitation!

The best advice for using software restriction policies that you will find is in the Windows XP Security Guide (chapter 6 is all about this!)
Guide starts here:
http://www.microsoft.com/technet/security/prodtech/windowsxp/secwinxp/default.mspx

chapter 6 here (although you should read the intro and other information before diving right in)

There's also some very good stuff here:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx

Note that these do not have "templates" in the sense of something to download and apply, but have templates such as this:

Block Malicious Scripts

An organization wants to be protected from script-based viruses. The LoveLetter virus, technically called a worm, was estimated to have caused between $6 and $10 billion in damage. This worm, which has more than 80 variants, continues to be encountered frequently.

The LoveLetter worm, written in the Visual Basic Script language (VBS), is encountered as LOVE-LETTER-FOR-YOU.TXT.VBS. A software restriction policy blocks this worm simply by disallowing any .vbs file from running.

However, many organizations use VBS files for systems management and logon scripts. Blocking all VBS files from running protects an organization, but a VBS can no longer be used for legitimate purposes. A software restriction policy overcomes this handicap by blocking the undesirable VBS, while allowing legitimate ones to run.

This policy can be created using the rules in Table 4. Rules for Blocking Malicious Scripts
<table>
Default Security Level: Unrestricted

Path Rules

*.VBS - Disallowed
*.VBE - Disallowed
*.JS - Disallowed
*.JSE - Disallowed
*.WSF - Disallowed
*.WSH - Disallowed

Certificate Rules
IT Department Certificate - Unrestricted

and this:

Manage Software Installation

You can configure your organization's machines so that only approved software can be installed. For software that uses Windows Installer technology, this can be accomplished by the policy shown in Table 5 Rules for Managing Software Installation

<table>
Default Security Level: Unrestricted

Path Rules
*.MSI - Disallowed

\\products\install\PROPLUS.MSI - Unrestricted

To download the full security guide zip file you have to register using passport, start here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=2D3E25BC-F434-4CC6-A5A7-09A8A229F118&displaylang=en

This contains templates for securing workstations of different classes, but these contain lots of settings as well as software restriction, so apply settings selectively to your GPOs

[razor]

Excellent!

[razor]

Get this, I used the MSN Messenger program installed on my machine to derive the hashes, but the program still starts at boot up.

If I go the the .exe file within the folder its in, it will be restricted by the GPO, however, if I launch the program via my start up menu, or reboot my PC, it will run.

How can I restrict this program from starting up at reboot, and from the start menu? :?: