|
|
 |
 |
 |
|
Back to Article List It's Easy to Secure Windows 2000 Servers: Part 3 By Laura Taylor May 3, 2005 In the first two parts of this series, you learned how to use Microsoft's Management Console (MMC) to automatically configure and enforce security policies by creating security templates. You also learned how to create a security template and assign Account Policies, Local Policies, and Event Log security policies to it for a basic Windows 2000 server. In Part 3, I'll teach you how to configure and assign System Services, Registry Settings, and File System Settings security policies. Refreshing Our First Two Lessons Before I show you how to create a different template for specific server types such as a DNS server, a DHCP server, and an Exchange server, we need to finish learning how to configure the remaining policies for a basic Windows 2000 server. By using security templates you can ensure that security policies are automated. Once a template is in place the policies are regenerated and loaded into memory each time a system is re-started. As you'll recall, to get to the screen where you do the actual policy configuration, you first need to start up the Microsoft Management Console. You can do this from the Start menu by opening up the Run box and typing MMC as shown below.
Starting the MMC. After you add the Security Template snap-in (explained in Part 1 of this series), you need to select the template called basicsv, and then open the System Services configuration window as illustrated below.
The System Services Configuration Window. You are now ready to configure and assign System Services settings. The System Services settings allow you to stipulate which services get launched on startup. You can configure the System Services in the same method you configured the Local Policy settings and the Event Log settings. Configuring and Assigning System Services Security Policies The System Services settings should be unique to your organization, and should be a topic of discussion among the systems administrators before you configure them. Keeping that in mind, Table 1 shows an example list of System Service settings designed for a typical, client-server enterprise architecture. Your organization may actually have more services installed on its servers than the ones listed in Table 1. When you install a new server application it usually adds new services to Systems Services list. The applications that you have running on your server will determine what applications show up in the System Services setting list. The list on your server is likely to be slightly different than the list in Table 1. You will also notice that your Windows 2000 services, as well as your application services, are both mixed together in this list and are listed in alphabetical order. When configure System Settings, you will want to give the Administrators group full control. To configure the System settings on a group-by-group basis, you need to double-click on the Service name, and then click the Edit Security button as shown in below. You will then see the Allow/Deny security settings by group.
Configuring Security Policy Settings. In most cases, the group known as Authenticated Users should never have Full Control and their settings for most applications should be set to more restrictive settings such as Read access as shown below.
Authenticated Users Have Limited Control. You will need to step through this process for each and every application and each and every group. It is important that you know what you are doing when you apply these configuration controls. If you are unsure, leave the default settings in place.
To define the access control, ownership, and audit settings on your Windows 2000 server you need to configure the Registry security settings. There are three types of Registry keys you can configure: the CLASSES_ROOT keys, the MACHINE keys, and the USERS keys. To configure the Registry security settings, from the Console window shown in Figure 2, right-click on the Registry folder and select Add Key as shown below.
Adding Registry Keys for Configuration. You'll then be prompted to select a particular type of key to configure as shown below.
Selecting a Type of Registry Key to Configure. When you configure the security settings for your server's Registry keys, you should be sure that the box called Allow inheritable permissions from parent to propagate to child is not checked. You will then need to decide whether to Propagate the inheritable permission or Replace the existing permission for each key. In most cases you will want to elect to Replace the existing permission so that the inheritable permission is not propagated. An example of three Registry key settings is shown in Table 2. Note that for the Registry key settings, you will always want to give the Administrator group Full Control and the SYSTEM group Full Control.
To determine File System settings, select the File System folder in the Console window as illustrated below.
Configuring Security File System Settings. You can then double-click on each of the File System Object Names to configure the setting. Like with the Registry keys, you will have the option of selecting Propagate Inheritable Permissions or Replace Existing Permissions. The groups Administrator, SYSTEM, and Creator Owner should always be given Full Control. You will want to be more restrictive to Authenticated Users and other user groups and will need to understand which users need to access what files before you implement these settings. You should either remove the Everyone group, or else Deny all file permissions to this group. You want to know who is using what resources, and requiring all users to be Authenticated will enable you to know that.
Before Implementation You should research, write down, and determine all of your security settings in advance before you actually perform the configuration on a production server. Determining the correct settings will involve understanding the applications, the operating system, and user behavior patterns. This is a job for a Senior Systems Administrator. You should then circulate the documented settings to the Administrators on your staff, and your security team within your organization for review before implementing them. You should test them in a lab before implementing them on a production server. Finally, the IT Director or Security Officer should sign-off on all settings before implementation. By tightening up your security settings, you can greatly reduce the risk of intrusion or unauthorized use.
Read Part 4 of our series on securing Windows 2000 Servers here.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
| Copyright 1997-2023 Relevant Technologies. All rights reserved | Legal and Privacy | Sitemap Email: info@relevanttechnologies.com | 8115 Maple Lawn Blvd, Suite 350, Fulton, MD 20759 |
