Windows NT Server Operating System Security Features Carol A. Siegel Payoff

Transcription

1 Windows NT Server Operating System Security Features Carol A. Siegel Payoff This article is designed to provide security administrators with a security checklist for going live with Windows NT. Each of the basic security and audit features of the Windows NT operating system is explained, and recommended values for these features are suggested. The security administrator can use these values to create a security baseline when the operating system is initially configured. Introduction The Windows NT operating system offers substantial security and audit features that have earned it the C2 evaluation for auditing and authentication from the National Computer Security Center (NCSC). The features described in this article should be implemented according to the policies and standards of the organization. Windows NT uses a client/server architecture in which clients and servers are grouped together to form domains. Each domain contains one or more servers, shares common data bases and security policies, and has a unique name. How the domains interact should be determined before the operating system is installed. The trust relationships between these domains must be based on the business needs of the organization in conjunction with its security policies. Creating the Security Access Token The interactive log-on process is unique to Windows NT and offers certain built-in security controls. In order to log on, the user has to press three keys simultaneously: Ctrl + Alt + Del. By requiring this particular key combination, the operating system terminates any background process, thus preventing any Trojan horse program (e.g., a password grabber) from executing. After these keys are correctly pressed, a valid user log-on is requested. The user must enter a user name and password. The security subsystem passes this input to the Security Account Manager, thereby identifying and authenticating the user. security account manager (SAM) compares this information to a security data base that contains the individual user profile. After it is authenticated, this profile is downloaded from the server and a security access token is created for that user. This access token is then passed to the Win32 subsystem and the log-on is now complete. The access token is an object that contains such specific information as the user security ID (SID), which uniquely identifies the user, the group security IDs, which are the group SIDs of which a user is a member, and the privileges assigned to the user. It is this access token that is used to determine whether or not a user is permitted to access an object. Implementing User Security User security is established through the Policies menu in User Manager. The two policies in this menu are account policy and user rights policy. Account policy is a global policy and is applicable to all users in the specified domain (as shown in Exhibit 1).

2 Account Policy Dialog Box The account policy comes with certain default settings. Exhibit 2 indicates the default settings and the suggested values. Account Policy Default Settings and Suggested Values ACCOUNT POLICY DEFAULT RECOMMENDED VALUE VALUE Passport expires in X days 30 Days 30, 60* Days Passport change permitted after X days 14 days 7 days Minimum password length 6 characters 8 characters Password uniqueness-prohibit users from reusing last passwords 3 passwords 5 passwords Account lockout after n bad login attempts 5 attempts 3 attempts Reset the lockout count after n minutes 20 minutes 120 minutes Account lockout for n minutes 60 minutes 120 minutes Disconnect remote users Do not disconnect Disconnect** when log-on hours expire User must log on to change password Log-on required Log-on required NOTES: * This means 30 days for privileged users, 60 days for non privileged users ** Disconnecting will terminate any background processes as well. The user rights policy defines what rights are granted to each system user or group of users. A right is an authorization for a user to perform a certain action on the system. These rights may affect systemwide resources, and they should be assigned with care. Exhibit 3 illustrates how rights are assigned. Exhibit 4 shows the user rights that can be assigned. User Rights Policy Dialog Box User Rights

3 RIGHT* Access this computer from network Back up files and directories Change the system time. PERMITS A USER: Connect over the network to a computer. Back up files and directories. This right overrides file and directory permissions. Set the time of the internal clock. Force shutdown from a remote system Not currently implemented. Log on locally Manage auditing and security log Restore files and directories Shut down the system Take ownership of files or other objects Local log-on Specify what types of events and resource access are to be audited; view and clear the security log. Restore files and directories; overrides file and directory permissions Shut down Windows NT server. Assume ownership of files, directories, and other objects in the system. Note: * There are an additional 18 advanced rights. These are listed in the Windows NT Resource Kit, Microsoft Press. In addition to rights that may be assigned to individual users or groups, each user or group of users can have a profile which may be defined in the User Properties screen, accessible through User Manager for Domains. Exhibit 5 indicates the default values of the User Properties menu and suggested values. In addition to the User Properties that can be selected, buttons can specify what groups a user belongs to, specific user log-on scripts, the hours in which the user is permitted to log on, what individual workstations the user is permitted to use, and the expiration date of the account. These features should also be used in conjunction with the overall security policies of the organization. Default Values of the User Properties Menu

4 USER PROPERTIES DEFAULT VALUE RECOMMENDED VALUE User must change Selected for Select for new accounts password at next log-on new accounts or password changes User cannot change Not selected for Not selected, except for his password all accounts GUEST account except GUEST accounts Password never expires Not selected Not selected* Account disabled Not selected Selected for GUEST account. Selected by the security administrator for various reasons NOTE: *This may be selected on a case-by-case basis. For example, if a group of accounts were required to change their passwords on a specific day for a legitimate business reason, this feature could be used in conjunction with a manually forced password change by the security administrator for each member of the group. Group Security Concerns Local and global are the two types of groups. Local groups are defined on a node-by-node basis. They may be composed of both user accounts and global groups. In general, they set groupwide access permissions to resources on a local domain. Global groups are defined at the domain level. They set groupwide access permissions across multiple domains. Both local and global groups are created through User Manager for Domains. Individual members can then be added to each group. In addition, built-in local groups (e.g., administrators, users, guests, everyone, backup operators, server operators, account operators, and print operators) come with the operating system. These groups have preassigned rights, built-in abilities, and members, but they can be assigned additional members. Exhibit 6indicates the rights of the built-in groups. The rights assigned to these groups are alterable, the built-in abilities are not. Rights and Built-in Abilities for Default Local Groups Valid uses for local groups include the following: They can be used only in the domain in which they were created. They can be used to give access to users for objects in one domain only. They can be composed of global groups and individual users. They can include users from multiple domains. Valid uses for global groups include the following: They can be used to group individual users of a domain together.

5 They can be included in local groups, and by this inclusion they can be assigned rights or permissions to resources. They cannot contain local groups. They cannot contain other global groups. In general, local groups should be used as a way of setting groupwide access permissions on resources on the local domain, whereas global groups should be used as a way of setting groupwide access permissions across multiple domains. Directory and File Permissions File and directory permissions and their ownership determine the manner in which they can be accessed. File permissions are set through File Manager by first selecting a file, then selecting thepermissions command from the Security menu. This will display the name of the file, its owner, and a list of users or groups and their corresponding access to the file. These users or groups can be added or deleted, or their access can be changed. Special access can be granted to files according to the chart in Exhibit 7. Special Access Permissions and the Associated Actions Directory permissions are set through File Manager by selecting a directory, and then selecting the Permissionscommand from the Security menu. Here users and groups can be granted permissions. Special permissions on directories and some or all files in those directories can also be assigned according to the chart in Exhibit 8. Special Access permissions and the Associated Actions In terms of ownership, the creator of the file or directory is the owner by default. The owner of the file can, however, grant ownership to another user by either changing its permissions or selecting Owner from the Security menu in File Manager and selecting the Take Ownership button. The target user can only take ownership if that ability has been granted. The administrator can, of course, take ownership at any time. Permissions on shared files or directories can be defined through the Disk menu in File Manager. Through New Share, users or groups can be given access to shared files or directories and their permissions can be specified. However, permissions applied to directories include all subdirectories and their files. Auditing Features Windows NT auditing features can record events to show what users access what object, what type of access is being attempted, and whether or not the access attempt was successful. Windows NT provides auditing at the system-event level and at the object level. Auditing at the system-event level can be set by selecting Audit Policy under User Manager. Any user holding the Manage Auditing and Security Log right can set auditing at this level. Selecting User Manager or User Manager for Domains, choosing theaudit command from the Policies menu, and selecting the Audit These Events option turns on auditing. If the Do Not Audit option is highlighted, all auditing is completely turned off. This is the default

6 setting, but it is not recommended in any circumstance. If Do Not Audit is selected, system level auditing and file and directory auditing are both turned off. When selecting audit events, all events should be turned on for both successes and failures (or according to company policy). However, the Log on and Log off option may cause a significant number of Log entries, depending on the number of user accounts and frequency of log-ons. Other areas that can be audited are: Directories and files. Registry changes. Printer use. User activity for Remote Access Servers. Clipbook page use. All auditing is turned off by default. Therefore, for directory and file auditing to occur, file and object access must be turned on as part of the Audit Policy screen under User Manager or User Manager for Domains. Then for each directory or file, specific users or groups must be defined. Security events can be viewed through the Event Viewer by selecting Security from the Log menu. For domains, all auditable events are written to the security log on the domain controller and refer to events that occur on the controller and all servers in the domain. Security Event Logging Windows NT has a security log that records valid and invalid log-on attempts and events related to resource such use as creating, opening, or deleting files or other objects. System administrators or users with the manage auditing and security log right can view the security log events in the Event Viewer by selecting Security from the Log menu. By double clicking on any one event, a more detailed breakdown of that event can be displayed for analysis. The security log is protected by an Audit Command Language that restricts access to all but the administrator. The security log[systemroot]\system32\config\secevent.evtmust be secured using NT file system so that the audit command language (ACL) can be used. The security log contains a header and version number that is placed at the beginning of each log file. This header can be used to ensure that the file being read or written to is a valid log file. The Event Log service validates an existing file before writing events to it, and it uses the Alert feature to alert the administrator if the file is not a valid event log file. When a log file gets full (e.g., the next record to be overwritten is within the retention period), an Alert is sent to the administrator, and the record is not written to the log. By selecting Log Settings from the Log menu, the system administrator can specify certain Event Log parameters relating to its size and event recording. Security Alert Messages As a special feature of the Windows NT operating system, it has the capability to send an alert message to a designated individual who can report on security related events (e.g., too many log-on violations)as they occur. Performance Monitor's Alert View can be used together with network alerts to send an alert for any of the counters in performance monitor. The user must first specify to whom the alert goes in network alerts then turn on

7 and specify the recipient of the message in Send Network Message in Alert Options. An alert message is sent to the designated receiver, and the results can be viewed in Performance Monitor's Alert View. Log recording starts at boot time. By default, the maximum log size is 512K bytes per log, but this number can be set in accordance with disk and memory capacities. An administrator cannot, however, set the log for a smaller size than the size of the present log; the log must be cleared first. There are three choices for Event Log Wrapping: Overwrite Events as Needed (the default). Overwrite Events Older Than X Days. Do Not Overwrite Events (Clear Log Manually). It is recommended that your system be benchmarked to determine the optimal maximum log size. This is a balance between storage constraints, the amount of auditing being done, and archiving strategies. The Do Not Overwrite Events (Clear Log Manually) option should be selected so that events are not lost. When the log is full an alert message is displayed to the system administrator. Prohibited Access Message Creation Through the string editor in the registry, the security administrator can create a message that is displayed to users after the Ctrl + Alt + Del keys are pressed at log-on time. This message appears in a dialog box and requires that the return key be pressed to continue. The text of this message should state the following: THESE COMPUTER SYSTEMS ARE PRIVATE. UNAUTHORIZED ACCESS IS PROHIBITED. VIOLATORS WILL BE PROSECUTED. To create this message, the registry editor should be accessed and the following subkey selected: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindonwsNT\CurrentVersion\Winlogon To change the caption on the dialog box, double-click on the following: LegalNoticeCaption : REG_SZ : To change the text of the message, double-click on the following: LegalNoticeText : REG_SZ : Conclusion Before the security practitioner goes live with the Windows NT system, certain decisions regarding security should be made. Areas that should be addressed by the practitioner include: Account policy. Password controls. Account lockout controls. Log-on restrictions.

8 User rights policy. Previous screen Assignment to users. Assignment to groups. Create user properties. Create user profiles and restrictions. Groups. Create overall group architecture. Create local groups and assign users. Create global groups and assign users. Assign global groups to local groups. Directories and files. Set permissions on selected directories and files. Set ownership on selected directories and files. Create shared directories and files. Auditing. Turn on systemwide auditing. Select items to be audited. Consider auditing for other areas. Security event log. Set log parameters. Configure alert messages. Unauthorized access. Change legal notice caption. Change legal notice text. Author Biographies Carol A. Siegel Carol Siegel is vice-president and director of information security for Chemical Bank Global IRM in New York.

9

10