Exam 70-124: Objective 1.4: Configuring Role-Based Server Security

Configuring server security based on its role has been a topic of great discussion over the past couple of years, although one has to wonder why it took so long to become such an important issue. Not all servers are created equal, and nowhere is this more true than in Windows 2000. It is absolutely critical that you understand not only the functions of your servers but also their vulnerabilities and weaknesses as a result of providing the services that they do.

It has not been uncommon in the last year or two to see almost weekly security bulletins from Microsoft (or more often than not, from an "interested" third party) pointing out a new vulnerability or flaw in some Microsoft product. The most common server products that have been found to have flaws are SQL servers and IIS servers, although almost all the Microsoft Enterprise servers have been found to have some sort of vulnerability or another.

Until recently, you were on your own as to how to lock down a server to make it impervious to attack. All that has changed. Microsoft and several other organizations have taken a very proactive stance toward locking down Microsoft's products. Some of the better and more informative Web sites available to you in your quest to configure effective role-based security can be found at the following sites:

• www.microsoft.com/technet/security/

• http://csrc.nist.gov/itsec/guidance_W2Kpro.html

• http://nsa1.www.conxion.com/win2k/index.html

• www.microsoft.com/technet/security/tools/chklist/w2ksvrcl.asp

Additionally, Microsoft has put together a fairly comprehensive book that includes a good section on configuring role-based security at www.microsoft.com/technet/security/prodtech/windows/windows2000/staysecure/default.asp. Throughout this chapter, we examine some of the templates included in that book and see how they can be used to provide increased, yet still functional, security to your servers.

Test Day Tip 

The additional reference material found at these links is not something you will be expected to know come test day. Instead, it is provided for your own reference. Using this extra information, you can better protect your network from attackers.

Note 

Learn how and where to get the up-to-date news you need to keep your servers patched. Nothing else you can do will keep your servers safe from newly discovered vulnerabilities and attacks (after you've performed their initial configuration, of course). Be sure to regularly visit www.microsoft.com/technet/security/ to make sure you are abreast of the latest security issues concerning your network.

Securing the Domain

The starting place when it comes to configuring effective role-based server security has to be the domain level. After reading Chapter 1, you should now have a pretty good idea of the types of security settings that you can configure and why you might want to implement each one. In the ideal network environment, the application of security settings (via Group Policy) would look something like the process illustrated in Figure 2.1.

Figure 2.1: Configuring Security for the Enterprise

Windows 2000 Domain Controllers

Perhaps the crown jewel of the domain, domain controllers definitely need (and deserve) special treatment when it comes to configuring role-based security. By their very nature, domain controllers have an entirely different set of needs and concerns than any other server on the network. Let's examine some of the concerns associated with domain controllers and then how you can secure them effectively.

By default, when Active Directory is initialized for the first time in your domain, the Domain Controllers OU is created. Active Directory places all domain controllers into this OU, and they should never be moved to any other OU, because very specific ACLs are applied to this OU. Because the Domain Controllers OU (see Figure 2.2) is a top-level OU, it will be unaffected by the policies that we later apply to our member servers. For this reason, domain controllers must have their own specific security policy applied.

Figure 2.2: The Domain Controllers OU

Note 

You need to be aware of the potential problems that you could run into should you decide to apply the securedc.inf or hisecdc.inf template to your domain controllers if you do not plan properly. You will lose connectivity with legacy clients in your organization that are not using the Directory Services Client (DSClient) software, because they will not be able to use NTLMv2. Furthermore, you could have other issues crop up if you do not plan carefully. Never jump into configuration changes on any server, especially your domain controllers, without adequate preparation and a solid backout plan.

By default, the basicdc.inf security template is applied to all domain controllers. In some instances, this basic and low-security template might be adequate to meet an organization's needs, but it is not recommended for the majority of organizations-especially those that have an active connection into their network from the outside, whether via remote access provided to employees or an Internet connection for company and public use.

At a minimum, you should strongly consider applying the securedc.inf security template to your domain controllers by following the steps of Exercise 2.01.

Exercise 2.01: Securing Domain Controllers

1. From a domain controller, open your Security console that you created in Chapter 1.

2. Using Security Configuration and Analysis, open a new database and import the securedc.inf template.

3. Analyze the domain controller as discussed in Chapter 1 and note the differences, as shown in Figure 2.3. You can perform this process using either Security Configuration and Analysis or secedit.

   
   Figure 2.3: Inspecting the Changes Before They Are Made

4. Open the Active Directory Users and Computers console.

5. Right-click the Domain Controllers Organizational Unit. Select Properties from the context menu, and switch to the Group Policy tab.

6. Create a new Group Policy Object, naming it something intuitive such as Secure DC policy.

7. Edit the newly created GPO. Navigate to the Computer Configuration | Windows Settings | Security Settings node and right-click it. From the context menu, select Import Policy, as shown in Figure 2.4. Select the desired policy-in this case, securedc.inf template.

   
   Figure 2.4: Importing the Template

8. Looking at the settings in the GPO, now you can see that the settings have been loaded into the GPO.

9. Close the Group Policy editing window and the Active Directory Users and Computers console.

10. To force policy replication immediately, use the secedit /refreshpolicy machine_policy command from the command line as discussed previously in Chapter 1. Note that it can take several minutes to several hours for the changes to replicate, depending on the size and complexity of your network.

By applying the securedc.inf template, you made the following changes to the security configuration of the domain controllers in your network:

• Stronger password, account lockout, and auditing settings

• Servers (including domain controllers) configured to ignore LAN Manager responses and to use only NTLMv2 responses

• Users in the domain will not be able to connect to any member server from a client computer using LAN Manager (Windows 9x without the Directory Services Client Pack installed)

• SMB packet signing configured, providing a higher level of security

Should you desire to strengthen your domain controller security even further, you can optionally apply the hisecdc.inf security template. As mentioned earlier, the Security Operations for Windows 2000 Server, located at www.microsoft.com/technet/security/prodtech/windows/windows2000/staysecure/default.asp, has some additional configuration changes you can make to domain controllers, including a custom domain controller policy. The same is true for the National Security Agency (Big Brother really is watching over your shoulder now!) at http://nsa1.www.conxion.com/win2k/index.html. One last thing you can do to secure your Windows 2000 domain controllers is to ensure that they are always up to date with the latest service packs and hotfixes.

Exam Warning 

Pay special attention to the details that you are given to work with during the exam, especially when you have to choose between several similar options or an option that will produce undesired results. You especially need to pay attention when you're applying secure templates to your servers and domain controllers.

Member Servers

Member servers are the most frequently attacked targets on a typical Windows 2000 network. This should come as no surprise when you consider the number of different roles that a member server can play, including, but not limited to:

• SQL server

• Exchange server

• IIS server (Web, FTP, and NNTP)

• File server

• Print server

• RRAS server

• IAS server

The true difficulty in locking down all your servers is in understanding the different nuances and peculiarities associated with each server. Unfortunately gone are the days when one set of configuration settings was good enough and could be applied evenly across the network. Between flaws in the code and malicious attackers seeking to gain entrance through any means possible, your member servers really require the most work of any computers on your network when it comes to protecting them.

Windows 2000 ships with several security templates for workstations, as you saw in Chapter 1. The securews.inf and hisecws.inf templates can be used on member servers of all types (and workstations for that matter) to tighten up the basic security that is installed by default with the basicsv.inf template. However, specific server roles require additional security measures, even beyond using these two incremental security templates. Microsoft has recognized this need and provided additional templates for several different types of member servers, including Exchange servers and IIS servers; the NSA has done the same thing for generic member servers and IAS servers.

SQL Server 2000

The starting point for securing a SQL Server 2000 installation is to ensure that you've got your SQL server up to date with the latest service pack and hotfixes. At the time of this writing, Windows 2000 Service Pack 3 and SQL Server 2000 Service Pack 2 were the latest available. After applying the latest service packs, it is strongly recommended that you download and run the IIS Lockdown tool from www.microsoft.com/Downloads/Release.asp?ReleaseID=33961 and the Microsoft Baseline Security Analyzer (MSBA) from http://support.microsoft.com/default.aspx?scid=kb;en-us;Q320454&sd=tech. No one has publicly released a specific security template for SQL servers, so it's up to you to ensure that you have done all your homework on that front.

Notes from the Underground…
Buffer Overrun Heaven

SQL Server 2000 has become rather famous over the last year or two for the seemingly endless string of buffer overruns it has suffered. A buffer in a program is a place that the developer has set aside for the temporary storage of incoming or outgoing data, much like your e-mail in-box. Items come in and then can be distributed as required. A buffer overrun occurs when more data is put into a buffer than it was designed to hold. The problem lies in the fact that the extra data will continue to write over the next blocks of memory, erasing the contents that were there. This becomes a security issue when an attacker can successfully deliver a string of data that is sufficiently long to start overwriting memory areas where the program expects to find valid code. Instead, the application unknowingly executes carefully crafted code that the attacker had placed into the server's memory using a buffer overflow.

What makes buffer overflows particularly dangerous and difficult to control? A large application can have literally thousands if not tens of thousands of buffers, and any one of them is subject to a programming error that is just waiting to be exploited.

Exercise 2.02 walks you through the process of running the IIS Lockdown tool on an SQL server; Exercise 2.03 tackles running the MSBA against the SQL server.

Exercise 2.02: Locking Down SQL Server with the IIS Lockdown Tool

1. Download and execute the IIS Lockdown tool locally on the SQL server computer.

2. Click Next to dismiss the Wizard opening page.

3. Agree to the license agreement and click Next to continue. (You won't be able to continue without agreeing to the license.)

4. Its safe to say that about 99 percent of SQL servers have no need to have IIS services running. Therefore, you can select the Server that does not require IIS option from the Select Server Template page as shown in Figure 2.5. Click Next to continue.

   
   Figure 2.5: Selecting the Type of Server to Lock Down

5. On the next page, you will be presented with a summary of the actions to be carried out. In this case, all IIS services will be stopped and disabled on the SQL server. Click Next when you are ready to continue.

6. You can watch the progress of the tool, as shown in Figure 2.6.

   
   Figure 2.6: The IIS Lockdown Tool Making Configuration Changes

7. After the IIS Lockdown tool has finished, click Next and then Finish to close the wizard. You have now taken the first step in securing an SQL Server 2000 computer by disabling all IIS services.

After you've done the initial groundwork of running the IIS Lockdown tool against your SQL server, the next thing you should consider doing is to perform a scan of the SQL server using the MBSA tool. The results of the scan will enable you to further harden the server against attacks.

Exercise 2.03: Hardening the SQL Server with the Microsoft Baseline Security Analyzer

1. Download and install the Microsoft Baseline Security Analyzer onto the SQL server computer. (Alternatively, you can run it from any computer in the domain.)

2. Launch the MSBA tool and click Scan a computer.

3. Enter the computer information as required on the Pick a computer to scan page (see Figure 2.7) and click Start scan. By default, all selectable options are selected, although if you desire, you can deselect them, which will result in a less than optimal scan and is not recommended.

   
   Figure 2.7: Configuring the Scan Parameters

4. The scan can take several minutes to complete, depending on the particular computer being scanned. If you are asked to install any downloads as shown in Figure 2.8, you need to allow the install to proceed in order to complete the scan.

   
   Figure 2.8: Installing Required Updates

5. When the MBSA tool has finished, you will receive a formatted HTML output like that shown in Figure 2.9. As you can see, we have quite a bit of work to do to harden this server in several categories.

   
   Figure 2.9: Getting the MBSA Scan Results

As you can see, the bulk of the process of securing an SQL server is to ensure that it is properly updated in regard to service packs and hotfixes. After this has been done, you can use the IIS Lockdown tool and the MBSA tool to further harden the server. As part of the ongoing maintenance of your SQL servers, you should make a point to run the HFNetChk tool at least weekly. You can get the tool at www.microsoft.com/technet/security/tools/tools/hfnetchk.asp. Exercise 2.04 walks you through using the HFNetChk tool to scan your SQL server.

Exercise 2.04: Routine Maintenance with the HFNetChk Tool

1. Download and install the HFNetChk from www.microsoft.com/technet/security/tools/tools/hfnetchk.asp onto the SQL server computer. (Alternatively, you can run it from any computer in the domain if you will be using it as part of a script.)

2. Open a command prompt and change to the location of the extracted HFNetChk files on your computer.

3. Enter the hfnetchk command.

4. If you are asked to install any downloads, you need to allow the install to proceed in order to complete the scan.

5. The results are presented on screen as shown in Figure 2.10. Again, we have a lot of work do here. Alternatively, you can save the results of the scan to a text file by using the command hfnetchk -f filename.txt. This step can be particularly helpful when you are using the tool as part of a script across several computers.

   
   Figure 2.10: Getting the HFNetChk Results

Exchange 2000 Server

The process of securing Exchange 2000 servers is almost identical to that of securing SQL 2000 Server computers. You need to ensure that the most up-to-date service packs and hotfixes are applied to your domain controllers, Exchange 2000 servers, and Global Catalog servers. As of this writing, both Windows 2000 and Exchange 2000 Server are in Service Pack 3. Exchange 2000 Conferencing Server is in Service Pack 2.

After you have applied all required updates and fixes, you should then proceed to follow the same process as outlined for SQL servers: first running IIS Lockdown tool, then running the MBSA tool, and lastly running the HFNetChk tool. The procedures for using the MBSA and HFNetChk tools are identical to those outlined in Exercises 2.3 and 2.4, respectively. Because Exchange 2000 Server makes extensive use of IIS, the process to run the IIS Lockdown tool is different and is discussed in Exercise 2.05.

Exercise 2.05: Locking Down Exchange Server with the IIS Lockdown Tool

1. Download and execute the IIS Lockdown tool locally on the SQL server computer.

2. Click Next to dismiss the wizard opening page.

3. Agree to the license agreement and click Next to continue. (You won't be able to continue without agreeing to the license.)

4. Select the Exchange 2000 Server option from the Select Server Template page, as shown in Figure 2.11. If you want to manually configure the IIS services that get disabled and those that stay available, place a check in the View template settings check box. Click Next to continue.

   
   Figure 2.11: Selecting the Type of Server to Lock Down

5. On the next page, you be presented with a listing of the services to leave running on the server (see Figure 2.12). The role of the Exchange 2000 server will determine which services you need to leave running. For example, if you do not use newsgroups on your internal network, you can safely disable the NNTP service. If you are not using Outlook Web Access, you can also safely disable the HTTP service. Click Next when you are ready to continue.

   
   Figure 2.12: Selecting the Services

6. Depending on what services you leave running, the next few pages you see will vary. Configure your selections and click Next to continue through the pages.

7. After the IIS Lockdown tool has finished, click Next and then Finish to close the wizard. You have now taken the first step in securing an SQL Server 2000 computer by disabling all IIS services.

Additionally, the Security Operations for Windows 2000 Server, located at www.microsoft.com/technet/security/prodtech/windows/windows2000/staysecure/default.asp, has two customized security policies that you should consider applying to your Exchange 2000 servers. Exchange BackEnd Incremental.inf for back-end Exchange 2000 Servers (the ones not typically requiring HTTP) and OWA FrontEnd Incremental.inf for front-end Exchange 2000 Servers acting as Outlook Web Access servers are provided and should be implemented across all your Exchange 2000 servers as appropriate.

Windows 2000 Internet Information Services Servers

Perhaps the most commonly attacked and the most difficult Windows 2000 member server to secure is the IIS server. Let's face it-whenever you are voluntarily putting information into an untrusted public network like the Internet, you are opening yourself to attacks from all directions. There really is no way to dispute this fact. You can, however, take positive steps toward securing your IIS servers to prevent them from being attacked and compromised, possibly opening the door to the rest of your network.

To start, you should again make a point of ensuring that you have the latest service pack and hotfixes on all IIS servers. After that, you should perform the following sequence of actions, in this order:

1. Run the URLScan tool (see Exercise 2.06). The URLScan tool is an ISAPI filter that is installed at the global level (protecting an entire IIS server) and analyzes HTTP requests as they are received by IIS.

2. Run the IIS Lockdown tool (see Exercise 2.07).

3. Check for any current IIS updates at www.microsoft.com/technet/security/current.asp.

4. Follow the guidelines of the Secure Internet Information Services 5 Checklist at www.microsoft.com/technet/security/tools/chklist/iis5chk.asp (see Exercise 2.08).

5. Run the MBSA tool.

6. Run the HFNetChk tool.

Exercise 2.06: Locking Down IIS Servers with the URLScan Tool

1. Download the IIS Lockdown tool to the IIS computer of concern.

2. Open a command prompt and switch to the location of the iislockd.exe file.

3. Enter iislockd /c to extract the IIS Lockdown files, including the URLScan tool, to the directory of your choosing, as shown in Figure 2.13.

   
   Figure 2.13: Selecting the Location for the Extracted IIS Lockdown Files

4. Execute the URLScan tool from the location to which you extracted it.

5. URLScan will configure your server to be more secure by limiting the types of methods that can be used (such as GET and POST) and the extensions that are allowed and disallowed. The settings are stored in the %windir%\system32\inetsrv\URLScan directory in the urlscan.ini file. A log called urlscan.log is also maintained in that location.

6. Looking at the global properties for the IIS server (see Figure 2.14), you can see the URLScan ISAPI filter is installed with high priority. Note that ISAPI filters installed at the global level, although still applying to all sites on the server, will not be shown in the Properties page for each virtual server.

   
   Figure 2.14: URLScan Is Active and Protecting the IIS Server

After applying the URLScan ISAPI filter to your IIS server, the next step you need to take is to lock down the IIS server with the IIS Lockdown tool. The procedure to do this task is similar to that of the other servers you might have used IIS Lockdown on, but you should pay attention to some additional configuration options to ensure that you get your IIS server locked down exactly as you need it, with minimal loss of functionality. Exercise 2.07 discusses the procedure to lock down a dynamic (ASP) IIS server using IIS Lockdown.

Damage & Defense…
The Importance of Updating IIS

For several years now, vulnerabilities have been identified in the way that IIS handles Unicode translation. This situation has prompted quite a few security bulletins from Microsoft, yet administrators in many cases simply keep moving along, paying no attention to the problems that exist on their systems. Why do most of the Windows 2000 systems that are compromised get compromised? The reason is failure of administrators and other IT personnel to ensure that their systems are secure and up to date with all required patches and hotfixes.

One of the most famous IIS Unicode exploits was first announced in Security Bulletin MS00-078 and involved the way that IIS interpreted the Unicode equivalents of the forward slash and backslash characters (/ and \). Because IIS did not correctly interpret the Unicode equivalents of these characters, an attack could traverse directories on the server by using the double dot (../). For this reason, an attack could access files stored locally on the server in the context of the IUSR_computername account, which is a built-in account on IIS servers that is a member of the Everyone and Users groups by default-files that they should not and normally would not be able to access otherwise. By sending a malformed URL to the IIS server, such as http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir, an attacker can get out of the Web root directory and modify and delete files on the IIS server and otherwise wreak havoc on the server. In this case, Microsoft released both the URLScan tool and a hotfix that is available at www.microsoft.com/windows2000/downloads/critical/q269862/default.asp. Of course, if you have since applied Service Pack 2 or Service Pack 3, this fix is included.

This type of vulnerability is not the first nor will it be the last to be discovered and exploited in a Windows product. Your best course of action is to always keep up to date on new developments in the security field. The Security Focus Online Web site, at http://online.securityfocus.com/, is a good starting point, as is the NTBugTraq located at www.ntbugtraq.com. Nowhere is it more true that knowledge is power than when we're dealing with computer security.

Exam Warning 

It's important to understand how URLScan works to protect your IIS servers against many common types of exploits and vulnerabilities. More so, you should understand how to customize a URLScan installation to allow or disallow specific types of traffic as your organizational needs dictate.

Exercise 2.07: Locking Down IIS Servers with the IIS Lockdown Tool

1. Download and execute the IIS Lockdown tool locally on the IIS server computer.

2. Click Next to dismiss the Wizard opening page.

3. Agree to the license agreement and click Next to continue. (You won't be able to continue without agreeing to the license.)

4. Select the Dynamic Web Server (ASP enabled) option from the Select Server Template page, as shown in Figure 2.15. Since we are going to examine all the available options when configuring the server using IIS Lockdown, place a check in the View template settings check box. Click Next to continue.

   
   Figure 2.15: Selecting the Type of Server to Lock Down

5. On the Internet Services page (see Figure 2.16), you have the option to configure the services that will remain running on the IIS server. In most cases, you only need HTTP, and that is the presumption that we use to continue the rest of the process. After selecting Web service (HTTP), click Next to continue.

   
   Figure 2.16: Selecting Services to Remain Enabled

6. On the Script Maps page (see Figure 2.17), you are asked to choose types of scripting you will allow on the IIS server. Since this is a server that has dynamic ASP content, we need to uncheck at least ASP. Other commonly used scripting includes Server Side Includes (SSI) SHMTL, SHTM, and STM. After making your choices, click Next to continue.

   
   Figure 2.17: Configuring Script Mapping

7. The Additional Security page (see Figure 2.18) presents you with some even more granular configuration options to increase the security of the IIS server. The ones you choose to leave enabled depend on exactly what you are doing with the IIS server. For example, if you need to allow users to edit and save documents remotely using applications such as Microsoft Word or Microsoft Excel, you would leave WebDAV enabled. After making your choices, click Next to continue.

   
   Figure 2.18: Configuring Additional Security Options for the IIS Server

8. The next page, the URLScan page, asks you if you want to install the URLScan ISAPI filter. If you have not already done so (as outlined in the previous exercise), select URLScan to be installed. Otherwise, deselect it. After making your choice, click Next to continue.

9. The Ready to Apply Settings page (see Figure 2.19) summarizes the choices you have made. If all is well, click Next to continue or click Back to change the settings you have configured.

   
   Figure 2.19: Ready to Apply Settings

10. The Applying Security Settings page informs you as to the progress of the configuration changes. When all the changes have been made, click Next to continue. If you want a more detailed report, click the View Report button to open the log file.

11. Click Finish to close the IIS Lockdown tool.

At this time, your IIS server is fairly secure, but more work still remains to be done. You should now check for current (and outstanding) IIS updates that your IIS server might need to have applied. Do this by checking the security homepage on TechNET at www.microsoft.com/technet/security/current.asp. After you've checked the homepage-a task that you should repeat monthly, if not more often-you can move to the next step in the process of locking down your IIS server.

Realizing the strong need for guidance on securing IIS, Microsoft has provided several guides to help you go about getting your IIS server as secure as it can be. The Secure Internet Information Services 5 Checklist at www.microsoft.com/technet/security/tools/chklist/iis5chk.asp is an excellent guide that should be used by any administrator running IIS on a server.

Microsoft has created two customized security templates for IIS servers. The one you use depends on your needs and how your IIS server responds after you've tested the template in a lab environment. The Security Operations for Windows 2000 Server, located at www.microsoft.com/technet/security/prodtech/windows/windows2000/staysecure/default.asp, provides a baseline incremental template called IIS incremental.inf that you might consider applying. Should you find that the settings in this template are not quite secure enough for you, you can find another, more secure template located at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q316347 that Microsoft designed to completely secure IIS servers. Do not apply this template to a domain controller running IIS; unexpected and unwanted things will most certainly happen. In addition, as with all templates and configuration changes, you should first thoroughly test this one in a safe lab environment to determine how your IIS applications will respond once it has been applied.

Test Day Tip 

You need not worry about seeing any questions dealing with these custom-created IIS templates or the IIS check list. These resources are provided for your use so that you can lock down your IIS servers as much as possible beyond what is included in Windows 2000 by default.

Head of the Class…
Watch Where You Assign Blame

It really cannot be stressed enough how vulnerable your IIS servers are if you take no proactive action at all. It might not be completely fair to say that Windows 2000 is a hacker's favorite target, but it is not far from the truth. The issue lies not in the fact that Windows 2000 is an inherently insecure operating system, as many would like to believe; all applications, operating systems included, are likely to have flaws and problems. This holds true of Windows, UNIX, Linux, MAC OS, and every other operating system and application in production.

The true problem lies in the fact that many administrators simply do not understand or care to understand the necessity of keeping servers and workstations up to date with new patches and updates as they appear. Some of the fixes are put out because of programming errors that could have been prevented, but a good many of them are released in response to newly discovered attacks and vulnerabilities in the product. No product is perfect, software included, and thus people who have the means and the desire will continue to find ways to penetrate systems. Your job is to stay up to date with the fixes and updates that are issued and ensure that they are tested and deployed in a timely, organized fashion. Anything less equates to sleeping at the wheel.

After you've completed all the previous steps, you are still not quite out of the woods. Now you are in maintenance mode. You should take the time to run the MBSA tool against your IIS server to see if anything has been missed, such as a weak password or a user account that should not be enabled. You'd be amazed at the things that you can miss when configuring an IIS server. Your last, and ongoing, step should be to run HFNetChk against the server to ensure that you really have gotten all the Ts crossed and the Is dotted.

Windows 2000 Internet Access Service Servers

Internet Access Servers (IAS) should be treated the same as most other member servers. You need to look at the same things to maintain the server in its most secure form:

• Up-to-date service packs and hotfixes

• IIS Lockdown tool

• MBSA tool

• HFNetChk tool

Test Day Tip 

You shouldn't expect to receive any specific types of questions dealing specifically with IAS servers on your exam. Rather, you need just to understand the basic concepts that we have been discussing throughout this chapter in regard to the fact that each member server is different from every other member server, and no two member server roles should be approached from the same point of view when it comes to configuring security.