Example of writing Windows Software Restriction policy rules

For Windows Group policies, you may only use the functions in the "management template. There are not many friends who believe in "Software Restriction Policies.
If Software Restriction Policies are used well, we believe they can be compared with some HIPS software. By combining NTFS and Registry Permissions, you can fully implement comprehensive security configuration of the system. This is also a built-in function of the system, which can be seamlessly integrated with the system, it does not occupy additional CPU and memory resources, nor is it incompatible. Because it is located at the bottom of the system, its interception capability is unmatched by other software, the disadvantage is that it is not flexible and intelligent enough to ask users. Next, let's take a full look at the Software Restriction Policies.

This series of articles will focus on the following aspects:

· Overview
· Additional rules and security levels
· Priority of Software Restriction Policies
· Permission assignment and Inheritance of rules
· How to Write rules
· Sample rules

Today, we will introduce an example of compiling Software Restriction policy rules in Windows Group policies.

Root directory rules

 

If we want to restrict the running of a program in a directory, we generally create:

C: Program Files *. * Not Allowed

Such a rule seems to be okay, but in special circumstances it may lead to accidental injury, because wildcards can match files or folders. If this directory
Such as SiteMapBuilder. such as C: Program FilesSiteMapBuilder. NETSite Map Builder.. NET), can also match with the rule, resulting in accidental injury, the solution is to modify the rule:

C: Program Files Not Allowed
C: Program Files * unrestricted

In this way, sub-directories are excluded, so as to avoid accidental damage.

Internet security rules

We are often poisoned by viruses during Webpage Browsing. During Webpage Browsing, viruses will automatically be downloaded to the webpage cache folder through browser vulnerabilities, and then we will
Copy to a sensitive system location, such as windows system32 program files, and run the program. Therefore, it is not enough to restrict the browser cache folder. A more practical precaution is to prohibit ie from creating files in sensitive locations. Based on this, we can create the following rules:

% ProgramFiles % Internet users eriexplore.exe basic user
% UserProfile % Local SettingsTemporary Internet Files ** not allowed
% UserProfile % Local SettingsTemporary Internet Files * Not Allowed
% UserProfile % Local SettingsTemporary Internet Files Not Allowed
% UserProfile % Local SettingsTemporary Internet Files Not Allowed

If you are using another browser, set it to "basic user.

USB flash drive rules

Practice:

USB flash drive: * No trust is allowed.

However, it is highly secure and does not impose any restrictions on the normal operation of the USB flash drive.

CMD restriction policy

% Comspec % basic user

Note that the system processes the CMD and batch files separately. Even if you do not allow the CMD settings, you can still run the batch processing.

We usually seldom use some systems, but we also need to limit programs with potential threats. For example, ftp.exe, tftp.exe, telnet.exe, net.exe, net1.exe, debug.exe, 、at.exe, arp.exe, wscript.exe, cscript.exe, and so on can all be set as restricted or not allowed directly.

Prohibit disguised System Processes

Svchost.exe not allowed
C: WindowsSystem32Svchost.exe is not restricted.

If you are interested and energetic, you can also create a whitelist for all processes in the system, which may be more secure.

Other rules can be used freely.

Policy backup

Finally, we will mention the backup policy. We can't do this. Redo the system again next time. Haha, the backup is very simple. We can back up the backup by exporting the Registry (we will not introduce it if we do not advocate it ).
You can also directly back up the file and open C: WINDOWSsystem32GroupPolicyMachine. There is a Registry. pol file under this directory. Back up the system, redo the system, and COPY it directly. Of course, you can also share your policies with more people. Note that if this Machine Folder does not exist, you must never create it manually. Otherwise, it is invalid. You can use the method of creating a policy as described earlier, this folder will be generated after creation, or you can back up this folder directly during Backup. Remember not to create it manually. If you do not want to use these policies, simply rename or delete the Registry. pol file. Practice: how to solve the USB flash drive Virus

I will introduce some methods implemented by the system itself, without using third-party software. If you like third-party software, don't discuss it.

I have already introduced the first method: Use a Software Restriction policy to create a rule "? *. * It is not allowed to run even if you are infected with a USB flash drive.

The second method is actually an extension of the first method. We have analyzed the process of the system processing the autorun. inf file, from which we can see that there is a step,
Assumer.exe reads autorun. the inf content will be written to the Registry. Therefore, we can restrict the permissions of key values in the registry so that it cannot modify the registry, to prevent the running of the USB flash drive virus. Related registry keys:

Hkey_current_usersoftwaremicrosoftwindowscurrentversionpolicermountpoints2 * shellopen

Hkey_current_usersoftwaremicrosoftwindowscurrentversionpolicermountpoints2 * shellautorun

Hkey_current_usersoftwaremicrosoftwindowscurrentversionjavasermountpoints2 * shellexplorer

Hkey_current_usersoftwaremicrosoftwindowscurrentversionjavasermountpoints2 * shell * Command

Hkey_current_usersoftwaremicrosoftwindowscurrentversionpolicermountpoints2

The specific method is to reduce the permissions of these keys, or directly cancel the access permissions of all users.

The third method is to use a Windows vulnerability to create a Bug folder to prevent Autorun viruses. The specific method is:

First, create an image named Autorun under the USB flash drive. inf folder, and then create a folder with ". "BUG folder. In this case, autorun. the inf folder cannot be deleted. For example, if we create a folder in drive D:

Create the Autorun. inf folder under drive D, run CMD, and enter
Md d: autorun. infest ..

In this way, you can create a folder named "test." In the autorun. inf folder, which cannot be accessed in the resource manager, renamed, or deleted.

This method is relatively negative, but it is suitable for the use of USB flash disks on other computers. However, it is said that some viruses can already deal with this method.

The fourth method is also a widely spread practice, that is, the automatic playback function is disabled through the Group Policy or registry. I was convinced of this method before, but through recent
A few small experiments have found that this method is also flawed. It can only prevent some hard-working U disk viruses, but it cannot prevent many viruses. We can do the following experiments to verify this. Create an autorun. inf file, store it in the root directory of the USB flash drive, and COPY a NOTEPAD to the root directory of your USB flash drive. The content is as follows:

[Autorun]
Opendesknotepad.exe
Shellopen = open (& O)
Shellopencommand#notepad.exe
ShellopenDefault = 1
Shellexplore = Resource Manager (& X)
Shellexplorecommand#notepad.exe

Disable the automatic playback function from the Group Policy. Right-click the USB flash drive and there is no option in the new menu. However, if you double-click the USB flash drive, you will find that NOTEPAD is running. Right-click or choose to open or the resource manager will run, because autorun. inf has modified the functions of the two items in the right-click menu. So what does automatic playback do? I believe many packages know that there are a lot of CDs now. After you put the discs into the optical drive, you don't need to perform any operations, and an interface will pop up, asking you to choose what to run, or what kind of playing is like this. Remember that rising's soft killer is like this, and some driver disks of the motherboard graphics card also have this function, but put the same content into the USB flash drive, when you insert a USB flash disk, it does not run automatically. Obviously, this function of the operating system is only valid for the disc. This is what we know about the automatic playback function, we disabled the automatic playback function in the Group Policy, but it does not run automatically after the disc is put into the optical drive. However, if you right-click the optical drive, you will find that the automatic playback option still exists, it makes no sense to disable automatic playback. Here we need to pay attention to a small concept. There is a difference between AutoPlay and AutoRun. To completely disable this function of the system, we can only start with the service. If you are familiar with the system, you will know that the system handles automatic playback and runs automatically. The service is Shell Hardware Detection, therefore, as long as the Shell Hardware Detection service is disabled, all the USB flash drive viruses cannot run. However, this method is not omnipotent. Due to system differences, some systems may slow the system startup after the service is disabled.

I personally think that the method of modifying the registry is the most effective and has no side effects to prevent the USB flash drive virus.