Methods of Restricting Registry Access phần 2

The New Path Rule window 2. To create a new Internet Zone rule, proceed in a similar way, but select the New Internet Zone Rule command from the right-click menu.
Nội dung trích xuất từ tài liệu:
Methods of Restricting Registry Access phần 21. Figure 9.7: The New Path Rule window2. To create a new Internet Zone rule, proceed in a similar way, but select the New Internet Zone Rule command from the right-click menu. Select the Restricted Sites option, leave the security level at Disallowed, then click OK.3. To create a Hash rule, right-click the Additional Rules container, select New Hash Rule command from the context menu, and, when the New Hash Rule window appears (Fig. 9.8), click the Browse button to locate a copy of the file that you want to prevent from running. The hash appears in the File Hash field, and information about the file will appear in the File Information box. Now, any attempt to run the specified program will result in a check of the cryptographic hash, and based on the results of this check, the program will be allowed or disallowed to run depending on the policy type. Leave the security level at Disallowed, and click OK. Figure 9.8: The New Hash Rule window 4. The first time you create a rule of a particular type, test it. You can do so by logging off and logging on as an ordinary user, then by attempting to run the tool. You should be refused and receive the message shown in Fig. 9.9. Next, log on as Administrator and attempt to run the tool. You should be able to do so. Test all rules to ensure that they operate as you expect. Any changes to the rules should require a retest. Figure 9.9: Error message displayed to the user when attempting to run restricted softwareAfter creating and testing software restriction policies, take some time to investigate themfor possible holes. For example, when you create path rules, if a program file type is notcovered by the Designated file types list (see Fig. 9.4), the program will be allowed torun. Path rules are the simplest to understand and create. However, they have theirdrawbacks. For example, they will only prevent the user from running restricted toolsfrom within the specified folder and its subfolders. If the user can copy a tool from thatfolder to another location, that user will be able to run the tool. Furthermore, if the usercan obtain a copy of the tool from another source (typically, download it from theInternet or bring it to the office using one of the ultra-portable media discussed above),the user will also be able to run it.Note Finally, if you are creating path rules to prevent system utilities from running, dont forget to make a path rule that includes %windir%system32dllcache. A copy of the disallowed program might be available at this location, and if a path rule does not cover it, the program will be able to run.Thus, if the aim of your policy is to absolutely prevent users from running certain tools,you should create hash rules for each one.Note Hash rules, however, also do not provide absolute protection against undesirable software. For example, later versions of a restricted program will not be restricted by the hash rules that you have written.Finally, consider what happens if a program calls another program that calls yet anotherone - you must carefully investigate what happens in each particular case. Of course, ifthe program is disallowed, it cannot run, and, therefore, cannot call other programs. Onthe other hand, if a program is not restricted, it can both run on its own or be called fromwithin another allowed application. The situation is possible, however, when anunrestricted program calls a disallowed one. The disallowed program will not run, ofcourse, but this might result in the failure of some unrestricted programs, which might berequired for users to do their jobs. Another important point that you need to consider issituations in which there are multiple policies applied to the same program. In this case,you must be aware of the following order of precedence that exists when processingsoftware restriction policies (the first item in the list has the highest precedence): Hash rule Certificate rule Path rule (if path rules conflict, the most restrictive will take precedence) Internet zone ruleTo conclude our discussion of software restriction policies, it is necessary to emphasizeseveral other points, briefly listed below: Before designing and implementing domain-wide software restriction policies, you will have to migrate to Windows Server 2003 domains and upgrade all clients to Windows XP. Remember that Windows 2000 and earlier versions are unable to process software restriction policies. Be aware that this technology is rather new, and it will take time before it becomes mature and reliable. At the moment of this writing, it was not totally bug-free, and even the simplest local software restriction policies required careful testing ...