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.
Check C2 Compliance
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 system should not dual boot. Windows NT should be the only operating system installed.
The OS/2 and POSIX subsystems should not be installed.
All drives on the system must be formatted for the NT File System, not the FAT file system. To check drive status in Windows NT 4.0, right-click on the drive and choose Properties.
The Security Log should not overwrite old events. To check this, open the Event Viewer and choose Log Settings from the Log menu. The option called "Do Not Overwrite Events (Clear Log Manually)" should be enabled.
Do not allow blank passwords. To check this, open the User Manager for Domains and choose Account from the Policies menu and disable Permit Blank Passwords in the Minimum Password Length field. This will require that you choose the "At Least x Characters" field and specify a value for x.
Disable the Guest account. In the User Manager, double-click on the Guest account and put a check mark on the item called "Account Disabled."
Standard Evaluation
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
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.
Maximum Password Age
Password should expire in x number of days.
Minimum Password Length
Password should be greater than eight characters.
Minimum Password Age
Set to allow changes in x number of days.
Password Uniqueness
Set to Remember x Passwords.
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:
Lockout after x bad logon attempts
Set x to 4.
Reset Count After x minutes
Set to approximately 20 minutes to avoid unnecessary lockouts.
Lockout Duration field
Set according to your logon policies. If forever is set, an administrator must restore the account.
Forcibly disconnect remote users from server when logon hours expire
Set this option to prevent after-hours activities or disconnect systems that were left on
User must log on in order to change password
Set this option to prevent users whose passwords have expired from logging on. The administrator must change the password.
User Accounts
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:
Look for old user accounts of employees who have left the company and remove the accounts if appropriate.
Check the password options. Should the user be able to change the password? Does the password never expire? Is this account disabled? If it is disabled, has the user left the company? If so, consider removing the account.
Click the Groups button to determine which groups the user belongs to. Is membership in these groups appropriate for the user? What rights and permissions does the user obtain from the groups? What access does the group have to other domains?
Click the Profile button in the New User properties dialog box to check the location of the user's home directory. If you remove the account, also remove the specified directory. Does the user have a profile, and if so, is it mandatory? Are System Policies required?
Click the Hours button to evaluate the times that the user can access the network. Make sure no one can log on after hours if that is your policy.
Click the Logon To button to evaluate which computers the user can log on to. Make sure that no one can log on from a computer in an unsupervised area.
Click the Account button to set an account expiration date if necessary. All temporary accounts or administrator "test" accounts should expire automatically.
Click the Dialin button to evaluate dial-in capabilities. If users can dial in, enable Call Back options to a specified telephone number in the dialog box for added security.
Groups
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.
Are any of the accounts in a group inactive? If so, consider removing the accounts.
Carefully evaluate the members of management groups such as Administrators, Server Operators, Account Operators, Backup Operators, and Print Operators. Remove all unnecessary accounts.
Make sure that all administrative users have two accounts: one for administrative tasks and one for regular use. Administrators should only use their administrative accounts when absolutely necessary.
Evaluate each global group membership and the resources that the group has access to. Does the group have access in other domains?
What folders and files do groups have permission to access? This can be difficult to evaluate. Use a program like Somarsoft DumpACL to help you with this task.
Do local groups hold global groups from other domains? Check the membership of these global groups and make sure that no users have unnecessary access to resources in the current domain.
The Administrator Account and Administrators Group
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:
If you are taking over the management of an existing system, you should change the Administrator account name and password immediately. You do not know who might have a password that would give them access to the account.
The Administrator account is often the target of attacks because of its well-known name. You should rename the Administrator account to an obscure name and create a "decoy" account called "Administrator" with no permissions. Intruders will attempt to break in to this decoy account instead of the real account.
Enable failed logons in the auditing system to detect attempts to log on to any account, including Administrator.
Look for unnecessary accounts that have Administrator status. Perhaps an intruder has created such an account as a backdoor into the system.
Review the membership of the Administrators group and the Domain Admins group. Remove all unnecessary users from this group.
If you have a large network that consists of multiple administrators, interview these administrators on a regular basis to evaluate their activities and need for Administrator status.
To protect against the loss of the Administrator, create a "backdoor" Administrator account with an obscure name and a three-part password. Give three people one part of this password. In the event that Administrator access is required, all three must be present to access 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.
The Guest Account and Everyone Group
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:
Users who log on as guests can access any shared folder that the Everyone group has access to (i.e., if the Everyone group has Read permissions to the Private folder, guests can access it with Read permissions).
You don't know who Guest users are and there is no accountability because all guests log in to the same account.
Always disable the Guest account on networks that are connected to untrusted networks such as the Internet. It provides too many opportunities for break-ins.
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.
User Rights
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:
Access this computer from the network
By default, only the Administrators and the Everyone group have this right. Remove the Everyone group (why would you want everyone to access this server from the network if you are interested in security?), then add specific groups as appropriate. For example, create a new group called "Network Users" with this right, then add users who should have network access.
Backup files and directories
User's with this right can potentially carry any files off-site. Carefully evaluate which users and groups have this right. Also evaluate the Restore files and directories right.
Log on locally
For servers, only administrators should have this right. No regular user ever needs to logon directly to the server itself. By default, the administrative groups (Administrators, Server Manager, etc.) have this right. Make sure that any user who is a member of these groups has a separate management account.
Manage auditing and security logs
Only the Administrators group should have this right.
Take ownership of files or other objects
Only the Administrators group should have this right.
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.
Files, Folders, Permissions and Shares
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:
Check each folder and/or file to determine which local users and groups have access and whether that access is appropriate.
Check all shared folders and the share permissions on those folders to determine which network users and groups have access and whether that access is appropriate.
Program files and data files should be kept in separate folders to make management and permission setting easier. Also, if users can copy files into a data folder, remove the Execute permission on the folder to prevent someone from copying and executing a virus or Trojan Horse program.
Separate public files from private files so you can apply different permission sets.
If users or groups have access to a folder, should they have the same access to every file in the folder? To every subdirectory? Check the sensitivity of files and attached subdirectories to evaluate whether inherited permissions are appropriate.
Keep in mind that the Everyone group gets Full access by default for all new folders you create. To prevent this, change the Everyone group's permission for a folder, then any new subdirectories you create will get the new permission settings.
If the server is connected to an untrusted network such as the Internet, do not store any files on the server that are sensitive and for in-house access only.
Never share the root directory of a drive or one of the drive icons that appears in the graphical display. An exception would be sharing a Read Only CD-ROM drive for public access.
For sensitive, password protected directories, enable Auditing. Right-click a folder, click Security, then click Auditing and enable Failure to track users that are attempting unauthorized access a folder or file. Note that File and Object access must be enabled from the Audit Policies menu in the User Manager, as described later.
Use encryption wherever possible to hide and protect files. Mergent (www.mergent.com) and RSA Data Systems (www.rsa.com) provide encryption software for this purpose.
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.
Virus and Trojan Horse Controls
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:
Program directories should have permissions set to Read and Execute (not Write) to prevent a virus from being written into a directory where it can be executed. To install programs, temporarily set Write on, then remove it.
Install new software on a separate, quarantined system for a test period, then install the software on working systems once you have determined that it is safe to run.
Public file sharing directories should have the least permissions possible, i.e., Read Only, to prevent virus infections.
If a user needs to put files on your server, create a "drop box" directory that has only the Write permission. Check all new files placed in this directory with a virus scanner. Implement backup policies and other protective measures.
Educate and train users.
Check the Symantec (www.symantec.com) site for interesting papers on Windows NT-specific virus issues.
Auditing and Event Logs
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 Tolerance, Backup, and UPS
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.
In Disk Manager, make sure disk mirroring or duplexing is taking place to protect against failed drives or hardware components.
Check to make sure an uninterruptible power supply (UPS) is installed and configured properly. The UPS will protect data on a server that fails from a power loss. To check the UPS, open the UPS utility on the Control Panel.
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.
Review the backup policies. Is the backup schedule appropriate? Are files safely transported to secure backup locations? How might backup compromise the confidentiality of files?
