Steps for Evaluating the Security of a Windows NT® Installation
By Tom Sheldon
Updated November 1, 1996
This material is based on Appendix E in the Windows NT Security Handbook by Tom Sheldon, published by Osborne-McGraw-Hill, October 1996.
What do you do when you face the task of evaluating the security of a Windows NT system? One approach is to obtain a package such as the Kane Security Analyst (KSA). Check the Intrusion Detection System's Web site at www.intrusion.com or check the Somarsoft site at www.somarsoft.com. Another approach is to manually evaluate the security of a system. Although this can be a daunting task, you will find it a little easier if you follow the steps provided here. This discussion provides quick steps for analyzing the security of a server.
For more specific details about security auditing, refer to the Microsoft Press publication "Windows NT 3.5, Guidelines for Security, Audit, and Control," a joint research project by Citibank N.A., Coopers & Lybrand, The Institute of Internal Auditors, and Microsoft Corporation (1994)
NOTE: The descriptions for accessing the user interface in this paper relate to the Windows NT 4.0.
C2 compliance relates to stand-alone system security, rather than network security, but it can help you evaluate the strength of a system. Technically, a C2-compliant workstation cannot be hooked into a network; if you are creating these settings on a server you can never be C2-compliant. However, the following settings can serve as the basis for building a very secure system even if they don't necessarily apply to a network server.
The steps in this section outline the security settings you check for standard evaluation of a Windows NT system. Many of the settings are checked in the User Manager. Keep in mind that these recommendations may or may not be appropriate for your environment. One of the first things to check are the logon policies and restrictions--the "welcome mat" into the Windows NT Server. Are your users educated about password safety and appropriate use of the system? Do users read and sign a security policy? You should post legal notices in Logon dialog boxes to indicate that only authorized users may access the system and that all activities may be monitored.
TIP: You can create a batch file that runs a variety of NET commands to produce a security evaluation report for a server. See Chapter 10 in the Windows NT Security Handbook for an example.
Account policies and restrictions determine how password and logon policies are enforced for the entire domain. Keep in mind that each domain has its own policies. Open the User Manager and choose Account from the Policies menu. If you want to check a different trusting domain, choose Select Domain on the user menu. When the Account Policy dialog box appears, evaluate and choose the following settings under Password Restrictions based on your password policies.
Enable the Account Lockout option to prevent unauthorized users from attempting to access the system by guessing passwords. For optimum security, never run the server with this option disabled. Set the following options as appropriate:
After setting the domain account policies, check the status of each user account and group in the User Manager. This can be a tedious process if you have hundreds of accounts, so consider using the utilities such as the Kane Security Analyst or the Somarsoft utilities. Double-click on each account if you are checking manually. This opens the New User properties dialog box which displays password information and has buttons for checking group membership and other options. Check these options as follows:
The membership of groups should be carefully evaluated. A group that is granted permissions to sensitive files might contain users that should not have that access. Open each group listed in the User Manager and inspect its members.
The Administrator account and Administrators group have unlimited rights on the system. Therefore, you need to carefully evaluate the membership of the Administrators group and take care of some other housekeeping related to the Administrator account:
The Administrators group has "Access this computer from network" right, which you can block to prevent account hijacking or unauthorized activities. Without this right, administrators must log on at the computer itself in a controlled environment to do any administrative tasks. You will also need to remove the right from the Everyone group then add back in accounts that are allowed to log on from network.
When a Windows NT Workstation computer is added to a domain, the Domain Admins group is added to the workstation's Administrators group. This gives any member of the Domain Admins group access to the workstation computer as well. Determine whether this is appropriate. You may need to remove the Domain Admins group at the workstation and add only a specific Administrator account.
Evaluate the need for the Guest account. Most administrators agree that it should be disabled, although removing it remove the ability of anonymous users to access a system. In some organizations, the Guest account is very useful. For example, people who don't normally work with computers might need to occasionally access a system to obtain some information. Factory floor workers might want to look up pension plan information on a kiosk system in the break room. This is a good use for the Guest account. However, consider creating a separate domain for these public services where the Guest account is enabled. Alternatively, use a Web server for this type of system.
Note the following:
NOTE: If you have Microsoft Internet Information Server software installed, a special Guest account called IUSR_computername exists with the rights to log on locally. Remove this account if you don't want the general public to access your Web server. Users must then have an account to access the Web server.
In the User Manager for Domains, check the rights that users and groups have on the system. Choose User Rights from the Policies menu to display the User Rights Policy dialog box. Initially, the box shows the basic rights. To evaluate all rights, click the Show Advanced User Rights option. Here are some considerations for basic rights:
Scan all the advanced rights to make sure that a user has not been granted rights inappropriately. Some rights should only be assigned to the System account. A rogue administrator might manage to grant himself inappropriate rights and gain extended privileges on the system.
This discussion assumes that you are only using NTFS volumes on your servers. Do not use FAT volumes in secure installations.
To check permissions on folders and other resources, you must go to each resource individually to review which users and groups have permissions. This can be a bewildering task, so for large systems obtain a copy of the Somarsoft DumpACL utility.
To open the Permissions dialog box for a folder or file, right-click it and choose Properties, then click either the Sharing or the Security tab. The Sharing options show who has access to the folder over the network. The Security tab has the Permission and Auditing buttons so you can check local permissions or set auditing options.
Start your evaluation with the most sensitive and critical folders if you are doing this procedure manually or performing a periodic checkup. Take care to do the following:
You can remove Everyone's access to an entire folder tree by going to the root of the drive, changing the permissions, and propagating those permissions to subdirectories. Do not do this for the systemroot folder (usually C:\WINNT). You must manually update Everyone's right there.
Viruses are a particularly serious problem in the network environment because the client computer can become infected, transferring the virus to server systems. Other users may come into contact with infected files at the server. Evaluate and set the following options:
Check the status of audit settings by choosing Audit on the Policies menu in the User Manager for Domains. The Audit Policy dialog box appears. The settings in this box reflect the minimum settings that are appropriate for auditing in most environments. Keep in mind that auditing too many events can affect a system's performance.
Protect auditing and security logs from other administrators who might change or delete them. You can grant only the Administrators group the ability to access the logs. To restrict access to only one user (the "auditor"), remove all users except the auditor from the Administrators group. This means all of your other administrators should be members of a management group that does not have the "Manage auditing and security log" right.
Check for failed logons in the Event Viewer. You can enable security auditing for logon attempts, file and object access, use of user rights, account manage- ment, security policy changes, restart and shutdown, and process tracking.
Fault-tolerant systems duplicate various hardware components and process to guard against failures. Evaluate all fault-tolerant systems for proper installation and operation. Use the Disk Administrator utility (on the Start|Programs menu) to check disk systems and use the UPS utility (on the Control Panel) to check the status of uninterruptible power supplies.
Backup policies and procedures are essential. In your evaluation, determine which users belong to the Backup Operators group. Carefully evaluate if you trust these users. Backup operators have the ability to access all areas of the system to back up and restore files.
Members of the Backup Operators group should have special logon accounts (not regular user accounts) on which you can set logon restrictions. If Joe is the backup operator, he should have a regular logon account for his personal activities and a special logon account for backing up the system. Set restrictions on the backup account, then set restrictions that force Joe to log on from a specific system only during appropriate hours. Change, with frequency, the name and password of the account to guard against hijacking.
Email: [email protected]
All material Copyright © 1996, 2001 [Big Sur Multimedia, Inc]. All rights reserved. Information in this document is subject to change without notice. Other products and companies referred to herein are trademarks or registered trademarks of their respective companies or mark holders.