Security Issues and Solutions Part 2 - System Lockdown in Windows 2000
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In the next two articles in this series on security issues, we will examine issues and administrative recommendations associated with computer system lockdown. This series of articles examines various aspects of security threats, and the text is extracted from our book The Ultimate Windows 2000 System Administrator's Guide (Addison Wesley, 2000). Although some of the text is focused on Microsoft enterprise environments, the principles broadly address other operating system environments.
Securing the Windows 2000 system involves concentrating on a number of potential problem areas. These issues, which are internal to the enterprise and well within the scope of system administrator responsibility, include the following (some of these topics are covered in subsequent articles):
- User account security
- Proper password management
- Registry and file system lockdown
- Protection of network shares
- Trojan horses and virus control
- Environmental settings
- Removal of services that are not required
- RAS security
- Backup and restoration
- Physical security lockdown
- Dual-booting of multiple operating systems
User Account Security
A hacker's primary method of gaining unauthorized access is through user accounts. The system administrator is directly responsible for maintaining user account accountability and securing the enterprise against improper account usage.
Administrator Account
Providing an unauthorized user access to the Administrator account in Windows 2000 is comparable to giving away the keys to the castle. The Administrator account cannot be removed or locked out. Moreover, it permits an unlimited amount of logon attempts, so multiple logons cannot be used to intentionally deny the administrator access. Lastly, it allows a cracker plenty of opportunities to figure out the administrator's password. There are a number of precautions that can be implemented as a minimum safeguard against assaults, described in the following paragraphs.
The Administrator account should always be associated with a cryptic password that is generally too complicated to be remembered easily. This password should not be confused with the one used by the system administrator who belongs to the Administrators group. The use of the primary Administrator account logon should be limited to extreme situations. System administrators should always log on under their own account. As members of respective Administrators groups, they will be able to conduct appropriate support activity under that login. In theory, a hacker knows that there is always an Administrator account, but he or she is less likely to know the login name of individual members of the Administrators group.
Alternately, create a new account and add it to the Domain Admins global group. Only highly trusted system administrators should know its name and password. This account should be used for administrative duties. If each highly trusted administrator has her own account, a rogue administrator account can lock out the other accounts. However, an audit trail will more easily track individual patterns.
What makes a good password? It is easier to define a bad one. That would be your name or anyone's name, any word in the dictionary, your license plate, your phone number, or your social security number—all of which can be guessed by social engineering or can be quickly discovered via a cracking program. An example of a good password is a nonsense phrase—for example, "I like to sip soda in my sneakers." Use the first character of each word, mix some letters with numbers, and add punctuation. It now becomes Il2ss!mS, which is not too hard to remember and very difficult to guess or crack. (Of course, this particular password is now bad because it has been published.)
The Domain Administrator account password should be written down and physically protected in a safe place, under lock and key. Again, it should be employed for emergency system restoration, not daily use. This password will be replicated to all domain controllers. It can also be retrieved if the administrator is unavailable or incapacitated for some reason.
The same strategy should be implemented for all local Administrator accounts as well. A different cryptic password should be assigned to all local Administrator accounts for a site, and written down and stored in a safe place. If the physical security of one workstation is compromised, there is a chance that the Local Administrator password can be recovered from the file system. The Domain Administrator account should remain protected.
NOTE
The suggestion to write down the Administrator account password and store it in a safe place is contrary to what a system administrator should tell a normal user. It is based on the assumption that the administrator will exercise extreme caution in securing it. However, a user should never write down his password because it is simply too easy for someone to "eye" it in a normal work environment. Instead, because it will be used on a regular basis, the user should be required to mentally retain it. If the password is forgotten for some reason, the system administrator can reset it with little effort. As an added precaution, place the Administrator password in a sealed envelope. If the seal is broken, immediately change the password, and reseal the envelope.
Backup Operators
By default, the Default Domain Controllers Policy GPO gives both the Administrators and Backup Operators groups the right to back up and restore files and directories. This means that the Backup Operators can overwrite the file system, regardless of assigned permissions. Two actions can be taken to minimize this problem:
Use the Backup Operators group sparingly, and assign only the most trusted persons to it.
Remove these user right policies on all systems that do not require domain-level backup privileges.
Guest Account
The Guest account has significantly changed between Windows NT and Windows 2000. In Windows NT, it was a convenience to support Web servers and other applications that must run without user authentication. Thus, it had access to all objects with permissions assigned to the Everyone group. As a result, directories such as %SystemRoot%System32 were wide open to destruction from it. Windows 2000 has created a new built-in local group known as Authenticated Users, which is responsible for assigning permissions to users who previously belonged to Everyone. The Everyone group is specifically assigned to most objects with no permissions whatsoever. This has the effect of restricting Guest account privileges. To avoid the problems inherent in the Windows NT Guest account, use the Everyone group, which is disabled by default, very sparingly.