Customizing Server Security

EXAM 70-293 OBJECTIVE 1

Security templates contain predefined configurations, which are a great starting point, but usually, they do not fulfill the needs of many organizations. You may need to make some changes to match the organizational policies of your company. Similarly, configuring roles for servers requires additional steps to make the servers secure from attacks, accidents, and other possible problems. By customizing server security, you can implement security measures that will fulfill the unique needs of your organization.

Because every organization is different, the security needs of one company may vary from those of another. Before making security changes, you should consult corporate policies, as well as any requirements pertaining to organizational certifications or relevant laws. You should also use the other methods of identifying the security requirements of an organization that were discussed earlier in the chapter. Once you have an understanding of the organization’s needs, you can determine what customization needs to be done to enhance security.

Securing Servers According to Server Roles

EXAM 70-293 OBJECTIVE 1.3, 1.3.1

As you saw earlier in this chapter, servers can be configured in any number of different roles. You can use the Configure Your Server Wizard to configure the server for that role. Although this procedure may install and enable a number of different services, tools, and technologies, additional steps usually are required to ensure the server’s security. Some tasks are unique to the server’s role, but others should be applied to all servers on your network.

Security Issues Related to All Server Roles

Any server used by members of an organization might be at risk of attacks by hackers and malicious programs, as well as accidents or other disasters. You will want to consider taking a number of countermeasures to ensure that any server is well protected.

Physical Security

As the term suggests, physical security addresses the need to protect servers from physical threats. Such threats may affect any number of assets in an organization and can result in widespread damage. These types of threats always involve some level of tangible risk. Taking steps to prevent physical interaction with equipment and implementing methods to ensure that equipment is safe from environmental threats will help promote physical security.

A large part of physical security involves protecting systems from unauthorized physical access. Even if you’ve implemented strong security that prevents or limits access across a network, it will do little good if a person can sit at the server and make changes or (even worse) pick up the server and walk away with it. If people have physical access to a server, any number of events could occur. They could knock out network cables, bump the server over, spill a drink on electrical components, or unplug it. Physical security controls access to hardware and software, so that people are unable to damage or steal devices and the data they may contain. If people do not have physical access to systems, the chances of unauthorized data access are reduced.

To prevent physical contact, all servers in an organization should be locked in a secure area. If it can be justified, a dedicated server room should restrict access. If a company’s facilities are limited and there is only a single server involved, it should be kept in a locked closet to prevent anyone from touching it. In addition to the server itself, all installation CDs and backup tapes used by the server should be kept under lock and key.

Physical security also involves protecting servers and other assets from environmental disasters. Natural disasters can occur at any time, and they are largely dependent on the geographical location of an office. For example, a branch office in Tornado Alley would need to be able to withstand twisters, and a California branch office might need to withstand earthquakes and mudslides. In both areas, however, Uninterruptible Power Supplies (UPSs) should be installed to provide electricity during power outages, and systems to extinguish fires need to be in place. By considering natural risk sources within an area, you can determine which measures need to be taken to reduce or remove risks.

Physical security not only includes natural disasters, but also those caused by the workplace environment. If a server room isn’t properly ventilated with temperature control, the server could overheat or experience issues with electrostatic discharge. In wireless networks, poor environmental conditions could also cause sensitive data to be accessed by other parties who pick up the signals. As data is transmitted, unauthorized parties using special equipment could intercept the packets of data sent over the wireless network. In addition, servers need to be stored in stable areas that adhere to the environmental requirements of the equipment.

Head of the Class...
Knowing When to Stop Securing Systems

Security is an ongoing process, but there comes a time when you need to decide that enough is enough. No system can be absolutely secure, and every level of security you add restricts access and functionality. For this reason, security is a trade-off, and you need to decide when you’ve reached an acceptable level.

A major consideration for security is cost versus benefit. At no time should the cost of securing an asset exceed the value of that asset. For example, a server may be configured as a file server and contain sensitive data, which means a higher level of security is needed than for other resources. In providing this security, you don’t want to pay more for security than the equipment or data is worth. If the server cost $7,000, and it would cost the company $5,000 to replace the data, any security costs over this collective amount would negate any benefits from securing the server. Once it approaches the point where the company is spending an unreasonable amount of money to protect data or equipment, you’ve exceeded the optimal level of security. Keep in mind that you may need to work with your company’s Accounting department to come up with the appropriate numbers.

Service Packs and Hotfixes

At times, software vendors may release applications or operating systems with known vulnerabilities or bugs, or these problems may be discovered after the software has been released. Vulnerabilities are weaknesses in programming code that can be exploited. Bugs are defects that may cause the software to function incorrectly. To remedy these issues, manufacturers will release service packs, patches, or bug fixes after they have brought their product to market. Service packs contain updates that may improve the reliability, security, and software compatibility of a program or operating system. Patches and bug fixes are used to repair errors in code or security issues. Failing to install these may cause certain features to behave improperly, make improvements or new features unavailable, or leave your system open to attacks from hackers or viruses. In most cases, the service packs, patches, or bug fixes can be acquired from the manufacturer’s Web site.

Updates for Windows operating systems are made available on the Windows Update Web site, which can be accessed through an Internet browser by visiting http://windowsupdate.microsoft.com . The Windows Update Web site determines what software is recommended to secure your system, and then allows you to download and install it from the site.

Windows Update provides updates for only Windows operating systems, certain other Microsoft software (such as Internet Explorer), and some additional third-party software, such as drivers. To update most third-party programs installed on the computer, you will need to visit the manufacturer’s Web site, download the update, and then install it.

Windows 2000, Windows XP, and Windows Server 2003 also provide an automated update and notification tool that allows critical updates to be downloaded and installed without user intervention. When enabled, this tool regularly checks Microsoft’s Web site for updates, and if one or more are found, automatically downloads and installs the update. You can also just have it notify you that updates that are available. Because this tool requires connecting to Microsoft over the Internet, it can be used only if the servers or workstations have Internet access.

In some situations, administrators may not want Windows Server 2003 to automatically download and install software without their approval, or they may not want computers to connect to the Microsoft Web site in this manner. In these cases, the Automatic Updates service should be disabled or configured so that it is used for notification only. These settings can be accessed by selecting Start | Control Panel | System and clicking the Automatic Updates tab in the System Properties dialog box. As shown in Figure 2.27, the Automatic Updates tab provides a number of settings that allow you to configure whether updates are automatically acquired and installed on the computer, when updates occur, and whether intervention is required. These settings include the following:

• Keep my computer up to date Enables Automatic Updates on the machine. When this selected, the other settings in this list may be configured.

• Notify me before downloading any updates and notify me again before installing them on my computer Informs users that an update is available and asks them if they would like to download it. If the user chooses to have the update downloaded, Automatic Updates will prompt the user when the download is complete, asking if the update should be installed.

• Download the updates automatically and notify me when they are ready to be installed Causes any updates to be downloaded from the Microsoft Web site without any notification. Once the update has completed downloading, the user is asked if the update should be installed.

• Automatically download the updates, and install them on the schedule that I specify Causes any updates to be downloaded from the Microsoft Web site without any notification. When this option is chosen, you can specify the time when the update can be installed without user intervention.

  
  Figure 2.27: Choosing Automatic Updates Options

Head of the Class...
Deciding Whether to Apply an Update

Even though service packs, bug fixes, and patches are designed to fix problems with an operating system or application, you cannot be sure that they will not cause problems themselves. An example of this is Windows NT 4.0 Service Pack 6, which caused major problems after being applied. This service pack was removed from the Microsoft Web site and soon replaced with Service Pack 6a. It’s usually a good idea to wait a few days or a week to see if other customers of the manufacturer experience any issues before installing an update.

To ensure an update works properly and does not cause major problems with computers on your network, it is wise to apply the update to a test machine or computer in a lab environment before applying it to computers on the production network. A test machine has the same configuration and programs installed as other network machines, but it isn’t actually used for business purposes. Testing updates on such a computer is especially important when applying updates to servers, because server changes can affect large numbers of users if problems arise.

Although new versions of Windows provide a method of automatically applying updates from Microsoft’s Web site, you can configure this service to either notify you before applying an update or disable the service so that Windows will not regularly check for updates. If this service is disabled, you must regularly check for updates manually by visiting Microsoft’s site, downloading the updates, and applying them. You should never merely install Windows and leave it without applying critical updates. Failing to apply certain updates may leave your system vulnerable to attack or cause elements of the system to function unexpectedly.

Antivirus Software

Viruses, Trojan horses, and other malicious programs are a threat to any organization, especially if the organization is connected to the Internet. If these programs infect a network, data and systems can be damaged or destroyed. Worse, infection might cause critical information (such as passwords or files) to be transmitted to other sources. To prevent these malicious programs from causing problems, antivirus software should be installed on servers and workstations throughout the network.

When antivirus software is installed, it will scan for viruses and clean them using information stored in signature files. Signature files are used to identify viruses and let the software know how to remove them. Because new viruses appear every month, signature files need to be updated regularly by downloading them from the vendor’s Web site.

Unnecessary Accounts and Services

Hackers and malicious programs can use insecure elements of a system to acquire greater access and cause more damage. To keep these entities from exploiting elements of your system, you should disable any services that are not needed. If a service has a weakness for which a security patch has not been developed, it could be exploited. By disabling unneeded services, you are cutting off possible avenues of attack. In doing so, you will not affect any functionality used by computers and users, and you can avoid any security issues that may be related to them.

Certain accounts in Windows Server 2003 should also be disabled or deleted. If an account is no longer being used, it should be removed to avoid a person or program using it to obtain unauthorized access. Even if an account will not be used temporarily (for example, during an employee’s leave or vacation), the account should be disabled during the user’s absence. If an employee has left permanently or a computer has been removed from the network, these accounts should be deleted.

There are other accounts that you should consider disabling due to their access level. The Administrator account has full access to a system and is a well-known account. Windows Server 2003 and previous versions of Windows all have an account named Administrator that has the ability to do anything on a server. Because hackers already know the username of this account, they only need to obtain password to achieve this level of access. Although the Administrator account cannot be deleted, it can be disabled and renamed. If you create new user accounts and add them to the Administrators group, and disable the Administrator account, attackers will find it more difficult to determine which account to target.

Another account that is disabled by default, and should remain so, is the Guest account. This account is used to provide anonymous access to users who do not have their own account. Like the Administrator account, the Guest account is created when Windows Server 2003 is installed. Because there is the possibility that this account could accidentally be given improper levels of access and could be exploited to gain even greater access, it is a good idea to leave this account disabled. By giving users their own accounts, you can provide the access they need and audit their actions when necessary.

For any user, group, or computer account, it is important to grant only the minimum level of access needed. Employees can accidentally or maliciously modify data or use systems inappropriately. To prevent users from causing such problems, you should never give them more access than they require. You want users to be unable to access anything beyond the scope of their role within the organization. This will assist in keeping other data and systems on the network protected. Determining what level of security a user needs to perform his or her job usually requires some investigation. All users often have their own personal directories for storing files, but they also typically need additional access to databases, programs, and files stored on various servers. To determine how much access a user or group needs, you should begin by discussing the user’s duties with management. By understanding the job a user performs, you will be able to determine which resources the user needs to access.

Strong Passwords

Passwords are a key component of the default method of authentication for Windows and other software (such as database management systems). They are used to prevent unauthorized access to computers, networks, and other technologies by forcing anyone who wants access to provide a specific piece information, which should be known only to the authorized user.

Strong passwords are more difficult to crack than simple ones. These types of passwords use a combination of keyboard characters from each of the following categories:

• Lowercase letters (a–z)

• Uppercase letters (A–Z)

• Numbers (0–9)

• Special characters (` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : “ ; ‘ < > ? , . /)

The length of a password also affects how easy it is to crack. The more characters used, the more variations of letters, numbers, and special characters the password can contain. You can use security templates and group policies to control how long a password is valid, the length of a password, and other aspects of password management. If you specify a minimum password length of at least seven characters, it will be harder to exploit the account accessed with this password.

In addition, you should avoid using passwords that contain your username, real names, or company name, because these make passwords easier to guess. You should also avoid using passwords that contain actual words that appear in the dictionary, because hacking programs can be used to crack such passwords.

Another requirement that is important to having secure passwords is making sure that each time users change their passwords, they use passwords that are different from previous passwords. All too often, users will use the same password over and over, modifying it slightly. For example, they might have the password “pass1” one month, and then change it to “pass2” the next. In other cases, they might simply change the password each month to the name of the current month (January, February, and so on). Again, ensuring each new password is different from previous passwords will make it more difficult for unauthorized persons to determine current passwords.

To ensure domain controllers are secure, there are a number of password requirements that are enforced by default on Windows 2003 domain controllers:

• The password cannot contain any part of the user’s account name.

• It must be a minimum of six characters in length.

• It must contain characters from three of the four categories: lowercase letters, uppercase letters, numbers, and special characters.

NTFS

Windows Server 2003 supports the FAT, FAT32, and NTFS file systems. Of these, NTFS provides the highest level of security. Using NTFS, you can do the following:

• Set permissions on individual files and folders.

• Control which accounts have access to file system resources.

• Implement file encryption, which prevents unauthorized users from accessing files and folders.

• Implement disk quotas, which allows you to control how much hard disk space users may use.

Using NTFS greatly enhances the security and management of files.

Disk partitions can be formatted with NTFS when a server is initially installed. If a volume is formatted as FAT or FAT32, you can convert it to NTFS. You can convert partitions to NTFS by using the command-line tool convert.exe. This tool changes existing partitions into NTFS partitions, without adversely affecting any files on the hard disk.

Exam Warning

NTFS is an important part of security on Windows NT, Windows 2000, and Windows Server 2003 systems. Without NTFS, permissions cannot be set on individual files or folders. In Windows Server 2003, other features such as disk quotas and EFS are not available without NTFS.

Regular Backups

It is also important to perform regular data backups. When backups are performed, the data on a computer is copied to other media (such as tape), which can then be stored in another location. If a problem occurs with the source data, you can restore any files that were damaged or lost. For example, if a user accidentally deletes a file or a server’s hard drive crashes, a backup can be restored and all files returned to their previous state.

Windows Server 2003 also provides Automated System Recovery and the Recovery Console for restoring systems that have failed.

Recovery Console is a text-mode command interpreter that can be used without starting Windows Server 2003. It allows you to access the hard disk and use commands to troubleshoot and manage problems that prevent the operating system from starting properly. With this tool, you can do the following:

• Enable and disable services.

• Format hard disks.

• Repair the master boot record and boot sector.

• Read and write data on FAT16, FAT32, and NTFS drives.

• Perform other tasks necessary to repairing the system.

You can start Recovery Console from the installation CD for Windows Server 2003, or you can install it on an x86-based computer. When installed on the computer, Recovery Console can be run from a multiple-boot menu that appears when the computer is first started. Either method will start the same program and allow you to enter different commands to repair the system.

Automated System Recovery (ASR) allows you to back up and restore the Registry, boot files, and other system state data, as well as other data used by the operating system. An ASR set consists of files that are needed to restore Windows Server 2003 if the system cannot be started. When you create an ASR set, the following items are backed up:

• System state data

• System services

• Disks that hold operating system components

In addition, ASR creates a floppy disk that contains system settings. Because an ASR set focuses on the files needed to restore the system, data files are not included in the backup.

You should create an ASR set each time a major hardware change or a change to the operating system is made on the computer running Windows Server 2003. For example, if you install a new hard disk or network card, or apply a security patch or service pack, you should create an ASR set. Then, if a problem occurs after upgrading the system, you can use the ASR set to restore the system to its previous state (but only after you’ve attempted other methods of system recovery).

ASR should not be used as the first step in recovering an operating system. In fact, Microsoft recommends that it be the last possible option for system recovery and be used only after you’ve attempted other methods. In many cases, you’ll be able to get back into the system using Safe Mode, the Last Known Good Configuration or other options.

To create an ASR set, use the Windows Server 2003 Backup utility. On the Welcome tab of the Backup utility, click the Automated System Recovery Wizard button. This starts the Automated System Recovery Preparation Wizard, which takes you through the steps of backing up the system files needed to recover Windows Server 2003 and creating a floppy disk containing the information needed to restore the system.

Securing Domain Controllers

The methods described in the previous sections can improve the security of a server in any role, but they are particularly important for domain controllers. Physical security and strong passwords are needed to prevent unauthorized parties from modifying accounts or other aspects of the domain. In addition, methods to protect the server from malicious programs and tampering should be implemented. Examples include applying updates, installing antivirus software, and formatting all partitions as NTFS.

The effects of an insecure domain controller can be far-reaching. Information in AD is replicated to other domain controllers, so changes on one domain controller can affect all of them. This means that if an unauthorized entity accessed the directory and made changes, every domain controller would be updated with these changes. This includes disabled or deleted accounts, modifications to groups, and changes to other objects in the directory. Because all Windows 2000 Server domain controllers store a writable copy of AD, additional steps must be taken to secure the directory.

It is important that group membership is controlled, so that the likelihood of accidental or malicious changes being made to AD is minimized. This especially applies to the Enterprise Admins, Domain Admins, Account Operators, Server Operators, and Administrators groups.

Because anyone who has physical access to the domain controller can make changes to the domain controller and AD, it is important that these servers have heightened security. Consider using smart cards to control authentication at the server console.

Encryption should also be used to protect data and authenticate users. As mentioned, NTFS partitions allow file encryption, and Kerberos provides strong authentication security. In Windows Server 2003, Kerberos is the default authentication protocol for domain members running Windows 2000 or later.

Securing File and Print Servers

File and print servers also need additional security. In addition to setting permissions on files and folders, regularly performing backups, and using antivirus software, organizations may also need to implement greater levels of protection such as encryption. Similarly, print servers need to be protected from improper use and must be configured to prevent unauthorized users from wasting print resources.

File Servers

Because file servers are used to store data in a central location, it is important that they are kept secure. Although file servers allow the data to be accessed by other users, you need to ensure that only those who are authorized are able to use the files. For this reason, it is especially important that volumes on a file server are formatted as NTFS and appropriate permissions are set on files and folders. As an added measure of security, these disks should also use EFS.

EFS is used to encrypt data on NTFS volumes. When EFS is used, unauthorized users and malicious programs are prevented from accessing the content of files, regardless of their permissions. Although the process involved in the encryption and decryption of data can be quite complex, EFS file encryption is completely transparent to the user.

When a user specifies that a file is to be encrypted using EFS, parts of the file are individually encrypted with file encryption keys. These keys are stored in the file header and encrypted using a public key that corresponds to the user who encrypted the file. When the user accesses the file, the file encryption keys are decrypted using the private key that corresponds to the public key that was used to encrypt them. Because this key is held privately by the user who encrypted the file, no one else can access it. The decrypted file is stored in memory, and the original file remains stored in the file system remains encrypted.

When a folder is encrypted with EFS, you have the option of encrypting all files and subfolders inside it. If this option is used, any files that are created in or copied to folder or subfolders are automatically encrypted. If encryption is not specified at the folder level, only the files and subfolders that a user explicitly specifies will be encrypted.

Configuring & Implementing...
Ensuring That Data Is Encrypted

EFS is an important part of keeping data secure on a file server because it prevents unauthorized parties from viewing and modifying data. When folders are encrypted with EFS, you can have all files and subfolders encrypted as well. If this option isn’t used, files on the hard disk will not be encrypted. This is an important issue when users are working with applications that create temporary files.

Temporary files are used to store information while the person is working on a document, spreadsheet, or other file. These files are created by the application and may contain a duplicate working copy of a file. Although applications that use temporary files are supposed to remove them when the files are closed or the program shuts down, this isn’t always the case. If an authorized user opens an encrypted file using a program that creates temporary files, an unencrypted temporary file may be created. Potentially, a hacker who could not access the data in the encrypted file might be able to open the temporary file and view the data inside it.

To ensure that temporary work files are not accessible, you should encrypt the temporary folder you specify in the application. In this way, when the application creates a temporary file, it will automatically be encrypted, eliminating a potential target for hackers.

Although EFS is an important part of securing a file server, this does not mean that every file on the network is a candidate for being encrypted with EFS. As mentioned, only files on NTFS volumes can be encrypted with EFS. If a volume is formatted as NTFS, files that have the System attribute or are located in %systemroot% (for example, C:\Windows) cannot be encrypted. Also, if the file or folder you want to encrypt is compressed, you cannot use encryption. The opposite is also true: if a file or folder is encrypted with EFS, it cannot be compressed.

Note

In Windows 2000, there was no visual indication of which files and folders were encrypted. This made management of EFS difficult because you needed to examine file and folder properties when attempting to ascertain which ones were encrypted. In Windows Server 2003, Microsoft developers included an option that colors encrypted files and folders green, so that they can be easily spotted in Windows Explorer and other applications.

Another important limitation of EFS is that it encrypts data only on NTFS volumes. When a file is accessed remotely on a file server, Windows Server 2003 decrypts it and sends it across the network in unencrypted form. For data to be encrypted during transmission, other technologies like IPSec must be used.

IPSec ensures that data is sent securely over the network by encrypting packets and authenticating the identity of the sender and receiver. When using IPSec, a policy is applied to both the sender’s and receiver’s computer, so the systems agree on how data will be encrypted. Other computers that intercept traffic between the machines will be unable to decipher the information contained in the packets.

Print Servers

Files that are being printed may also require protection. IPSec can be implemented to protect the transmission of data being sent to printers. After all, if a document can be captured while being sent to a printer, a hacker can view its information just as if it were being accessed directly from a server.

Physical security issues can be very important for printers. Anyone with access to a printer can remove printed documents from it. This is especially critical for printers that are routinely used to print sensitive documents or financial instruments like checks. A sensitive document may reside on a highly secure file server, but once it is printed, anyone standing by the printer could simply pick it up and walk away. To prevent this from happening, such printers should be located in secure areas that are not accessible to the public and other unauthorized users.

Just as files can have permissions assigned to them, so can printers. Printer permissions are used to control who can print and manage network printing. As shown in Figure 2.28, they are set on the Security tab of a printer’s properties. Using printer permissions, you can allow or deny the following permissions for users:

• Print Allows users to print documents.

• Manage Printers Allows users to perform administrative tasks on a printer, including starting, pausing, and stopping the printer; changing spooler settings; sharing the printer; modifying permissions; and changing property settings.

• Manage Documents Allows users to perform administrative tasks relating to documents being printed. It allows users to start, pause, resume, reorder, and cancel documents.

  
  Figure 2.28: Setting Permissions for a Printer

Although different permissions exist for printing, only the Print permission gives the ability to print a document. For example, when only the Manage Documents permission is given, the user has the ability to manage other people’s documents but cannot send documents to the printer for printing. Because those who manage printers may need to print test pages to determine if the printer is working properly, the Manage Printers permission can be set only if the Print permission is given.

Because the Print permission is assigned to the Everyone group, all users have access to print to a printer once it is shared on the network. For most printers, it’s usually a good idea to remove this permission and add the specific groups within your organization that should have access to the printer.

Securing DHCP, DNS, and WINS Servers

DHCP, DNS, and WINS servers often provide the ability to connect to the network and find other computers. DHCP is used to provide IP address and configuration information to clients. DNS and WINS servers are used to resolve names to IP addresses (and vice versa). If you do not secure these servers, malicious persons and programs may be able to prohibit users from connecting to the network, redirect traffic to other locations, and impact the ability to use network resources.

DHCP servers do not require authentication when providing a lease. Any client that contacts the DHCP server can obtain a lease and connect to the network. In addition to receiving an IP address as part of the lease, clients may also be automatically configured with WINS or DNS server information. To avoid this, it is important that you restrict physical and wireless access to your network. This helps to prevent unauthorized persons from successfully connecting to your network and obtaining a valid DHCP lease. In addition, auditing should be enabled on the DHCP server so that you can review requests for leased addresses. By reviewing the logs, you may be able to identify possible problems.

Just as DHCP is an unauthenticated protocol, so is the NetBIOS naming protocol used by WINS. WINS was designed to work with NetBIOS over TCP/IP (NetBT), which does not require any authentication. Because a user does not need to provide credentials to use WINS, it should be regarded as available to unauthorized persons or programs. These entities could request a massive number of names to be registered or resolved by the WINS server, so that the server becomes bogged down and unable to process other requests. This type of attack is called a denial of service (DoS) and is designed to overload systems and prevent access for legitimate users.

Rogue servers can also be a problem on the network. When a client requests a DHCP lease, it does so by broadcast. If an unauthorized person puts a DHCP server on the network, the incorrect IP address and configuration information could be provided to clients. This isn’t the case if the rogue DHCP server is running Windows 2000 or Windows Server 2003, because these must be authorized in AD. If the server determines that it is not authorized, the DHCP service will not start. However, pre-Windows 2000 and non-Windows DHCP servers require no authorization and can be effectively used as rogue DHCP servers in a Windows Server 2003 environment. Handing out bogus DHCP leases that do not expire can be a very effective DoS technique. Because of this, it is important to monitor network traffic for DHCP server traffic that does not come from your network’s authorized DHCP servers.

Restricting access to DHCP tools and limiting membership in groups that can modify DHCP settings are other important steps in securing a DHCP server. To administer DHCP servers remotely using the DHCP console or Netsh utility, you need to be a member of the Administrators group or the DHCP Administrators group. By restricting membership in these groups, you limit the number of people who can authorize a DHCP server to service client requests.

Test Day Tip

Many people get DHCP, DNS, and WINS confused with one another. Remember that DHCP is used to assign IP addresses to clients, while DNS and WINS are used for name resolution. To avoid confusing DNS and WINS, remember that DNS is the Domain Name System. Remembering its name will help you associate that DNS is used to resolve DNS names to IP addresses and vice versa. Through the process of elimination, this will make it easier to remember that WINS is used to resolve NetBIOS names to IP addresses and vice versa.

Securing Web Servers

Because IIS provides a variety of services that allow users to access information from the Web server service, it provides potential avenues of attack for unauthorized users, malicious programs, and other sources. For this reason, it is not installed by default. If you do not need a Web server on your network, IIS should remain uninstalled. If it has been installed on servers that do not need it, make sure to uninstall it.

Once IIS is installed on Windows Server 2003, it is locked down to prevent any unneeded services from being exploited. By default, IIS will provide only static content to users. If dynamic content is used on the server, you will need to enable the necessary features. For example, if you your site is going to use ASP, ASP.NET, Common Gateway Interface (CGI), Internet Server Application Programming Interface (ISAPI) or Web Distributed Authoring and Versioning (WebDAV), each of these will need to be enabled before they can be used. As with Windows Server 2003 itself, any components that are not needed should be disabled.

Another default setting of IIS is that it will not compile, execute, or serve files with dynamic extensions. For example, if you have Web pages written as ASPs with the extension .asp, IIS won’t provide users with this content. These are not allowed by default because of Microsoft’s new security initiatives. Dynamic content can contain malicious code or have weaknesses that can be exploited. If files that provide dynamic content need to be used on the Web server, you must add the file extensions to the Web service extensions list. Any file types that are not needed should not be added.

An important part of protecting Web servers is using firewalls. Firewalls prevent direct access between a network and clients by having traffic pass through the firewall, which determines if the traffic should be blocked or allowed. In other words, it acts as a buffer between the Web server and clients using it or between the internal network and other networks like the Internet. Rules can be set up on the firewall controlling what kinds of traffic may pass and who can perform certain actions. For example, the firewall might prevent AVI files from being transmitted from the Internet for general users but not administrators. Or, it might prohibit executable downloads to prevent virus-infected files or Trojan horses from being installed on clients.

Securing Database Servers

When securing databases, you should take advantage of security features offered by the database software. Microsoft SQL Server, for example, provides two methods of authenticating clients to access data: Windows Authentication Mode and Mixed Mode. When Windows Authentication Mode is used, the SQL Server administrator has the ability to grant logon access to Windows user accounts and groups. If Mixed Mode is used, users can be authenticated through either Windows authentication or separate accounts created within SQL Server.

Regardless of the authentication mode used, like many database applications, SQL Server allows you to control access to data at a granular level. Permissions can be set to determine the operations that a user can perform on the data contained in the database. In many database applications, you can set permissions at the server, database, or table level. While one account might have the ability to create tables and delete data in all databases, another may only be able to view data in a single database. These permissions are different from those that can be set through AD and NTFS, and they apply only within the database program.

Database servers may also need to be secured through other roles that are used to access the database. For example, IIS is set up through the application role, and Web pages on the server can be used to access data stored in a database. Similarly, applications that are developed and made accessible from a terminal server may be used to view and manipulate database information.

To control access to the database server, you can use settings configured through a data source name (DSN). A DSN is commonly used by compiled and Web-based programs to gain access to data that is stored in data management systems and data files. A DSN contains information on the database name, the server it resides on, and the directory in which it’s stored (if a data file is used). It also holds the username, password, and driver to use when making the connection. Programs use information in the DSN to connect to the data source, make queries, and manipulate data. To create or modify a DSN, use the Data Sources (ODBC) applet (select Start | Administrative Tools | Data Sources (ODBC)).

Because a DSN provides the username and password to use when connecting to the data source, a number of security-related issues arise from its use. Any passwords that are used should follow the recommendations for strong passwords that were discussed earlier in this chapter. In cases where a DSN is being used to connect to a SQL Server database, you also have the option of using Windows authentication or SQL Server authentication. If SQL Server authentication is used, you can enter the username and password of an account created in SQL Server. However, you should avoid entering the name of any accounts with access higher than the user will need. For example, entering the system administrator account (sa) would provide a DSN with full access to SQL Server and could maliciously or accidentally cause problems. To avoid possible damage to data or access violations, you should provide the username and password of a SQL Server account that has restricted access.

Securing Mail Servers

When Windows Server 2003 is configured with the mail server role, it should be set up to require secure authentication from e-mail clients. As mentioned earlier, clients retrieve their e-mail from mail servers using the POP3 protocol. Client software and the mail server’s POP3 service can be configured to accept only passwords that are encrypted in order to prevent them from being intercepted by unauthorized parties.

In Windows Server 2003, the Microsoft POP3 Service uses Secure Password Authentication (SPA) to ensure that authentication between the mail server and clients is encrypted. SPA is integrated with AD, which is used to authenticate users as they log on to retrieve their e-mail. In cases where domain controllers are not used, SPA can authenticate to local accounts on the mail server. When the POP3 service is configured to accept only authentication using SPA, clients must also be configured to use encrypted authentication. If they are not, clients will attempt to authenticate using cleartext (which is plaintext, or unencrypted data) and will be rejected by the mail server.

To prevent mail servers from filling up with undeleted or unchecked e-mail, disk quotas should also be implemented. E-mail can include attachments, which are files that are sent with messages. Over time, mail left on the server can fill up hard disk space and affect server performance. By using disk quotas, users can be limited to a specific amount of hard disk space. Disk quotas can be used only on NTFS partitions. When NTFS is used, permissions can also be set on the directories that store e-mail, preventing unauthorized parties from accessing it on the server.

Securing CAs

In addition to the basic server hardening techniques mentioned earlier in this chapter, a CA needs additional levels of security applied it. Recall that a root CA resides at the top of the hierarchy, with subordinate CAs existing below it. Because the root CA is the most trusted one in a hierarchy, any CAs below it automatically trust it. These subordinate CAs use the root CA’s public key and bind it to its own identity. In doing so, the subordinate can also issue certificates to users and computers.

Because of the trust between root and subordinate CAs, if the root CA is compromised, subordinate CAs continue trusting it. This compromises all certificates issued by the CAs in the hierarchy. As a security measure, you should disable the root CA’s ability to issue certificates online and allow only child CAs to perform this function. An offline root CA is more difficult to compromise, since physical access to it is required.

Additional benefits can be derived from the use of enterprise CAs. When a user requests a certificate from an enterprise CA, that CA is able to validate the information provided by the user through AD. This can provide an extra measure of security. Stand-alone CAs require manual inspection and approval of requests by a CA administrator. Manual processes are typically much more error-prone than automated ones.

When certificates are found to be invalid, they should immediately be revoked. After a certificate is revoked, the CRL should be immediately updated and published. The CRL is used to inform the world of certificates that are no longer valid. If the certificate is invalid, the software used to check it often allows the user to decide whether or not to trust the certificate holder.

Note

Although you can publish a CRL immediately, that does not necessarily mean that all hosts will begin to use the new list. CRLs are cached on local hosts and will not be refreshed until the update period is reached. As a result, the old list that allows invalid certificates will continue to be used until a host checks back in for an update. As an administrator, you can determine how frequently the CRL is updated at the host level. You’ll need to balance your security needs against the network traffic requirements of a CRL update and choose an appropriate interval for your organization.

Securing Application and Terminal Servers

Application and terminal servers are also configurable server roles that need additional steps to ensure that they are secure. Users are able to access applications across the network and execute them on servers using each of these roles. Because of the importance of many network-accessed applications, and the damage that can be done if they are exploited, it is essential that these roles are protected.

Application Servers

Application servers provide access to a wide variety of data on the network, and they need to be hardened using the methods discussed earlier. The tasks users perform on a network often rely on their ability to use specific software and to be assured that all data is secure. To achieve these goals, hard disks storing these applications and the files they generate should be formatted with NTFS.

There is also a need for in-house applications, which are developed by programmers working for the company, to use the latest development tools. Older application development tools may have vulnerabilities that can be exploited. For example, a program developed using an older version of Visual Basic could be decompiled, allowing a hacker to view the code used to create the program. Code generated for in-house applications often contains sensitive information such as server names and authentication information. In addition, older development software is often not able to take advantage of the latest advances in security.

Application servers need to use the general security methods discussed for other servers. They may need to connect to other servers to acquire information or provide services. For example, an application hosted on an application server may use a database server to acquire and process data before returning it to end users. Because the two work in conjunction, the database server must also be secured. Even though the application server might be exceptionally secure, if there are security issues on the database server, the data might be compromised, which can potentially affect the ability of the application to do its job.

Servers configured in the application server role also have IIS 6.0 installed by default. IIS lets the application server provide Web-based applications to users of the network. Because the application server may have a Web server installed on it, steps need to be taken to ensure the Web server is also secure, as discussed earlier in this chapter.

Terminal Servers

Because terminal servers provide access to applications and data, they also need to be configured to ensure that users and hosts do not achieve unauthorized access. By setting permissions on connections, you can control who can access a server and perform specific tasks. This is in addition to the permissions that can be set on files accessed by users in a terminal server session. By limiting access in these ways, you can control who is able to use files and applications and what actions they are able to perform.

Terminal servers can also be configured to use specific levels of encryption. When a communications link is established between a client and the terminal server, the data transmitted between them can be encrypted to prevent others from being able to view and use it. The following encryption levels can be set:

• High This is the default level. It uses 128-bit encryption, which may not be supported by all clients. If clients do not support this level of encryption, they will be unable to connect to the terminal server.

• Low This level provides only one-way encryption. Clients send data to the server using 56-bit encryption, but any data sent from the server to the client is unencrypted.

• FIPS compliant This level encrypts data using Federal Information Processing Standard (FIPS) encryption algorithms and is mandated for use by portions of the U.S government.

• Client compliant This level encrypts data using the strongest possible key strength supported by the client. Because the level of encryption depends on the client, it may be a good idea to use it if legacy clients or a mix of clients are used on the network. However, if you have strong security requirements, this level does not allow you to specify the encryption level clients will use, so it should not be used.

Creating Custom Security Templates

EXAM 70-293 OBJECTIVE 1.3.2

Earlier in this chapter, we discussed how you can use predefined security templates to modify security settings. Although these templates contain settings that can be used for a number of purposes, they may not have the settings you specifically need for your organization. In such cases, you may want to create custom security templates.

You can create custom security templates in a number of ways. As described earlier, modifying the results of an analysis using Security Configuration and Analysis, and then exporting the changes to a new template file, is one way to create a custom security template. In addition, you can create custom security templates using the Security Templates snap-in. The Security Templates snap-in allows you to modify existing templates and create new ones from scratch.

As shown in Figure 2.29, Security Templates consists of two panes. The left pane contains the Security Templates node. When expanded, this node reveals the default template location (%systemroot%\Security\Templates) and the child nodes that contain policy templates. Each policy node contains groups of settings that, when selected, appear in the right pane of the utility.

Figure 2.29: The Security Templates console

To define the settings for a particular policy in the group, right-click the policy in the right pane and selecting Properties. Each dialog box contains different options that are relevant only for that setting. For example, the Properties dialog box for the Maximum password age policy is shown in Figure 2.30. The Define this policy setting in the template check box enables the configurable settings in this dialog box. In the case of the Maximum password age policy, the settings in the Properties dialog box allow you to control the number of days until the password expires. Clicking OK applies any changes you have made to the policy.

Figure 2.30: Setting Maximum Password Age Properties

In addition to modifying existing templates, you can create new templates with Security Templates. Right-click the folder in which you want to store the new template and click New Template. In the dialog box that appears, shown in Figure 2.31, enter a name for the template in the Template name text box. Optionally, you can enter a description in the Description text box. After you click OK, the new template will appear in the list.

Figure 2.31: Adding a New Security Template

When a new template is created, all of the settings in it are undefined. In other words, there are no restrictions set within the template, because all settings are bypassed. To configure security settings for the template, you must go through each node and make the necessary changes to the policy settings, as discussed earlier. Exercise 2.04 guides you through the process of creating a new template and modifying a setting in it.

Exercise 2.04: Creating a New Template Using Security Templates

1. Select Start | Run, type MMC, and click OK.

2. When MMC opens, click File | Add/Remove Snap-in.

3. In the Add/Remove Snap-in dialog box, click the Standalone tab to select it (if necessary).

4. Click the Add button. When the Add Standalone Snap-in dialog box appears, select Security Templates from the list and click Add.

5. Click Close to return to the previous window. A Security Templates entry should appear in the Add/Remove snap-in dialog box. Click OK to close the dialog box.

6. The console tree in the MMC should now contain a Security Templates node in the left pane. Expand this node to display the %systemroot%\ Security\Templates node. (Note that %systemroot% will be replaced with your actual Windows directory location, such as C:\Windows.)

   Expand this node to display all of the security templates that are stored in this directory.

7. Right-click the %systemroot%\Security\Templates node and select New Template from the context menu.

8. In the dialog box that appears, type TestTemplate in the Template name text box, and then click OK to continue. The new template should now appear in the left pane of Security Templates.

9. Expand the TestTemplate node to view the child nodes within it.

10. Expand Account Policies.

11. Click the Password Policy node to display the policy settings it contains.

12. In the right pane, double-click the Maximum password age policy to display the Properties dialog box.

13. Select the check box next to Define this policy setting in the template.

14. Change the value in the Password will expire in box to 90.

15. Click OK. The Suggested Value Changes dialog box will appear. Because the Minimum Password Age value hasn’t been set, this policy will automatically be adjusted to 30 days.

16. Click OK to accept the change, and then exit the Properties dialog box.

17. Select File | Save As.

18. When the Save As dialog box appears, enter a name for this template in the File name text box, and then click Save to save this new template.

Deploying Security Configurations

As mentioned earlier in this chapter, security configurations can be deployed either manually on the local computer or to multiple systems using AD. You learned how to use Security Configuration and Analysis and Secedit tools to apply a security template to a single computer. Also, when you use GPOs to deploy security templates, you must use Active Directory Users and Computers (for GPOs at the domain and OU levels) or Active Directory Sites and Services (for GPOs at the site level).

Computers have local security policies, which reside on the machine and affect only that particular computer. A user who logs on to the computer is subject to the policy settings that have been configured. The security policy can control a wide range of settings, including whether the user’s actions are audited, the resources the user is allowed to use, and whether the user can even access the computer.

GPOs can be applied to any Windows 2000 or later computer that has joined a domain. They can also be applied to user accounts. Security settings configured in GPOs override those made at the local computer level. Because policies can be set at the site, domain, and OU levels in AD, a computer or user may be subject to a wide combination of security settings. Policy settings are cumulative and applied in the following order:

1. Site-level GPOs that affect the computer account

2. Domain-level GPOs that affect the computer account

3. OU- and sub-OU level GPOs that affect the computer account

4. Site-level GPOs that affect the user account

5. Domain-level GPOs that affect the user account

6. OU- and sub-OU level GPOs that affect the user account

By default, all settings applied will be in effect for the user and computer. However, it is also possible that some settings may conflict between GPOs. For example, a site-level policy that applies to the computer may specify a different setting (such as a user right) than an OU setting (the same right, but configured differently) that is applied later. By default, the last setting applied is the effective setting. This means that the OU-level setting would be in effect. Administrators can modify this behavior.

When security settings are applied using GPOs, they do not immediately affect the computer, as local computer policies do. Local computer policies are stored on the computer and take effect immediately. GPO settings are stored in AD and need to be downloaded to the machine. The Group Policy settings are refreshed on computers at regular intervals. Workstations and member servers have group policy settings refreshed every 90 minutes, with a random 30-minute offset (so that all clients do not refresh at the same time and overload the domain controllers). Domain controllers are refreshed every 5 minutes because of their additional security needs. In addition, security settings in GPOs are refreshed every 16 hours, regardless of whether changes have been made to the policy.

If you do not want to wait for an automatic refresh of group policy settings to take place, you can use the gpupdate command to force a refresh. This command replaces the secedit /refresh command that was used in Windows 2000. This command has the following syntax:

gpupdate [/target:{computer | user}] [/force] [/wait:Value]     [/logoff] [/boot]

The gpupdate parameters are defined in Table 2.4.

Table 2.4: Parameters for the gpupdate Command

Parameter	Description
/target:{ computer | user}	Used to specify that just the computer or the user settings should be processed. By default, both are processed.
/force	Used to reapply all settings. By default, only changed settings are applied.
/wait: Value	Used to specify when the command prompt should become available during the processing of group policy settings. When the timeout is reached, processing continues in the background, but the command prompt is made available. Status messages will not be displayed in the console if control of it has been returned by the application. By default, it will wait 600 seconds for policy processing to finish. If 0 is used, the program won’t wait. If –1 is used, it will wait indefinitely.
/logoff	Specifies that the computer should log off the current user if client-side extensions are used in the group policy settings that are refreshed only at logon. An example of such an extension would be those dealing with user-targeted software installation and folder redirection. Some policies, like these, cannot be applied with a background refresh.
/boot	Specifies that the computer should restart if client-side extensions are used in group policy settings that are only applied at bootup. An example is a software installation policy that is applied to the computer. Some policies, like this one, cannot be applied with a background refresh.
/sync	Specifies that the next foreground policy application is to be done synchronously. This type of policy is applied when the computer boots up and when the user logs on.