Lesson 1:Tuning Security for Client Roles | MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)

< Day Day Up >

Administrators tune the security of server roles to reduce the risk of a malicious attacker compromising a server. For client computer roles, security tuning tends to focus on reducing costs by restricting the desktop environment. Many of the most time- consuming help desk calls occur after a user installs non-standard hardware and software. Fortunately, Microsoft Windows clients that participate in an Active Directory directory service domain can be centrally configured and managed to provide administrators with very granular control over what users can and cannot do.

You can specify which applications users can access and which features are available based on users’ job types, services provided by the IT department, and the needs of your environment. For example, you can use Group Policy settings to prevent users from accessing various storage devices, such as floppy disk drives, hard disks, or CD-ROMs. By using security policy or access control lists (ACLs), you can also secure objects, such as system files and the registry, so that your users cannot gain access to them.

Implementing restricted client configurations can result in increased user productivity by reducing the incidence of computer-related problems. Also, because standard configurations are easier to troubleshoot or replace, using them brings about a reduction in support costs.

Planning Managed Client Computers

When planning the requirements for managed client computers, start by identifying the baseline security level that is appropriate for users to have on their computers. The baseline user security level is specified by granting users membership to one of these groups: Users, Power Users, and Administrators. Membership in the Users group gives the most protection from a number of external threats, such as viruses, and it limits the damage that users can accidentally or intentionally cause to their computers. However, user level permissions have the most incompatibility problems with older applications. Take particular care before you give users privileged access to computers that they share with other employees.

Next, identify the types of systems users need to interoperate with. Interoperability with earlier systems, such as Microsoft Windows NT 4.0–based servers and UNIX file servers, necessitates that some of the security you might use in a pure Windows Server 2003 environment must be relaxed.

Finally, consider the level of support users provide for their own computers. Users who use portable computers and provide their own support might require administrator rights on their computers. Other high-performance users, such as developers, might also need administrative rights.

Real World

Sure, we’ve all been annoyed by the user who decided to free up some disk space by deleting the useless Windows folder, but the worst users to deal with are other administrators. We system administrators think we know everything about computers. The fact is, even if you know Windows Server like the back of your hand, that doesn’t mean you’re an expert about Windows on a desktop computer.

For example, I destroyed the modem in my laptop a few years ago by plugging it into the digital phone line at a hotel. Digital phone lines have higher voltages than analog lines, and the extra voltage will damage the modem’s circuitry. It was a dumb mistake, and it’s one that every desktop support guy has heard a dozen times. The IT guy I called immediately knew that I had broken my modem, but I had no idea until I talked to him. Even though I had managed a large modem bank, I had no experience with using modems on the go.

Before deploying your management solutions to a wide base, fully test your design in a lab environment. Minimally, your test environment should consist of a domain controller and one computer representative of each client computer type in your organization. These client computer types might include desktop computer, mobile computer, and highly restricted kiosk computer. If you are testing software installation through Group Policy, include one or more servers set up as software distribution points. By setting up a test-to-production environment deployment process, you can ensure that you provide a reliable and consistent configuration management solution.

Document the testing network in addition to all steps required to set it up. If new hardware, such as a new server, is being added to your organization’s network, use this same hardware in your test deployment if possible. To minimize variables and to ensure that testing does not interfere with your organization’s network services, keep the testing network on its own isolated local area network (LAN).

After completing tests in a controlled environment, select a group of users to pilot your configuration. Keep the users to a manageable number. A pilot can expose unexpected problems on a small scale so that you can resolve them before deploying on a large scale. Verify that the deployed technology is operating as expected. If you perform an iterated deployment, deploy and test in phases, and then emphasize the testing of the final configuration.

Software Restriction Policies

Software restriction policies are a feature in Windows XP and Windows Server 2003 that can be used to regulate unknown or untrusted software. Businesses that do not use software restriction policies put the burden of identifying safe and unsafe software on the users. Users who access the Internet must constantly make decisions about running unknown software. Malicious users intentionally disguise viruses and Trojans to trick users into running them. It is difficult for users to make safe choices about what software they should run.

With software restriction policies, you can protect your network from untrusted software by identifying and specifying the software that is allowed to run. You can define a default security level of Unrestricted or Disallowed for a Group Policy object (GPO) so that software is either allowed or not allowed to run by default. You can make exceptions to this default security level by creating software restriction policy rules for specific software. For example, if the default security level is set to Disallowed, you can create rules that allow specific software to run.

You can use four types of rules to create a software restriction policy: hash rules, certificate rules, path rules, and Internet zone rules. When a hash rule is created for a software program, software restriction policies calculate a unique hash of the executable file. When a user tries to start an application, Windows generates a hash of the application and compares it to existing hash rules for software restriction policies. The hash of a software program is always the same, regardless of where the program is located on the computer. However, if a software program is altered in any way, its hash also changes, and it no longer matches the hash in the hash rule for software restriction policies.

You can create a certificate rule that identifies software and then allows or does not allow the software to run, depending on the security level. For example, you can use certificate rules to automatically trust software from a trusted source in a domain without prompting the user. You can also use certificate rules to run files in disallowed areas of your operating system.

A path rule identifies software by its file path. For example, if you have a computer that has a default security level of Disallowed, you can still grant unrestricted access to a specific folder for each user. You can create a path rule by using the file path and setting the security level of the path rule to Unrestricted. Some common paths for this type of rule are %userprofile%, %windir%, %appdata%, %programfiles%, and %temp%. You can also create registry path rules that use the registry key of the software as the path. Because these rules are specified by the path, if a software program is moved, the path rule no longer applies.

An Internet zone rule can identify software from a zone that is specified through Microsoft Internet Explorer. Internet zone rules are useful for preventing users from running applications downloaded from the Internet, but still allowing programs stored on the local computer or other trusted computers to run. The zones you can choose from are Internet, Local Intranet, Restricted Sites, Trusted Sites, and My Computer.

The My Computer zone includes any applications installed on the local computer. The Local Intranet zone is intended to be used for computers located within your organization’s internal network, but it does not include any sites by default. The Trusted Sites zone, by default, includes only Web sites used to download updates from Microsoft and to submit error messages to Microsoft. By default, the Restricted Sites zone is empty. The Internet zone includes any computers not located in any of the other zones.

To specify which computers on the network are included in the Local Intranet, Restricted Sites, and Trusted Sites zones for a single computer, start Internet Explorer, and on the Tools menu, click Internet Options, and then click the Security tab. You can then select Local Intranet, Restricted Sites, or Trusted Sites and click the Sites button to add additional locations that will be included in that zone. You can also configure zones by using a GPO: Open a GPO in the Group Policy Object Editor, expand User Configuration\Windows Settings\Internet Explorer Maintenance, and then click Security. Then, in the right pane, double-click Security Zones And Content Ratings.

Software restriction policies consist of the default security level and all the rules that apply to a GPO. Software restriction policies can be applied across a domain, to local computers, or to individual users. Software restriction policies provide a number of ways to identify software, and they provide a policy-based infrastructure to enforce decisions about whether the identified software can run. With software restriction policies, when users run software programs, they must adhere to the guidelines that are set up by administrators.

With software restriction policies, you can control the ability of software to run on your system. For example, if you are concerned about users receiving viruses through e-mail, you can apply a policy setting that does not allow certain file types to run in the e-mail attachment directory of your e-mail program. You can even restrict policies based on users, allowing certain users on a computer to run an application, but not others.

Security for Desktop Computers

When a computer manufacturer delivers a new computer to an organization, the operating system is generally configured to provide the greatest flexibility to the typical user. Many organizations have additional software installed on top of the operating system, such as Microsoft Office. This provides power users with the tools they need to do their jobs.

However, many types of employees do not require much flexibility and will actually be more productive if the software on their computers is restricted. For example, a user in the accounts payable department might only need access to an e-mail client, accounting software, and a Web browser. For this type of user, restricting the applications they can run can make them more productive (for example, by removing Solitaire). Additionally, it can reduce the risk of malicious software, such as viruses and Trojans, infecting the computer.

In a typical restricted desktop computer role, the desktop and Start menu are significantly simplified. Users cannot make extensive customizations, other than a limited number of application-specific settings. Applications are typically allocated to users based on their job roles, and users cannot add or remove applications. This type of desktop configuration is appropriate in a marketing or finance department, for example. In these areas, users require only a specific and limited set (typically three to five) of productivity and in-house applications to do their jobs.

If your environment requires secure desktops, create a security template that contains the standard desktop security settings. Base this new security template on the Hisecws.inf predefined security template, which contains the majority of the settings you would need to specify. Besides the settings already defined in the Hisecws.inf template, you should consider enabling both the Accounts: Rename Administrator Account and Accounts: Rename Guest Account policies. Also, your organization’s security policy might require that you warn users as they log on by enabling the Interactive Logon: Message Text For Users Attempting To Log On and Interactive Logon: Message Title For Users Attempting To Log On policies. Consult your legal department for the exact messages used to warn users.

Security for Mobile Computers

Mobile computers require that you attend to several additional security considerations beyond those of desktop computers. Mobile users might use their computers while traveling, which might require them to perform administrative tasks that a member of the IT group would normally perform. For example, a mobile user might need to print a document using a different printer than the one installed in the office, and would need to install the correct printer driver. To allow this, disable the Devices: Prevent Users From Installing Printer Drivers security option. If you anticipate that users who work away from the office will need to install or reinstall applications while working remotely, you might want to enable the Always Install With Elevated Privileges setting in the Administrative Templates\Windows Components\Windows Installer node.

Mobile users might connect to foreign networks, such as a wireless hotspot at a coffee shop. These foreign networks won’t have the benefit of your organization’s network security, so mobile users have an elevated risk of being attacked across the network. To mitigate this risk, enable the Internet Connection Firewall (ICF, known in Service Pack 2 as Windows Firewall) on all network interfaces for mobile computers. Unfortunately, ICF cannot be configured by using Group Policy settings. Lesson 2 in this chapter contains more information about firewalls.

It’s much more likely that a mobile computer will be stolen than a desktop computer, which makes Encrypting File System (EFS) extremely important on mobile computers. To reduce the likelihood that an act of theft will compromise your business’s secrets, any confidential documents should be encrypted with EFS. Though EFS cannot be enabled for specific folders using security templates, you can create a logon script that enables EFS for folders that might contain confidential data.

Mobile users might require additional flexibility to configure their systems, for example, they might need to configure virtual private network (VPN) connections. In such cases, modify the appropriate settings under the User Configuration\Administrative Templates\Network\Network Connections node of the applicable GPO.

Security for Kiosks

A kiosk is a public workstation that runs only one application, runs unattended, and uses a single user account that automatically logs on. A kiosk should be highly secure, should be simple to operate, and should not allow users to make changes to the default settings. The Start menu, and even the desktop, should be unavailable. Users should not be able to customize the computer, install applications, save any data, or access the file system directly.

Off the Record

Ever pick up the quarterly hacker’s magazine 2600? It’s always an interesting read, and it can be educational for those of us working on the lawful side of the information security industry. Well, if you read a couple of issues of it, you are bound to find detailed descriptions of how to hack into some kind of kiosk computer. It seems like there’s always a way to make a kiosk computer do something it’s not intended to do. One common trick is to press Ctrl+C during startup when a script is running—this can interrupt the script and give the user a command prompt.

Kiosks usually run dedicated applications. The dedicated application could be a custom application, a Web application accessed by means of Internet Explorer, or another application, such as Microsoft PowerPoint. The default application should not be Windows Explorer, or any other shell-like application, because of the flexibility and potential for misuse that Windows Explorer provides. Be sure the command prompt is disabled and Windows Explorer cannot be accessed. Applications used for kiosk scenarios must be carefully checked to ensure they do not contain “backdoors” that allow users to circumvent system policies.

When creating a security template for a kiosk computer, start by creating a copy of the Hisecws.inf template. Assuming that you plan to make the primary kiosk user account a member of the local Users group on the computer, modify the security template so that the Users group is not granted the Shut Down The System user right, which might be granted by default.

Within the Audit Policy node of the template, you should enable restrictive password and account lockout policy settings for the local accounts. If a user does manage to get to a logon prompt, the account lockout settings will prevent the user from successfully guessing a password. Enable extensive security logging and system auditing. This can be useful for proving that a user did attempt to misuse the system and for identifying how the attacker compromised the computer.

Within the Security Options node of the security template, enable both the Accounts: Rename Administrator Account and Accounts: Rename Guest Account policies. Use file and folder permissions to prohibit changes to files or folders outside of the user’s profile folder. Specifically, apply more restrictive access controls in the root directory. Restrict registry permissions to limit access to the computer registry hive, which prohibits the user from making changes.

After importing the kiosk security template into the kiosk GPO, you should specify several GPO settings that are not configurable by means of security templates. Specifically, expand User Configuration\Administrative Templates, and examine each node contained within. You should enable every setting starting with Remove in the Start Menu And Taskbar node. Also, carefully review and configure the settings contained within the Desktop, Network, System, and Control Panel nodes of the GPO.

Practice: Restricting Software

In this practice, you will restrict two applications from running on Computer1. You must complete this practice before completing the troubleshooting lab in this chapter.

Exercise: Configure software restrictions

In this exercise, you will familiarize yourself with software restriction policies by creating a new GPO.

Log on to the cohowinery.com domain on Computer1 using the Administrator account.
Create a new Microsoft Management Console (MMC) console, and add the Group Policy Object Editor snap-in.
When the Group Policy Wizard appears, click the Browse button.
In the Browse For A Group Policy Object dialog box, click the Create New Group Policy Object button.
Name the GPO Test Software Restriction Policy. Click the new GPO, and then click OK. Click Finish, click Close, and then click OK to return to the MMC console.
Expand Test Software Restriction Policy, Computer Configuration, Windows Settings, and Security Settings.
Right-click Software Restriction Policies, and then click New Software Restriction Policies.
In the left pane, click Software Restriction Policies.
In the right pane, right-click Enforcement, and then click Properties.
Click All Software Files.

Dynamic Link Libraries (DLLs) are not programs in themselves. They are the building blocks of programs, and they contain libraries of functions that perform specific tasks, such as creating a new file or establishing a network connection. To have the policies apply to all software files, including DLLs, select All Software Files. Otherwise, leave All Software Files Except Libraries selected.
Click All Users, and then click OK.

To have the software restrictions apply to administrators in addition to regular users, leave All Users selected. If you would rather enable administrators to more easily troubleshoot software problems by bypassing the restrictions, select All Users Except Local Administrators.
In the left pane, click Security Levels. The right pane shows two levels: Disallowed and Unrestricted. Leave Unrestricted specified as the default.

Unless an administrator has changed the setting, Unrestricted is specified as the default. This allows all applications to run unless specifically denied. Although this allows administrators to name applications that should not be run, it can be easily bypassed by a user who renames an application file. Specifying Disallowed as the default ensures that no applications can run unless specified by an administrator. Using the Disallowed setting requires a great deal of configuration and testing because otherwise it will prevent end users from accessing their software.
In the left pane, right-click the Additional Rules node, and then click New Hash Rule.
Click the Browse button, and then navigate to C:\Windows\Notepad.exe. Click Open.
Click Security Level, and then select Disallowed.

This prevents anyone logged on to a computer to which the GPO applies from running the Notepad executable file.
Click OK.
In the left pane, right-click the Additional Rules node, and then click New Path Rule.
Click the Browse button, and then navigate to C:\Windows\PcHealth\HelpCtr\ Binaries. Click OK.
Click Security Level, and then select Disallowed.

This prevents anyone logged on to a computer to which the GPO applies from running Msconfig, an executable file in the specified path.
Click OK.
Close the Group Policy Object Editor.
Start the Active Directory Users And Computers console.
Right-click Domain Controllers, and then click Properties.
Click the Group Policy tab, and then click the Add button.
In the Add A Group Policy Object Link dialog box, click the All tab. Click Test Software Restriction Policy, and then click OK twice.
Restart the computer to ensure that the updated Group Policy takes effect. After the computer restarts, log on to the cohowinery.com domain on Computer1 using the Administrator account.
Click Start, and then click Run. Type Notepad, and then click OK.

The application will not run, because the software restriction policy does not allow it. Instead, you will see the dialog box shown in Figure 4.2.

Figure 4.2: Software restrictions forbidding the execution of Notepad
Click Start, and then click Run. Type Msconfig, and then click OK.

The application will not run, because the software restriction policy does not allow it.
Use Windows Explorer to browse to the C:\Windows folder. Right-click Notepad.exe, and then click Copy. Right-click the C:\Windows folder in the right pane, and then click Paste.
In the right pane, scroll to the bottom of the list of files, and double-click the file Copy Of Notepad.exe.

The application will not run, because the software restriction policy does not allow files that match the hash of the Notepad.exe file to run. Therefore, even though you have renamed the file, it will still not run.
Use Windows Explorer to browse to the C:\Windows\PcHealth\HelpCtr\Binaries folder. Right-click Msconfig.exe, and then click Copy. Right-click the C:\Windows folder in the left pane, and then click Paste.
In the left pane, click the C:\Windows folder. In the right pane, double-click the file Msconfig.exe.

The application will run, because the software restriction policy was configured to restrict the path of the file, and not the file itself. Therefore, moving the file to a different path allows the user to bypass the restriction.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

Which of the following software restriction rules can be used to allow any application on an intranet to be run on a computer?
1. Hash rules
2. Certificate rules
3. Path rules
4. Internet zone rules
Which of the following software restriction rules should be used to ensure that a particular executable file cannot be run?
1. Hash rules
2. Certificate rules
3. Path rules
4. Internet zone rules
Which of the following rules would you not enforce on a computer to be used as a kiosk?
1. Remove the Run menu item from the Start menu.
2. Deny the Everyone group the right to log on locally.
3. Require a user to log on automatically.
4. Deny the interactive user the right to change his or her own password.

Lesson Summary

Software restriction policies can be applied to a GPO to restrict the applications that can run on a target system. Software restriction policies can restrict applications based on a hash of the executable file, the path in the file system, a certificate associated with the application, or the Internet zone from which the application is running.
You should create security templates for the various computer roles in your organizations, including desktop computers, mobile computers, and kiosks. Whenever possible, you should base these templates on a predefined security template.
Security templates are useful for creating GPOs, but they contain only a subset of the settings available when configuring a GPO. Therefore, after importing a security template into a GPO, you might have to use the Group Policy Object Editor to specify additional settings.
Mobile computers have different security considerations than desktop computers. Mobile computers are subject to a wider array of network attacks because they might connect to unprotected networks. Additionally, they are more likely to be stolen, so encryption of the disk’s physical contents might be necessary.
Kiosks require security settings that are tightly restricted to prevent abuse. GPOs allow an administrator to remove all major user interface elements and configure kiosk computers to log on a user and launch a single application automatically at startup.

< Day Day Up >