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

WINDOWS SERVER 2003 SYSTEM LOCKDOWN

Securing the Windows Server 2003 system involves concentrating on a number of possible problem areas. These issues, which are internal to the enterprise and well within the scope of the system administrator's responsibility, include the following:

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. The three user accounts that might be the most vulnerable are Administrator, Backup Operators, and Guest.

THE ADMINISTRATOR ACCOUNT

Providing an unauthorized user access to the Administrator account is comparable to giving away the keys to the castle. The Administrator account cannot be removed or locked out. Moreover, it permits an unlimited number of logon attempts so that multiple logons cannot be used to automatically deny the administrator access. Last, it allows a cracker plenty of opportunities to figure out the administrator's password. A number of precautions that can be implemented as a minimum safeguard against assaults are 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 accounts. As members of respective Administrators groups, they will be able to conduct appropriate support activity under that logon. In theory, a hacker knows that there is always an Administrator account, but he or she is less likely to know the logon names of individual members of the Administrators group.

Alternatively, 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 phrasefor 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, since 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 each local Administrator account 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 the Local Administrator password can be recovered from the file system. The Domain Administrator account should remain protected.

NOTEThe 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, since it will be used on a regular basis, the user should be required to retain it mentally. If for some reason the password is forgotten, 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.

NOTEPasswords are used to generate a cryptographic key known as a hash. Even though only the hash of an account's password is stored in the KDC or SAM database, earlier hash algorithms are well known. This is particularly true for the down-level Windows NT 4.0 NTLMv1 hash algorithm. There are crack applications available to determine the account password through brute force. However, Kerberos and NTLMv2, supported on Windows NT 4.0 Service Pack 4 or greater, have much stronger hash-generating algorithms. In addition, disabling the Windows Server Store password by using reversible encryption for all users in domain password policy will make reading the hash very difficult. This can be accomplished by opening the Default Domain Policy snap-in select Windows Settings Security Settings Account Policies Password Policies. Double-click Store password using reversible encryption from the right panel. In the dialog box, select Enable or Disable and click OK. One-way encryption is generally stronger. Therefore, we recommend that you disable this feature. With Windows Server 2003, an administrator can also increase the password security level through the Registry editor using the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, add NoLmHash value

NOTENew to Windows Server 2003 is support for the new NIST Hash Algorithms (FIPS 180-2 and PKCS #1). This feature supports the new National Institute of Standards and Technology (NIST) hashing algorithms, which are part of the latest drafts of Federal Information Processing Standard (FIPS 180-2) and PKCS 1. The new hashes are included in the Advanced Encryption Standard (AES) RSA Full Cryptographic Service Provider. Public Key Cryptography Standards (PKCS) 1 recommends use of these new hash algorithms for newly developed applications. This feature is integral to the operating system and requires no administrative intervention.

NOTEAnother new feature of Windows Server 2003 is support for the FIPS Kernel-Mode Crypto Module that is integral to the operating system. It runs as a driver in kernel mode and implements the cryptographic algorithms approved by FIPS. The kernel driver will go through testing so it can be on the list of FIPS 140-1 Level 1 certified cryptographic modules. The supported algorithms include Secure Hash Algorithm-1 (SHA-1), Digital Encryption Standard (DES), 3DES, and an approved random number generator. It is designed specifically to enable government sectors to deploy Internet Protocol Security that is compliant with FIPS 140-1.

BACKUP OPERATORS

The Default Domain Controllers Policy GPO gives both the Administrators and Backup Operators groups the right to back up and restore files and directories by default. 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 from Windows NT to Windows Server 2003. 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, and as a result directories like %SystemRoot%System32 were wide open to destruction from it. Windows Server 2003 has 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.

Password Policies

As previously underscored, passwords represent one of the basic areas of security vulnerability. Since password policies can minimize abuses, we highly recommend establishing them.

DOMAIN PASSWORD POLICIES

Password lockdown is accomplished differently when working with domains and local system accounts. Password and account lockout policies should reflect the settings within the securews.inf (for secure workstations) and securedc.inf (for domain controllers) templates. Security templates are used to establish a standard set of policies that can be used repeatedly. For a quick visual inspection, the Security Template snap-in and Default Domain Policy snap-in can be used to rapidly compare template settings against those currently in use. An in-depth comparison can be achieved with the Security Configuration and Analysis snap-in. Refer to Chapter 8, "Group Policies," for information about using and applying policies.

Table 11.3 outlines the password policies that apply to both domain and local computer passwords. To change or view domain password policies, open the MMC Default Domain Policy snap-in select Computer Configuration Windows Settings Account Policy. Double-click Password Policy. Select each listed policy and make the appropriate changes.

PASSWORD LOCKOUT POLICIES

Password lockout policies minimize a hacker's ability to discover a logon name and password. The policies should be liberal enough to permit a user with "sloppy" typing skills to make several attempts at a successful logon but sufficiently tight to frustrate an attacker.

There are three lockout policies (Table 11.4):

Account Lockout Counter establishes the number of unsuccessful logon attempts that will be permitted prior to a lockout. Although there will always be an authorized user who will repeatedly fail, five attempts is a reasonable number.

Account Lockout Duration establishes the period of time in which the lockout will be enforced, after which the system is unlocked and new logon attempts will be recognized. A reasonable time is 30 minutes.

Reset Lockout Counter resets the lockout attempt counter in the period designated. Again, 30 minutes is reasonable.

These policies are available from the MMC Default Domain snap-in select Computer Configuration select Windows Settings select Security Settings Account Policies double-click Account Lockout Policy. To modify the displayed settings, double-click the targeted policy and make changes in the dialog box that appears.

LOCAL PASSWORD SETTINGS

If local user accounts are established, strict policies for local passwords should be set. The options available for local passwords mirror those of the domain password settings. They can be viewed and set from the Security Configuration and Analysis snap-in select Account Policies double-click Password Policy. They may also be viewed from the Local Computer Policy snap-in. Select from the listed policies and make the appropriate changes.

DETERMINING WHO SETS A PASSWORD

Windows Server 2003 configuration allows passwords to be established by the end user or the system administrator. The system administrator typically selects the password when it is likely that the user will choose a weak one or the end user is not very sophisticated. The biggest problem with this scenario is that the administrator is likely to create a password that is very difficult to remember, inclining the end user to write it down for easy reference. Although the intent is to strengthen security, the moment a password is written down, security is compromised.

The alternative approach is to have the end user set the password and enforce rules that make password creation unique. Additionally, the user should be forced to change the password periodically.

PASSWORD FILTERING

One method of ensuring that the created password meets the desired level of complexity is password filters. A password may be filtered as suggested, but it must meet the complexity requirements policy.

The password filter installed with Windows Server 2003 may be used or a custom filter may be applied. Installation is accomplished by modifying the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa Registry key and adding the file name with .dll extension to the string list. The *.dll filter should be placed in the %SystemRoot%\system32 folder.

OTHER USER ACCOUNT SECURITY OPTIONS

Windows Server 2003 provides many additional security restriction options for both domain and local users. Describing each of them would require dozens of pages of text, so, since they are fairly obvious, we will point you to them instead. To view and modify these options, open the Default Domain snap-in select Windows Settings select Security Settings select Local Policies select Security Options. Double-click the targeted policy and make appropriate changes in the dialog box that is displayed.

Registry and File System Lockdown

Registry and file system permissions are crucial to Windows Server 2003 security. Default security permissions can be viewed from the Security Templates snap-in. The basicdc.inf, basicsv.inf, and basicwk.inf templates are the only ones that modify File System and Registry group policy security settings. A GPO should be used to enforce these default templates and ensure that all users and services are covered by the secure file and Registry settings. These templates also reflect the default file and Registry permissions for all Windows Server installations and are considered secure. The other default templates in the Security Template snap-in are designed to cover other security policy areas.

In addition to manipulating the security templates to reflect the appropriate lockdown levels, administrators should apply these four rules:

Use NTFS and take advantage of Windows Server 2003 file/folder permissions, auditing, and file encryption.

Do not place sensitive information or system files on a FAT partition. There are no file/folder permissions for local access on a FAT file system.

Remember that the file owner always maintains full control over the object. Even if the administrator denies the owner all permissions, the owner can still view and modify security settings.

When auditing file systems, never neglect the file owner.

NOTEWindows Server 2003 prevents file thumbnails from being placed in exposed directories when a user modifies ACLs or encrypts the file.

Trojan Horses and Viruses

One of the biggest security threats to your network is unauthorized scripts, applications, DLLs, applets, ActiveX, and any other code component that can run on the operating system. These components perform processes that can destroy system operation and data. The concept of the Trojan horse derives from the ancient tale of the battle of Troy, when Greek soldiers passed the Trojan barriers by hiding inside a giant wooden horse that they offered as a gift to Troy. That event created the saying "Beware of Greeks bearing gifts," but it might be better stated today as "Beware of geeks bearing unknown code." What might appear harmless could create significant losses.

Software components constructed by hostile individuals are generally imported through e-mail, FTP, or Web services, or are internally created and distributed within your network. Once a hostile component is strategically placed on a system, the "Trojan horse" waits to be executed by the user. All processes started during a user's session will run with that user's security token. Thus, when a user inadvertently runs a hostile component, that hostile component assumes all of his rights and privileges. Additionally, the process will assign the user's default discretionary ACL to newly created objects, enabling the hostile component to create new elements with permission settings equal to the rightful user's.

If a hostile individual is able to place the component on the user's machine in the first place, she obviously has some level of access (or the user downloaded the component from the Web). This security threat is also probably looking for a way to improve its current access rights, and the administrator's account is its most promising target.

There are a number of defensive practices you can employ against Trojan horses and viruses, including the following:

Never run applications under the Administrator account.

Use auditing and scripts to search for components in suspect directories.

Ensure that environmental parameters are set correctly, as discussed in the next section.

Don't run software from unknown sources, and use up-to-date antivirus software.

Environmental Path Settings

Path security is all too often overlooked. Most applications started from the command window and from the desktop use environmental parameters to determine common directory locations and system information. The PATH variable determines a logical search path direction through directories (or folders) to find a given component. If a hacker knows the exact location of a component, he can gain access to an object even without permission to the folder. This may take skill, but Chapter 8 discusses how to use absolute paths to override folder permissions. The system administrator should ensure that only the intended directories are included in the PATH variable. These variables can be viewed from Control Panel System Advanced tab Environmental Variables. They can also be viewed by typing path at the command prompt.

Environmental variables (illustrated in Figure 11.5) are applied in order from the following sources:

Autoexec.bat (tightly restrict access)
first modifies environmental parameters.

System environment
only administrators modify further parameters.

User environment
final modification to environmental parameters can be done by the user.

CURRENT WORKING DIRECTORY SECURITY RESOURCE

A misguided user could be the source of real problems stemming from within his or her current working directory. The default working directory is defined in the user's account properties and is otherwise known as the home directory. If a cracker has somehow broken into a user's account, some level of risk exists. The current working directory is searched in addition to the directories specified in the PATH variable. A cracker may place executables in the working directory that replace the intended system calls. Thus, if an application is run from a directory other than the system or program directory, a rewritten .dll impostor may be executed rather than the intended one. This .dll may perform the same tasks as the intended code in addition to providing the cracker access to the system at the user's privilege level. If this happens from an ordinary user's account, the resulting problems will ordinarily be restricted to that account. However, if it happens from an administrator's account, the entire system and perhaps the domain could be damaged. Obviously, this can lead to problems when users, and especially administrators, execute applications from directories that are not secure. To prevent working directory mishaps, the following commonsense steps should be enforced:

Designate application directories and tightly configure permissions.

Regularly search the system for .dll files that are not located in the %SystemRoot%, Program Files, or other designated application directories.

Look for any type of executable created by unauthorized users.

EXTENSION MAPPING TO DISGUISE A FILE TYPE

Windows .NET associates a file name extension with a particular application. When a file from Explorer or My Computer is opened, it is graphically displayed with the associated application's icon. Changing this mapping is very simple and can render the file nonexecutable. It is achieved by selecting it from the Explorer or My Computer window, selecting a file, right-clicking the Properties option, and clicking Change. This does not change the format of the file, but simply alters the Open With application list. The best defense is to encourage users to restrict their use of this facility.

A more serious problem can occur if the Registry is somehow violated. The HKEY_LOCAL_MACHINE\SOFTWARE\Classes key stores specific information on the application that is launched with each file extension. With Regedit or Regedit32, it is possible to remap a plain text file (.txt) extension, for example, to any application available in the system. Let's assume that someone has loaded a malignant program that removes all files in the current working directory. Further, through access to the Administrator account, the Registry had been changed so that all .txt extension files are mapped to this damaging program. The obvious effect is that the next time anyone launches a text file, all files in that current working directory will be lost. This is just another reason to guard against unauthorized Registry modification.

SPOOFING SHORTCUTS

Desktop shortcuts are used to streamline access to an application or file. If access is somehow granted to the shortcuts on a user's desktop, it is possible to change the properties and direct the shortcut to another file or application. In the case of a system administrator, a malicious internal user or hacker could direct a shortcut to a damaging virus or Trojan horse. While the administrator believes that he or she is executing a normal application, the shortcut is spoofing the reality of its redirection. This possibility again underscores the need for users not to leave their desktops unprotected.

Extraneous Services as a Security Threat

Common sense dictates that the more services on a server, the greater the opportunities for attack. Thus, a minimalist approach to system administration can be a positive security action. Remove unneeded services and applications from all systems. For instance, some unused subsystems may not have known security holes as yet but without careful monitoring may leave the system vulnerable.

In most environments, for example, the POSIX and OS/2 subsystems serve little or no value. (This statement does not apply if the Interix UNIX 95 environment is used in place of the standard POSIX subsystem.) However, because they communicate with the Windows Server 2003 executive mode, they can create a program or command that does significant damage. Therefore, unless a clear requirement exists, remove the POSIX and OS/2 subsystems by using the Registry Editor to remove the strings "OS/2" and "POSIX" from the Registry key. The modification should be made on the Registry tree level HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Subsystems \Optional.

Backups and Restoration Security

Data integrity is not commonly viewed as a security issue, but maintaining system and data backup is fundamental. Securing valuable information through regular backups is the best defense against a disaster, a runaway virus, or a hack job. In Chapter 13 we elaborate on backup and restoration methods in Windows Server 2003

When implementing a backup policy, don't forget to also secure the backup media. For example, if you regularly back up critical data files and then tuck media away in an unsecured desk drawer, you are inviting theft. At a minimum, store backup media in a secure environment. We also recommend that a second set of backup media be periodically archived in a secure remote location.

Physical Security

The importance of physical security cannot be understated; it ranges from issues of outright theft of a system or key storage component to intervention with the boot drive during startup. Let's consider several common scenarios that threaten physical security.

THEFT OF SYSTEMS OR STORAGE MEDIA

At a minimum, efforts must be taken to physically lock down domain controllers and member servers. As powerful systems come in lighter and more portable packages, the ability to take important services out the door without detection becomes increasingly easy.

Theft of critical media is just as easy. If unmonitored access is provided to a critical system like a domain controller, it is really no effort to open the cover and pull a hard drive. Your physical data can be out the door and in the hands of a hacker in just a few minutes.

PHYSICAL ACCESS TO THE BOOT CD-ROM AND FLOPPY DRIVES

Let's consider another hardware-based scenario. Physical access to a floppy drive or CD-ROM on a domain controller or member server during the booting process invites intrusion. For the malicious, it is possible to use boot disks to erase all data or to get system access. With FAT-based Windows Server installations, the boot can also be used to gain direct access to files on the drive. All the invader has to do is abort the install process and revert to a DOS prompt. Even easier is simply booting directly from MS-DOS. Although native-mode NTFS was designed to prevent intrusion, the same type of utilities that plagued Windows NT, such as ntdos.exe, will undoubtedly surface for Windows Server 2003.

General Physical Security Solutions

To prevent this type of serious damage, it is recommended that domain controllers and member servers be physically locked in a server room or, minimally, fitted with locking devices. Also, use passwords to protect BIOS settings, which eliminate floppy disk and CD booting. If the BIOS password is not supplied, settings cannot be modified and thus attempts to boot floppies or CD-ROMs can be denied.

NOTEMany CD-ROMs come with an autorun function, which allows a virus to be executed or copied onto a hard drive without visibility. Turning off this feature is recommended. Using the Registry Editor, move to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControllerSet\Services\CDROM key. Right-click Autorun REG_Word and select Modify. Set the value to 0.

Another commonsense security action is placing critical systems and media in an environment that is not likely to experience water damage. For example, if a pipe breaks over the weekend and results in even a few inches of water, a floor-standing server as well as its data could be damaged.

Dual-Boot Environments

Installing more than one bootable operating system on a machine can breach security. Even NTFS partitions are vulnerable to the Administrator account's being accessed through a secondary operating system. If another operating system is booted, permissions set from the original are useless.

Auditing as a Line of Defense

The Windows Server 2003 audit trail is invaluable. For example, it can determine how a system crashed, how security was compromised, or how much disk space a user is consuming. The OS provides highly granular control over the logged events and the objects and services allowed to record events.

USING SECURITY AUDITING

The Windows Server 2003 auditing properties are viewed and modified through GPOs. The Audit policies found in the Default Domain snap-in via Computer Configuration Windows Settings Security Settings Local Policies Audit Policy determine what events are recorded in the Security Log. Standard events are shown is Figure 11.6.

The group policies found in the Default Domain snap-in via Computer Configuration Windows Settings Security Settings Event Log (Figure 11.7) provide control over a number of properties. This control includes how much disk space is dedicated to the logs, who can access them, how long they are retained, and the method for retaining them.

Event Log Retention

The retention method for a security log configures how the log is updated once it is full. If an overwrite option is not selected, the system will halt when the log is full, whereupon the administrator must take the following steps to enable the system:

From the Start menu, select Programs Administrative Tools Event Viewer and save the current logs (if desired). Clear All Events from each.

Change the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\crashonauditfail to 1.

Restart the system.

OFFLINE AUDITING POLICIES

Reviewing audit reports while offline may prove convenient in some administrative circumstances. Auditing policies for offline folders can be found in the Default Domain snap-in via User Configuration Administrative Templates Network Offline Files. See Figure 11.8 for a list of options.

EVENT VIEWER USE

The Event Viewer gives the administrator access to six event logs. The Security Log displays successes and failures and classifies them into Object Access, Account Logon, Policy Change, Privilege Use, Directory Service Access, and Account Management categories (Figure 11.9).

The other logs have three types of record
Error, Information, and Warning (Figure 11.10). The Application Log contains events logged from programs running on the system, including all exceptions raised. The System Log records events raised by the Windows Server 2003 operating system (Figure 11.11 on page 505). All users can view the System and Application Logs but only administrators can view the Security Log.

File, folder, printer, Active Directory, group policy, and other system objects have associated access control lists (ACLs). Each ACL is composed of a discretionary access control list (DACL) and a system access control list (SACL). The DACL details user and group access rights to an object (Figure 11.12 on page 506); the SACL determines the users and groups that will be audited when attempting or performing access rights on the object (Figure 11.13 on page 507).

GENERAL AUDITING PROCEDURES

The following steps should be observed when using Windows auditing:

Set the SACL on objects of interest to identify the group and user access events to monitor.

Set auditing policies to record the desired events.

Periodically view the logs and clear them out.

NOTEAs you establish your auditing strategy, remember that only NTFS files and folders can be audited.

AUDIT EVENTS THAT NEED THE MOST CAREFUL REVIEW

No system administrator can track and review all event items, but must restrict her attention to those of greatest importance. As a general rule, audits of the following events are particularly helpful when tracking security threats:

Logon/Logoff provides information on logon failures and may indicate if a certain user account is under attack.

Account Management provides information on users who have sought rights to use administrative tools.

Startup/Shutdown shows who has attempted to invoke a shutdown command and also lists services that were not properly initiated during startup.

Policy Changes indicates what policy changes were attempted.

Privilege Use lists attempts to change permissions to objects.

NOTEIf a cracker breaks into the system, he will most certainly try to cover his tracks and erase the logs. To guard against this action and retain logs, provide remote logging of the above events to a secure log server that is in a safe place with only local logons, and have critical events printed out to a printer. This will keep the log files intact and help trace security problems.