Example of writing software restriction policy rules in Windows Group Policy (1)

For Windows Group Policy, perhaps everyone is using more of the features in the "Management Templates". For the "software restriction strategy" I believe that not many friends have used it.

If the software restriction strategy is good, I believe it can be compared with some HIPS software. If you combine NTFS permissions and registry permissions, you can fully implement the system's full security configuration. At the same time, because this is a built-in function of the system, it seamlessly integrates with the system, and does not occupy additional CPU and memory resources. The incompatibility phenomenon, because it is located at the bottom of the system, its interception capability is unmatched by other software. The downside is that its settings are not flexible and intelligent, and will not ask the user. Let's take a comprehensive look at the software restriction strategy.

This series of articles will focus on the following aspects:

·Overview
·Additional rules and security levels
·Priority of software restriction policy
· Rule Assignment and Inheritance
· How to Write a Rule
· Example Rule

Today we introduce an example of writing a software restriction policy rule in Windows Group Policy.

Root Directory Rules

If we want to restrict the running of programs in a directory, it is usually created such as:

C:\\Program Files\\*.* Not allowed < Br>

Such a rule seems to be no problem, but in special cases it can cause accidental injury, because the wildcard can match the file or match the folder. If there is a directory such as SiteMapBuilder.NET under this directory
(such as C:\\Program Files\\SiteMapBuilder.NET\\Site Map Builder.NET), it can also match the rules, resulting in accidental injury. The solution is to rule the rules. Modified:

C:\\Program Files Not allowed
C:\\Program Files\\*\\ Unrestricted

This eliminates subdirectories and thus does not cause accidental injury.

Rules for Internet Security

We are often poisoned when we browse the web. When we browse the web, the virus will be automatically downloaded to the web cache folder through the browser vulnerability. Then, copy your own
to a system sensitive location, such as windows system32 program files, etc., and then run. So simply limiting the browser cache folder is not enough. A more practical precaution is to prevent IE from creating files in sensitive locations. Based on this, we can create the following rules:

%ProgramFiles%\\Internet Explorer\\iexplore.exe Basic User
%UserProfile% \\Local Settings\\Temporary Internet Files\\** Not allowed
%UserProfile%\\Local Settings\\Temporary Internet Files\\* Not allowed
%UserProfile%\\Local Settings\\Temporary Internet Files\\ Not allowed
%UserProfile%\\Local Settings\\Temporary Internet Files Not Allowed

If you are using a different browser, set it to "Basic User" as well.

U disk rules

More practical:

U drive letter: \\* Unallowed distrust can be restricted

Set to a higher degree of security, and there is no limit to the normal operation of the USB flash drive.

CMD Restriction Policy

%Comspec% Basic User

It should be noted that the system handles CMD and batch files separately, even if CMD is not allowed. , you can still run batch processing

For some systems we rarely use it, but there are restrictions on programs that have potential threats. For example, ftp.exe, tftp.exe, telnet.exe, net.exe, net1.exe, debug.exe, at.exe, arp.exe, wscript.exe, cscript.exe, etc., can be set to be subject to Limited or directly set to not allowed.

System processes that prohibit camouflage

svchost.exe is not allowed
C:\\Windows\\System32\\Svchost.exe Unrestricted

If you are interested With a spirit, you can also make a white list of all the processes of the system, so the security may be higher.

Other rules are free to play.

Backup of Policies

Finally, mention the backup of the policy. Can't do this hard to finish the next redo system again, huh, huh, backup is very simple, we can back up by exporting the registry (not recommended, it will not be introduced).
You can also back up by directly backing up the file, open C:\\WINDOWS\\system32\\GroupPolicy\\Machine, there is a Registry.pol file in this directory, yes, it is. Back up it, redo the system and COPY directly, you can also share your strategy with more people. One thing to note here is that if the Machine folder is not available, it must not be created manually. Otherwise, it can be used. You can use the method of creating a policy that we introduced earlier. After creating it, this folder will be generated, or you can backup it. Back up this folder directly. Don't remember to build it manually. If you don't want to use these strategies, it's easy to rename or delete the Registry.pol file.