Prevent Files With These Extensions Running From These Locations...

[DaveP]

I know this has been asked before. However I think I have followed the advice in the other posts and it is still not working for me so what am I doing wrong?

Taking one file type as an example [solving the problem gives me the answer to other file types also]

Let us say that I want to prevent students running CMD from their home folders and from memory stick locations. And let us say that home folders are mapped to U:\ and memory sticks are created as E:\ and F:\

At the server in Group Policy [GPO created to control student user behaviour] In User Configuration I have created a Designated File Type in:

Policies\Windows Settings\Security Settings\Software Restriction Policies

File Type: CMD

In the same GPO I have placed a Path Rule under User Configuration:

Policies\Windows Settings\Security Settings\Software Restriction Policies\Additional Rules

Path Rule: U:\*.CMD: Disallowed

However I find that students can still run a test CMD file.

What am I missing?

Server: Windows Server 2008: Standard Edition: 64 Bit: Service Pack 2

Client: Windows XP Pro: SP3

Thanks.

[p858snake]

have you told the machine and server to gpupdate (forcefully)?

[DaveP]

have you told the machine and server to gpupdate (forcefully)?

Yes I have also restarted the station and waited an absolute age.

[SYNACK]

Have you looked at it with the RSoP snapin to see what policies have applied and what errors, if any are generated?

[Arthur]

What am I missing?

I may be wrong, but shouldn't you be disallowing cmd.exe and command.com (both located in %SystemRoot%\System32) because you would usually block VBS files by disallowing cscript.exe and wscript.exe?

It's also worth mentioning that even after you have done the above, it is still very easy to bypass these restrictions via process injection. I reckon a student could easily do this if they spent a few minutes on Google.

[DaveP]

I may be wrong, but shouldn't you be disallowing cmd.exe and command.com (both located in %SystemRoot%\System32) because you would usually block VBS files by disallowing cscript.exe and wscript.exe?

It's also worth mentioning that even after you have done the above, it is still very easy to bypass these restrictions via process injection. I reckon a student could easily do this if they spent a few minutes on Google.

What I am actually trying to do it develop a GPO which can be eventually be expanded to include all file type and all locations where I do not want students running files they control.

They might bring in a memory stick that has a batch file they have written at home, it may have a shortcut to a program that I do not want the students to run directly or it may have a portable executable. So as a start I am trying to prevent students from running:

*.EXE, *.BAT, *.ZIP, *.COM, *.CMD, *.LNK from U:\, E:\ and F:\ [these are areas connected to the school network they have read/write control over]

Or is this not the right approach?

[Arthur]

What I am actually trying to do it develop a GPO which can be eventually be expanded to include all file type and all locations where I do not want students running files they control.

Actually I was wrong. I was thinking of something else.

An easy way to prevent all executables and scripts from being run from USB flash drives would be to create a couple of path rules like: "E:\*" and "F:\*". This should work no matter many sub-folders they use. I assume you're still using USBDLM so that removable drives do not get assigned other drive letters?

N.B. I've not tried it myself yet, but apparently restricted users can use %SystemRoot%\System32\runas.exe to bypass SRPs so you may want to block that too. e.g.

runas /trustlevel:"Unrestricted" e:\schoolwork\game.exe

For files in user areas, you could use "File Server Resource Manager" on your server to block each extension you don't want to have in there.

Yet another approach might be to do the exact opposite and disallow everything by default because there will almost always be something you have missed (like WSH and HTA files). All you have to do then is explicitly allow just the programs and/or locations via hash or path rules. Details on how to do this can be found here and here (from step 3).

[DaveP]

Yes I am using USBDLM but I can't experiment with that today because I am not on site. I can experiment with student home folders [U:\]

I have created a path file for U:\ [U:\*.CMD and U:\*.BAT] but I find that my students can still run these file types from this location.

Do I have the 'wrong end of the stick' on this setting?

[Arthur]

Does U:\* work?

[DaveP]

Does U:\* work?

That looks like it will deny access to everything in U:\. I can give it a go and let you know...

[Arthur]

Not everything. By default it should be just the following designated file-types.

Extension / Description
. ADE	Microsoft Access Project Extension
. ADP	Microsoft Access Project
. BAS	Visual Basic Class Module
. BAT	Batch File
. CHM	Compiled HTML Help File
. CMD	Microsoft Windows NT Command Script
. COM	Microsoft MS-DOS Application
. CPL	Control Panel Extension
. CRT	Security Certificate
. EXE	Application
. HLP	Windows Help File
. HTA	HTML Applications
. INF	Setup Information File
. INS	Internet Communication Settings
. ISP	Internet Communication Settings
. JS	Microsoft JScript File
. JSE	JScript Encoded Script File
. LNK	Shortcut
. MDB	Microsoft Access Application
. MDE	Microsoft Access MDE Database
. MSC	Microsoft Common Console Document
. MSI	Windows Installer Package
. MSP	Windows Installer Patch
. MST	Visual Test Source File
. PCD	Photo CD Image
. PIF	Shortcut to MS-DOS Program
. REG	Registration Entries
. SCR	Screen Saver
. SCT	Windows Script Component
. SHS	Shell Scrap Object
. URL	Internet Shortcut (Uniform Resource Locator)
. VB	VBScript File
. VBE	VBScript Encoded Script File
. VBS	VBScript Script File
. WSC	Windows Script Component
. WSF	Windows Script File
. WSH	Windows Scripting Host Settings File

[DaveP]

This is what I have in that GPO:

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% 
Security Level Unrestricted 
Description  
Date last modified 11/07/2010 10:56:35 
 
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% 
Security Level Unrestricted 
Description  
Date last modified 11/07/2010 10:56:35 
 
U:\* 
Security Level Disallowed 
Description  
Date last modified 11/07/2010 13:50:23 
 
U:\*.BAT 
Security Level Disallowed 
Description  
Date last modified 11/07/2010 11:07:09 
 
U:\*.CMD 
Security Level Disallowed 
Description  
Date last modified 11/07/2010 11:06:37

I have run gpupdate /force

I have restarted the station

I have waited for some time [more than an hour] before logging on a s a typical student and I find that this user can still run CMD and BAT files from U:\

Using Group Policy Modelling Wizard at the Domain Controller to check if the policy is applied to this test student I find that the policy does indeed apply to this individual.

I must still be missing something but what?

[Arthur]

I think you may need to make a few changes. What happens if you use these instead?

%SystemRoot%
Security Level: Unrestricted

%ProgramFiles% 
Security Level: Unrestricted

U:\*
Security Level: Disallowed

%SystemRoot%\System32\cmd.exe
Security Level: Disallowed

%SystemRoot%\System32\command.com
Security Level: Disallowed

If that works you will probably want to add the following to your list too.

E:\*
Security Level: Disallowed

F:\*
Security Level: Disallowed

%SystemRoot%\System32\cscript.exe
Security Level: Disallowed

%SystemRoot%\System32\wscript.com
Security Level: Disallowed

%SystemRoot%\System32\mstsc.exe
Security Level: Disallowed

%SystemRoot%\System32\mmc.exe
Security Level: Disallowed

%SystemRoot%\System32\msiexec.exe
Security Level: Disallowed

%SystemRoot%\System32\rundll32.exe
Security Level: Disallowed

%SystemRoot%\System32\task*.exe
Security Level: Disallowed

%SystemRoot%\System32\telnet.exe
Security Level: Disallowed

%SystemRoot%\regedit.exe
Security Level: Disallowed

As you can see, using a white-list might be a better approach because there are far too many EXEs to block with a black-list.

[Arthur]

How did you get on, Dave. Any luck?

[DaveP]

Hi. I took the settings suggested in your previous post.

Still not working I am afraid.

Could be a job for the Summer Holiday?