The Ultimate Windows Server 1002003 System Administrators Guide [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

The Ultimate Windows Server 1002003 System Administrators Guide [Electronic resources] - نسخه متنی

Robert Williams, Mark Walla

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید



SECURITY POLICY


A security policy is an important element of the overall security of the computer or network being protected. In general, the more security that is applied to a system or network, the more inconvenient the system will be for users.

A security policy, as well as security procedures, helps to define what you are trying to protect and how to protect it. Because of different goals, each type of industry or organization has different security needs. An e-commerce site needs a different security policy from that of an accounting firm or government agency. Before you begin securing your site, it is wise to see if a security policy has been established. If not, develop one.

Most technology decisions should be based on policy. To develop a security policy, take the following guidelines into consideration:


In preparing a risk analysis, ask yourself, what am I trying to protect and from whom?


Determine the probability of risk with a cost/benefit analysis of resource(s) protection.


Determine who is responsible for protecting the resources.


Define how you will respond during a breach of security.



Security policies should not be made in a vacuum, but should be approved and supported by people with authority. To be effective, they should not be too difficult to implement. Once the security policy is in place, procedures and guidelines should be established to ensure that it can be monitored and enforced. The security policy snap-ins discussed later should be configured to meet the security goals and policy of the organizational unit, site, and domain structure; the corresponding procedures that are implemented will affect how users do their work. Larger companies may have compartmentalized security that responds to different needs of various sites, divisions, and departments.

There are some general considerations that will determine how security will be implemented and enforced. This list is by no means all-inclusive but is here to give examples of the questions that should be asked.


Is there an Internet connection, and how can the users use it?


How are disks and information shared?


Is data backed up? If so, which data and how often?


Do the users know their responsibilities?


What are the remote access requirements?


How will you know if security has been compromised?


Is there a firewall in place, and if so, what is permitted to go through it?



Once these questions have been answered, it is necessary to apply them to categories of effort. These questions can be broken down into the following general areas:


Confidentiality.
How will you protect information from being read by unauthorized sources? This includes consideration of technologies such as encryption, file permissions, and network sniffing.


Integrity.
How will you ensure that your data will not be deleted or modified, and, if it is, that you know the source? You must decide how to deal with file permissions, digital signatures, viruses, and programs that are not secure.


Availability.
How will you ensure that your systems remain available? The plan must involve issues like denial of service, acceptable system use, and employment of redundant systems.


Recoverability.
How will you recover if your system has been compromised? You will need to determine the best ways to use data backups, hard copies, and remote data stores.


Audit.
Will you be able to tell if a security breach has happened? Use of log files, system auditing, event monitors, and alarms to guard against abuse must be factored into the plan.



Implementing security can be a full-time job, and monitoring it and maintaining it can require an even larger time commitment. When designing security policies and procedures, it is important to consider the resources that will be necessary to implement, monitor, and enforce them.

Security Policy Snap-Ins


The security tools for Windows Server 2003 do not introduce new conceptual or technological advancements to PKI, group policies, or the Active Directory, but instead offer a convenient and uniform way to distribute these features. The Security Configuration and Analysis and Security Template snap-ins are the two main components of the Microsoft Security Configuration Tool Set. They configure, analyze, and distribute a subset of the Security Settings portion of the Group Policy tree. These settings include:


Account Policies include passwords, system lockouts, and Kerberos policy settings.


Local Policies include user rights and security events.


Event Log permits review of events that could show a compromise of security.


Restricted Groups provide added security for default Windows Server 2003 groups with predefined functions, such as the Administrators group.


System Services manage local system services security.


Registry sets local Registry key data permissions.


File System sets local file system permissions.



NOTEThe Security Template snap-in does not provide a direct means for viewing and modifying public key policies and IP security policies. Rather, these policies must be set or imported from the Default Domain snap-in Windows Settings Security Settings IP Securities Policies on Active Directory or IP Security Policies, respectively.

It's also important to remember that the Local/Remote Computer Policy snap-in includes only the Account Policies and the Local Policies from the above list.

In addition to distributing consistent security configurations, the tools can analyze security settings and graphically display differences between current and intended settings.

USING SECURITY TEMPLATE SNAP-INS


Group policies are used to apply security templates to designated user and computer accounts. Local Computer Policies can also apply security templates, but only local settings and account policies are affected by them. Security templates make the system administrator's job easier by allowing her to create templates that may then be distributed using group policies across a site, domain, organization unit, user group, or even individual users. They are ASCII files whose names have .inf extensions that can be modified with a text editor. All security templates can be found in the %SystemRoot%security\templates\*.inf directory.

CAUTION

It is possible to copy, paste, and otherwise modify the .inf files directly as text files within a tool such as Notepad. However, this is not recommended. The Security Template snap-in should be used to create and modify Windows Server 2003 security templates. Copying part of a template within the Security Templates snap-in and pasting it into another template is less risky. Again, use extreme caution.

The Security Templates snap-in, as seen in Figure 11.1, comes with nine predefined templates. These are divided into a default template and incremental templates.

Figure 11.1. Building a Custom Template


The default template, setup security.inf, is designed to establish a baseline configuration for the system's Security Settings. When Windows Server 2003 is initially installed on a clean NTFS partition, the local computer policy should be similar to the setup security*.inf template. If the system is upgraded from Windows NT 4.0, no security settings are applied; the security settings from the previous environment are not overwritten. The default or setup security*.inf template can be used to set a baseline for the upgraded system or for existing installations to match the suggested settings.

The incremental templates (Table 11.1) are meant to overlay or "apply on top of" the current settings to provide the additional security measures implied by their names.

NOTEThese templates modify Registry values in addition to setting permissions on the local Registry. There is nothing to stop someone with Read/Write permission from modifying the ASCII .inf templates using an editor and changing Registry parameters outside the scope of Security Settings. That is why the templates must be protected from abuse.














































Table 11.1. Incremental Security Templates


Incremental Template


Description


Compatws.inf


Contains the Power Users group without members, which removes all users from that group. The Users group is granted more file system and Registry privileges so that Windows NT 4.0 and other users of earlier systems may run applications on the server.


DC security


Additional security settings applied when a system is promoted to a domain controller.


Rootsec.inf


Sets permissions on the root file system defined by Windows XP. If permissions on the root directory are changed, reapply this template.


Notssid.inf


Removes Terminal Server user SIDs.


Securedc.inf


Imposes stricter Account Policies, Local Policies, and Event Log settings than the default settings. Digital signing and secure channels are requested when possible. Down-level communication with Windows 9x/NT 4.0 Service Pack 4 or higher is possible.


Securews.inf


Same as Securedc.inf except that all users are removed from the Power Users group with the Restricted Groups settings.


Hisecdc.inf


Enables secure channel and digital signing for all communications. Disables NTLM and LM authentication (allows only Kerberos authentication) and all drivers must be signed. All communication is encrypted and authenticated at the highest level possible. Systems configured with this template will not be able to communicate with systems that do not run Windows Server 2003 (Windows 9x/NT 4.0).


Hisecws.inf


Same as Hisecdc.inf except that all users are removed from the Power Users group with the Restricted Groups settings.


Setup security.inf


Saves the original machine configuration after installation.

BUILDING A CUSTOM TEMPLATE


The Security Templates snap-in is handy for viewing template settings, but its true purpose is to create custom templates. There are two methods for building a custom template: An existing template can be selected, modified, and then saved as another template; or a completely new template can be created.

Modifying an Existing Template


Creating a new template by using an existing one involves modifying the existing one and saving it under a different name. To do this, follow these steps:



Open the MMC Security Templates snap-in.

Right-click the desired template and select Save As from the menu.

Enter a new template name and Save.

Open the new template node and modify settings as needed.

Right-click the template node and select Save unless it is dimmed. In this case, it is already saved.


Building a New Template


To create a new security template, take the following steps:



Open the MMC Security Templates snap-in.

Open Security Templates and right-click the templates directory icon.

Select New Template from the menu.

Enter the file name for the template and Open it.

Modify the template settings just as the Security Settings for Group Policy Objects (GPOs) are modified.

Right-click the template node and select Save unless it is dimmed. In this case, it is already saved.


The Security Configuration and Analysis Tool


Analysis of security is a fundamental responsibility of the system administrator. The Security Configuration and Analysis (SCA) snap-in tool is designed to assist in this. Fine-tuning of security is accomplished through regular analysis.

The Security Configuration and Analysis snap-in tool is primarily used to analyze or compare the current computer settings to a personal database and thus view potential discrepancies in the security landscape. It can also be used to configure the local system to match the personal database security settings and to layer templates and produce custom templates for later distribution. All of this is done preferably through a GPO.

Custom security templates are built by layering template upon template to produce security settings. For example, to configure a highly secure domain controller, the basicdc, securedc, and the hisecdc templates would all be applied to the server. Templates can be applied using GPOs, as we saw in the discussion of the Security Settings Extension; or they can be applied with a personal settings database via the Security Configuration and Analysis tool. Importing security templates into GPOs is discussed in Chapter 8, "Group Policies." Note that when GPOs import a template into Security Settings, the enabled settings overwrite previous configurations.

Security templates may be layered to configure high security status, for example, using the Security Configuration and Analysis tool to build a custom template that accumulates all settings from three separate templates. Using GPOs to layer templates and distribute security settings is the method of choice whenever the Active Directory is implemented, but for standalone systems the SCA should be used. The Local Computer Policy snap-in does not allow configuration of the Event Log, Restricted Groups, System Services, Registry, or File System policies.

USING THE SECURITY CONFIGURATION AND ANALYSIS SNAP-IN


There are distinct uses for the SCA snap-in, as its name implies: configuration and analysis. A quick examination of how to use each is appropriate.

Using SCA to Configure Security


Let's demonstrate how the SCA tool can be used to build a highly secure custom template for a domain controller. First, the custom template is created, and then the SCA tool is used to analyze or compare current computer settings with the template settings. Finally, the custom template is used to manually configure the current computer settings. Again, this last step is necessary only on systems without Active Directory support. The following specific steps are invoked:



Add the Security Configuration and Analysis (SCA) tool to a custom console.

Right-click the SCA snap-in and select Open database (Figure 11.2).

Figure 11.2. The Security Template Database

Enter the name Custom High Sec DC.dbd for the database and click Open.

Select the setup security.inf template from the Import Template dialog.

Check the Clear this database before importing and click Open. (Figure 11.3).

Figure 11.3. Import Templates


Repeat steps 1 through 4 for the securedc.inf and hisecdc.inf templates. At this point you have successfully laid three templates on top of each other in an incremental fashion in the Custom High Sec DC database. As a precaution, you must run an analysis on the database before you can export the new template.



Right-click the SCA snap-in and select Analyze Computer Now.

Click OK to the Error log file path dialog box.

Wait as the tool compares the current computer settings with the newly created ones.

Verify the output of the log to make sure that everything is correct.

Right-click the SCA snap-in and select Export Template.

Enter the name Custom High Sec DC.inf for the template name and click Save.

Right-click the %SystemRoot%\Security\Templates node below the Security Templates snap-in and select Refresh. The new template should be displayed among the standard templates.


Under the Security Configuration and Analysis snap-in the Security Settings nodes are displayed. Select the Local Policies Security Options node. In the details pane, the Database Settings are compared to the Computer Settings, as shown in Figure 11.4. Common policy settings are denoted with a green check mark, and conflicting policy settings are denoted with a red X. If either the database policy or the computer setting is not defined, the policy is not marked.

Figure 11.4. Security Options from the SCA Snap-In


To map the current database settings onto the local system:



Right-click the SCA snap-in and select Configure Computer Now.

Click OK to the Error log file path dialog box.

Wait as the tool updates the current computer settings with the database settings.


The local system is now configured with the high security settings. To put the system in its original state, reload the Setup Security template into a database and configure the system with the new database.

Analyzing Security


Security analysis involves several steps. The following should be invoked to conduct analysis:



Open the Security Configuration and Analysis snap-in.

Right-click Security Configuration and Analysis click Open database.

Select an existing database, or create a new personal database by typing in a new file name click Open.

Import one or more security templates by right-clicking Security Configuration and Analysis Open the working database.

Select Import Template.

Select a template file and click Open.

Repeat the last step for every template that is to be merged into the database.

Perform a security analysis by right-clicking Security Configuration and Analysis click Analyze System Now.

Click OK to use the default analysis log.

Review analysis results by right-clicking Security Configuration and Analysis select the security Lockout Policy or Password Policy.

The right pane provides a number of columns, including Attribute for the analysis results, Database Setting for the security value, and Analyzed System Setting for the current security level. If a red X is displayed, inconsistencies exist between the current settings and the base configuration. A green check mark indicates consistency. If no icon appears, that attribute was not set and therefore was not analyzed.

Resolve any discrepancies revealed by analysis by accepting or changing some or all of the values flagged select Configure System Now.

Repeat the import process and load multiple templates.

Once the templates are imported, select Configure System Now.


NOTEThe secedit command can be run from scripts to apply security settings to many computers. It can also be used to force the policy refresh throughout the domain.

NOTESecurity policies are applied with the same inheritance precedence as for any other policy. Windows .NET follows the LSDOU model, in which inheritance order flows as follows: Local Computer (L) Site (S) Domain (D) Organizational Unit (OU).


/ 158