InformIT

ISA Security Concepts - Part I

Date: Feb 22, 2002

Sample Chapter is provided courtesy of Sams.

Return to the article

This sample chapter focuses on topics such as the ISA Server Security Configuration wizard. This wizard enables you to tighten your security considerably. Read on to explore site and content rules in detail. Rules enable you to control the flow of traffic to meet your security needs. They determine which computers, users, or applications should be able to access resources on your network. Also, Virtual Private Networks (VPNs) are supported in ISA Server. This chapter covers configuring both ends of a VPN tunnel using the ISA Server wizards.

Zubair Alexander specializes in design, implementation, and engineering of enterprise network services. For more information on all of his publications, visit his Web site at www.techgalaxy.net.

This sample chapter is excerpted from Microsoft ISA Server 2000.

As one might expect, security concepts will get a lot of coverage in an ISA Server book. Because we have a large number of important items to cover, the ISA Server security concepts are broken down into two chapters in this book: Chapter 3, "ISA Security Concepts Part I," and Chapter 4, "ISA Security Concepts Part II."

ISA Server can be implemented as a dedicated firewall to protect your local area network from potential intruders on external networks. You can configure rules and filters that prevent unauthorized users from entering your network, and you can limit the access of authorized users to only the contents that they should be accessing, thus securing your valuable corporate resources.

In this first of two security chapters, we will focus on topics such as the ISA Server Security Configuration wizard. This wizard enables you to tighten your security considerably. We will explore site and content rules in detail. Rules enable you to control the flow of traffic to meet your security needs. In other words, they determine which computers, users, or applications should be able to access resources on your network. Rules can be configured for both inbound and outbound traffic. We will also discuss the support for Virtual Private Networks (VPNs) in ISA Server. You will learn how to configure both ends of a VPN tunnel using the ISA Server wizards. Later in this chapter, you will also find a comparison of existing security solutions.

When discussing security and firewalls, it's hard not to talk about demilitarized zones (DMZs). A DMZ provides an extra layer of protection against outside attacks. In this chapter, first you will be presented with an overview of DMZs, followed by an explanation of a couple of common DMZ scenarios in use today.

After exploring the security items found in this chapter, move on to Chapter 4, "ISA Security Concepts II." The primary focus of this chapter will be on packet filtering. You will learn the fundamentals of packet filtering, including the creation and application of filters. You will also be presented with the application filter concepts.

Emphasizing Network Security

As a person responsible for securing your network, it is probably no surprise that you have to be security conscious from the get go. Some administrators leave their system unprotected in the beginning while they slowly work on different aspects of their system. Needless to say, this could be a huge security risk.

Let's take a real-world scenario that's more common than a lot of folks realize. As you may know, businesses that have standardized on Compaq's servers can use Compaq's Web-enabled management software to manage their systems. The wide range of components that can be managed includes RAID configurations and free hard disk space to IP addresses and serial numbers. You can even restart the server remotely and get into the management tools.

Well, you say, that sounds pretty cool. So what's the problem? Well, the problem is that some newbie administrator may not realize that Compaq's management software running any Web-based management tool on port 2301 can act as a proxy server. This could potentially leave the server wide open to folks on the Internet, unless the administrator changes the default configuration before connecting the server to the Internet. With the default username (administrator) and password (administrator) known to everyone, hackers can have anonymous access to the server. By the way, Compaq has a security patch available for Windows NT 4.0 and Windows 2000 to fix the problem with the Web-enabled management software. The patch is available at http://www.compaq.com/support/files/server/us/download/9608.html.

If you don't take precautionary measures to secure your network devices, you are taking a risk. Change the default passwords on systems before you put them in production; don't enable services unless you have properly configured them; don't share folders unless you've set the permissions; don't enable Web sites unless you've configured proper authentication—you get the point. Take security seriously, go through the security checklists, and be overly cautious. Now, let's explore the security options ISA Server offers you as you plan and implement a security system to protect personal and/or corporate data and servers.

Running the Security Wizard

To begin, you need to be aware of the ISA Server Security Wizard. With this handy wizard you can tighten your security on all the servers in an array. Keep in mind that running this security wizard is one way to secure your network—it is not the only way. The ISA Server Security Wizard is a good place to start securing your network, but we will cover other methods that can be used with this wizard to help lock down your network infrastructure effectively.

There are three levels of security that are available using the wizard, as explained here:

TIP

I have seen some administrators use this wizard and then complain about their ISA Server getting "messed up." The wizard makes literally dozens of changes to the registry, file permissions, and user rights. My recommendation is that you read and understand the information in the security templates before you implement them.

Table 3.1  ISA Server Security Configuration

Security Level

Windows 2000 Server Security Templates

Windows 2000 Domain Controller Security Templates

Dedicated (highest level)

hisecws.inf

hisecdc.inf

Limited Services (medium level)

securews.inf

securedc.inf

Secure (lowest level)

basicsv.inf

basicdc.inf

Now that you have been given some background and specific warnings, let me tell you about my general philosophy about such wizards. Frankly, security wizards make me nervous and I don't always trust them. I am not convinced that the wizards will only make the changes that they are supposed to make. Why is it that a wizard can make the configuration changes one way, but won't let you undo those changes? I don't mind using wizards for certain tasks, but using wizards to secure my server is not my cup of tea.

CAUTION

The ISA Server Security Configuration Wizard doesn't have an "undo" feature. Before you run the wizard, make sure you've backed up your operating system and ISA Server configuration. The Security Wizard, among other things, modifies numerous operating system registry settings, which makes reverting back to the original configuration a very time consuming and difficult task. ISA Server lists the configuration changes to a file called securwiz.log in the ISA Server installation folder, but the log only tells you that it changed the setting, it doesn't tell you what exactly the change was.

To configure the appropriate security level, use the following procedure:

WARNING

If you just go by the name, it may seem that the Secure level is the most secure of the three choices, but in fact it is the least secure level. The Dedicated level offers the highest security, the Limited Services offers a medium-level security, and the Secure level offers the lowest level of security among the three.

Once you are satisfied with the level of protection that is appropriate for your servers (for instance, by running the ISA Server Security Configuration Wizard), you can then configure additional security options by establishing ISA Server rules. This provides even greater control at a more detailed level over your network traffic.

ISA Server rules are generally used to control outgoing traffic from the internal network to the Internet. In the next chapter we will explore IP packet filters, application filters, and intrusion detection filters, all of which are used to control incoming traffic. Now let's examine the ISA Server rules.

ISA Server Rules

The ISA Server rules determine what network resources client machines are permitted to access. You configure rules to control incoming traffic from the Internet to your internal network, and outgoing traffic from your internal network to the Internet. However, the rules are primarily used for managing inbound traffic.

There are several types of rules supported by the ISA Server. These rules include access policy, bandwidth, protocol, routing and chaining, scheduling, server publishing, site and contents, and Web publishing rules. The following sections will explore the site and content, protocol, bandwidth, and publishing rules.

Site and Content Rules

Site and content rules are used to allow or deny clients access to certain contents on the Internet. This rule works in conjunction with the protocol rules. In other words, clients are allowed access if the site and content rule specifically allows access. However, even if the site and content rule allows the client to access the contents, you still need to create a protocol rule, as you will learn more about in a moment, that allows the client to communicate using that protocol.

If you configure two conflicting rules, one that allows access and the other that denies access, the "deny rule" takes precedence and is processed first. Let's say as an IT manager you configure a couple of site and content rules. Rule #1 allows only the managers to access certain contents. Rule #2 denies all employees access to the same contents. As a manager, you will not be able to access the contents because the "deny rule" will be processed first.

When dealing with arrays, you can create site and content rules both at the enterprise level and at the array level. When you enable the array-level rules, they add additional restrictions to the existing enterprise-level site and content rules. For example, let's say that you are using an enterprise policy that permits all employees to use ICQ Chat at all times. You can configure a site and content rule at the array level that permits temporary employees to use ICQ Chat only during lunch hours, which will further restrict the existing enterprise policy. When you apply an enterprise policy to an array, you can only add deny rules at the array level, which simply gives you the capability to apply additional restrictions at a lower level.

Site and content rules are useful in applying various kinds of restrictions or granting different levels of permissions to the clients. For example, you can decide whether a site and content rule applies to all destinations, all internal destinations, all external destinations, to a certain destination set; or you can configure an exception rule so that it can apply to all destinations except the one you list. The rules either "allow" or "deny" access to destinations.

You can also decide at what times the rule should be in affect by using a predefined schedule. For example, you can apply the rule only to weekend or weekday hours. In addition, the rules can be applied to certain client address sets, to specific users or groups, or to any request. If that's not enough, you can even control the content groups to which the rules are applied. For example, the rules can be applied to only certain types of contents, such as macro documents or applications.

With this level of control, you can come up with all kinds of options to either deny or permit only certain users to access specific objects, at specific times, from specific locations. For example, you can restrict a group of contractors from downloading videos and images from external Web sites during 8:00 a.m. and 9:00 a.m. when the traffic is heavy on your network. As another example, you can create a rule that permits only employees in the IT department to download applications, but limit them from downloading the files only after hours or weekends. You could create an exception that enables the IT manager or the network administrator to download the files at any time.

Now that you have a better understanding of what the rules are used for, you will learn how to configure them.

Let's say you want to configure a rule that will enable your internal clients to access all contents on the Internet at all times. To configure such a site and content rule for the enterprise policy, use the following procedure:

  1. In the ISA Server Management console, click on Enterprise, Policies, <your enterprise policy>, Site and Content Rules.

  2. Right-click the Site and Content Rules and select New, then click on Rule to start the New Site and Content Rule Wizard.

  3. Enter a name for the rule, for example Internet Access, as shown in Figure 3.1. Notice that there is a note warning you to create new policy elements that may be required by the rule before using the wizard. You might have to create a destination set, a client address set, a schedule, and a content group.

  4. Figure 3.1 The New Site and Content Rule Wizard.

  5. On the Rule Action screen, select Allow.

  6. On the Rule Configuration screen, you will use the default selection Allow Access Based On Destination, as shown in Figure 3.2. If you don't specify clients or a schedule on this screen, the rule you create will be applicable to all the clients.

  7. Figure 3.2 Rule configuration for the site and content rule.

  8. On the Destination Sets screen, decide how you want to apply this rule. Select All Destinations (the default option), but notice the other options listed in the drop-down box.

  9. Click Finish on the final screen to complete the wizard.

Figure 3.3 shows the rule you just created inside the ISA Management console. Notice in the right-hand pane that the rule applies to the enterprise and allows any request to access all contents at all the destinations all the time.

Figure 3.3 The site and content rule at the enterprise level.

To configure a site and content rule at the array level, you will go through the same process as described previously.

Protocol Rules

Protocol rules are used to control clients' access to the Internet. They can allow or deny use of protocol definitions and can apply to either all or selected IP traffic. ISA Server comes with several common protocol definitions. You can add additional protocols to customize your environment.

As mentioned earlier, the protocol rules and the site and content rule work hand in hand. Remember from our earlier discussion that even if the site and content rule enables the client to access the contents, you still need to create a protocol rule that enables the client to communicate using that protocol.

TIP

When you disable an application filter, its protocol definition is no longer available to the client. In other words, clients using that protocol definition will be denied access.

Similar to the site and content rules, the rules that deny protocols are processed before the rules that allow access.

Let's say you want to create a protocol rule for a group of temporary employees that denies them access to ICQ 2000 chat during business hours. Here's how you will configure the rule.

  1. In the ISA Server Management console, click on Enterprise, Policies, <your enterprise policy>, Protocol Rules. For an array policy, you will go to Servers and Arrays, <your server name>, Access Policy, Protocol Rules.

  2. Right-click Protocol Rules and select New, then click on Rule to start the New Protocol Rule Wizard.

  3. Enter a name for the rule on the first screen; for example ICQ 2000.

  4. On the Rule Action screen, choose Deny.

  5. On the Protocols screen, select an option from the drop-down box to apply the rule. We will select Selected Protocols, as shown in Figure 3.4, because we only want to deny the TEMPS Group from accessing the ICQ 2000 protocol during work hours. Check the ICQ 2000 box. (Also note in Figure 3.4 the list of protocols to choose from.) If you need something other than Selected Protocols, some of the other options you can choose from are as follows:

  6. Figure 3.4 Configuring the protocol to which the rule applies.

  7. On the Schedule screen, select Work Hours from the drop-down box. The other options are Always and Weekend.

  8. On the Client Type screen, select Specific Users and Groups.

  9. In the Users and Groups screen, add the TEMPS group.

  10. Click Finish on the final screen to complete the wizard.

After you have created the rule, you can double-click the rule to access its properties. On the Schedule tab, you can customize the hours for the TEMPS group. The default hours are Monday through Friday 9 a.m. to 5 p.m.

You can create additional schedules by clicking on the New button. This brings up the new schedule window that shows the TEMPS group's work schedule, which is Monday through Friday from 9 a.m. to 12 p.m. Figure 3.5 shows the new custom hours that you've configured for the TEMPS group.

TIP

At first sight, it might not be obvious what the selected scheduled hours are for a particular protocol. Depending on the area of the window that you've selected, the hours shown at the bottom are not necessarily the hours that are active. Highlight the dark (active) area with the mouse and you'll notice the exact hours at the bottom of the screen, as shown in Figure 3.5.

Figure 3.5 Applying a custom schedule to a protocol rule.

TIP

You can define new schedules; however, after the new entries are added, there is no delete option to get rid of them. To delete the entry, go to ISA Server Management console, Enterprise, Policy Elements, Schedules. You'll see the schedules you've created in the right-hand pane. When you try to delete the entry you'll be warned that if this policy element is used by any rule, ISA Server will not start.

Bandwidth Rules

Bandwidth rules are available in all ISA Server installation modes. The bandwidth rule works with the Quality of Service (QoS) scheduling service in Windows 2000 to prioritize network connections. The connections have a default scheduling for priority. If there is a bandwidth rule associated with a connection, its priority is changed accordingly. The bandwidth rule itself is not responsible for controlling the bandwidth of the connections; it simply communicates with the QoS to let it know how the priority should be set on a connection. It is the responsibility of the QoS service to control the bandwidth.

There's a default bandwidth rule that is guaranteed a minimum bandwidth by the QoS in Windows 2000. This rule can't be deleted or modified. You can create your own bandwidth rules to overwrite the default configuration. The range can be anywhere between 1 and 200 for both inbound and outbound traffic. For example, if you want Microsoft SQL Server to have more bandwidth on the network than other services, you can create a bandwidth rule for SQL Server and set the priority to a higher number; for example 200 (the maximum priority). On a busy network, when five clients send a request to Microsoft SQL Server and two send it to Microsoft Exchange Server, the bandwidth from five users will be evenly split among the five SQL Server users. The remaining bandwidth will be used by the two Exchange users.

Let's take a look at a bandwidth rule configuration as an example of this process. The following procedure describes how you can configure a bandwidth rule for Microsoft SQL Server.

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Bandwidth Rules.

  2. Right-click Bandwidth Rules and select New, then click on Rule to start the New Bandwidth Rule Wizard.

  3. Enter a name for the rule on the first screen; for example Microsoft SQL Server.

  4. On the Protocols screen, select an option from the drop-down box to apply the rule. For our example we will select Selected Protocols, as shown in Figure 3.6, and check the Microsoft SQL Server box. All the options available are listed here:

  5. Figure 3.6 Configuring a bandwidth rule.

  6. On the Schedule screen, select Always.

  7. On the Client Type screen, select Any Request.

  8. On Destination Sets screen, select All Destinations.

  9. On the Content Groups screen, select All Content Groups.

  10. On the Bandwidth Priority screen, select Use Default Scheduling Priority. (You will create a new priority in a moment).

  11. Click Finish on the final screen to complete the wizard.

  12. Right-click the new rule you just created and select Properties.

  13. On the General tab, ensure that the Enable box is checked.

  14. On the Bandwidth tab, check the Specified Priority Box and click on New.

  15. Enter the information shown in Figure 3.7 in the New Bandwidth Priority box and click OK to close the window.

  16. Figure 3.7 Creating a new bandwidth priority.

  17. On the Bandwidth tab, select your new SQL Server entry from the drop-down box, as shown in Figure 3.8.

  18. Figure 3.8 Specifying a new bandwidth priority.

  19. Click OK to apply the settings.

TIP

After you close the Window shown in Figure 3.7 and the entry is created, you won't see a Delete option. Even if you cancel out and don't click the Apply or OK button, the entry will still be saved. To delete the entry, go to ISA Server Management console, Enterprise, Policy Elements, Schedules. You'll see the schedules you created in the right-hand pane. When you try to delete the entry you'll be warned that if this policy element is used by any rule, ISA Server will not start.

Publishing Policy Rules

Publishing policy rules consist of two rules that allow information on servers in the internal network to be securely published to the external Internet clients. The two rules are known as:

The internal published servers are actually SecureNAT clients, so they don't need any special configuration. All you have to do is point them to the ISA Server computer as a default gateway. The external users communicate with the ISA Server computer, and in fact can't tell that they are really talking to a server inside the corporate network. The ISA Server acts as an intermediary and translates packets back and forth. The only IP address visible to the external clients is the IP address of the ISA Server computer.

Let's first take a closer look at the server publishing rules; we will then look at the Web publishing rules.

NOTE

The server publishing rules are available in Firewall and Integrated ISA Server mode—not in the Cache mode. The Web publishing rules are available in all three modes.

Server Publishing Rule

By default, ISA Server blocks all incoming traffic from the Internet. To allow an internal server to be accessible to the external clients, you create a server publishing rule. For example, to publish your FTP server to folks on the Internet, you'll create a server publishing rule on your ISA Server.

Server publishing rules can be limited to certain clients by using client address sets, which include the IP addresses of internal and possibly external clients.

When IP packet filtering is enabled on the ISA Server computer, the server publishing rules are applied to the client address sets. When IP packet filtering is disabled, the server publishing rule is applied to all the clients. This may not seem like a big deal, but let's look at an example so you can better understand what the consequences may be.

As an example, let's say you publish an FTP server only for the finance department so no one else can access their files. When IP filtering is enabled, only the finance department can access the files; however, if you disable IP filtering, the rule is applied to all the clients. Depending on how all the rules are configured and whether they are allow or deny rules, there is a possibility that you may end up giving access to more than just the finance department.

Let's say you want to publish an Exchange server located on the internal network inside the ISA Server computer. To configure a server publishing rule to publish this server, use the following procedure:

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Publishing, Server Publishing Rules.

  2. If the enterprise policy settings are not configured to allow publishing, you won't be able to create a server publishing rule at the array level. See the following tip.

  3. Right-click Server Publishing Rules and select New, then click on Rule to start the New Server Publishing Rule Wizard.

  4. Type a name for the server publishing rule. Be sure to read the note that states that you may have to create new policy elements required by the rule before you use the wizard.

  5. On the Address Mapping screen, type the IP address of the internal Exchange server that you want to publish under the IP address of the internal server. Under External IP Address on ISA Server, type the IP address of the external interface on your ISA Server that is connected to the Internet.

  6. On the Protocol Settings tab, apply the rule to the Exchange RPC Server. Figure 3.9 shows the built-in list of protocols that are available to you.

  7. On the Client Type screen, select Any Request.

  8. Click Finish to complete the wizard.

TIP

If you don't see the options to create a new server publishing rule or a Web publishing rule on the array members, it is probably because the enterprise policy settings are not configured to allow publishing. To enable this option, go to the properties of your server and on the Policies tab, check the Allow Publishing Rules option. The missing options should become available to you immediately. You must be a member of the Enterprise Admins group to allow publishing rules.

Figure 3.9 Configuring a server publishing rule.

Web Publishing Rule

The Web publishing rule is used for publishing Web servers only. To publish all other servers, you need to use the server publishing rule.

Using the Web publishing rule, you make your internal servers available to external clients so they can access HTTP contents on the Web server. The ISA Server works as the intermediary and forwards HTTP requests to the internal Web server. If the contents are available in the ISA Server cache, it will respond on behalf of the Web server and return the contents to the client from the cache. The published Web server doesn't support digest or Basic authentication—and it better not, or else it will expose its IP address to the clients on the Internet.

You will notice a default Web publishing rule in the ISA Management console. This rule applies to all requests to all the destinations and is configured to discard all requests. This rule cannot be modified or deleted; and if you have additional rules, this rule will be applied last. When the requests come in, ISA Server checks to see whether there are rules and if the request matches the rule. If it does, the request is processed accordingly; if it doesn't, the default rule is applied (processed last in order) and the request is discarded.

Let's work through an example of a Web publishing rule. Say you want to publish a Web server called WEB1 to the external clients. To create a Web publishing rule, use the following procedure:

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Publishing, Web Publishing Rules.

  2. If the enterprise policy settings are not configured to allow publishing, you won't be able to create a Web publishing rule at the array level. See the preceding tip.

  3. Right-click Web Publishing Rules and select New, then click on Rule to start the New Web Publishing Rule Wizard.

  4. Type a name for the Web publishing rule. Be sure to read the note that states that you may have to create new policy elements required by the rule before you use the wizard.

  5. On the Destination Sets screen, choose an appropriate option. The options are listed here:

  6. We will apply this rule to All Destinations.

  7. On the Client Type screen, select Any Request. You can also select specific computers, users, or groups.

  8. On the Rule Action screen, check the option Redirect the Request To This Internal Web Server (Name or IP Address), as shown in Figure 3.10, and type the IP address of the internal server that you want to publish. You can also use the fully qualified domain name of the server.

  9. On the next screen, click Finish to complete the wizard.

After the rule has been created, you can modify it by right-clicking the rule and selecting Properties. On the Bridging tab (see Figure 3.11), you can redirect the HTTP or SSL requests as HTTP, SSL, or FTP. For SSL, you can require that the site be published using SSL and 128-bit encryption. In addition, you can use a certificate to authenticate to the SSL Web server.

Figure 3.10 Redirecting a Web request to an internal published server.

TIP

The default port numbers for HTTP (80), SSL (443), and FTP (21) shown in Figure 3.10 are used only if you select to bridge the specific protocol. The bridging option is available on the Bridging tab, as shown in Figure 3.11.

Figure 3.11 Configuring the bridging option for a Web publishing rule.

VPN Support

A Virtual Private Network (VPN) enables you to extend the functionality of your private network to a remote network by using the Internet as the backbone. VPNs can be used in several different scenarios. ISA Server uses Windows 2000's Routing and Remote Access service to manage VPNs and offers wizards to configure VPNs in two of the most popular scenarios:

A VPN enables users to exchange information between two computers as if they were connected via a point-to-point link. Even though these computers can be located in remote sites, the information exchanged is encrypted and therefore secure. For example, let's assume that your Human Resources (HR) director, Shannon, wants to be able to work from home. With a VPN, you could allow her to access your corporate network via her Internet connection at home by creating a virtual "tunnel," as shown in Figure 3.12. First Shannon will use her modem to connect to her ISP. Then she will make a second connection to create a VPN tunnel to the corporate network. Once connected to the network, Shannon will be able to perform most of the tasks that she normally does while she is on the corporate network at work. She will be able to access the HR database, print to the network printers, access files in her home folder, and surf the Internet. Because Shannon handles confidential employee information, it is imperative that the data traveling between her home computer and the corporate network is secure. Creating a virtual tunnel encrypts data traveling inside the tunnel and offers the level of security that she needs.

Figure 3.12 A VPN tunnel from home to corporate network through an ISP.

In addition to the users, entire networks, such as branch offices, can access your corporate network via a VPN. Again, data is encrypted between both ends of the VPN tunnel; therefore all communication is secure. For example, if you have offices in Seattle and San Francisco and you want to use the Internet as a secure tunnel between the two offices, you can set up an ISA Server in both cities and create a virtual tunnel between them, as shown in Figure 3.13.

Figure 3.13 VPN tunnel between two offices across the Internet.

NOTE

For additional reading, check out my article "VPN Deployment Using Windows 2000" on the Microsoft TechNet CD, or online at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/profwin/pw0201.asp. The article covers configuring a VPN server, levels of encryption supported by VPNs, and the PPTP and L2TP packet structure.

PPTP, L2TP, and IPSec

In order to create VPNs that are secure, ISA Server supports the use of several protocols that will help you develop your VPN infrastructure. ISA server uses Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP) to create VPNs across TCP/IP-based networks. The use of IP Security protocol (IPSec) is also supported to help ensure secure data transfer across the Internet, or between computers within a local area network. Let's look at these protocols in more depth.

PPTP

PPTP is an extension to the Point-to-Point Protocol (PPP) and supports multiple protocols that will communicate over the Internet. A PPTP tunnel encapsulates IP, IPX/SPX and NetBEUI protocols inside PPP datagrams. This means that you can use a NetBEUI application on a server across the Internet, even though NetBEUI is not a routable protocol and therefore cannot be used to communicate directly on the Internet. PPTP doesn't require any dial-up connections. For example, if you already have a T1 or DSL connection to the Internet, you simply create a PPTP tunnel. In a typical scenario, a home user can dial into the ISP's server with a modem, which will connect the user to the Internet, and then create a second connection using PPTP and establish a VPN.

As mentioned earlier, PPTP can encrypt data passing through the VPN tunnel. It uses Microsoft Point-to-Point Encryption (MPPE) to encrypt data either with the default 40-bit encryption, or the stronger 128-bit encryption. Installing Windows 2000 Service Pack 2 on Windows 2000 computers will automatically upgrade the encryption level to 128-bit.

TIP

If you want MPPE to encrypt data, use MS-CHAP, MS-CHAP v2, or EAP/TLS authentication. MS-CHAP v2 and EAP/TLS support mutual authentication; therefore, if these protocols are the only protocols configured, make sure that both the server and the clients support them. The connection will be disconnected if, for example, the server doesn't identify itself to the client.

L2TP

L2TP is a combination of Layer 2 Forwarding (L2F) and PPTP. It provides similar functionality as PPTP to establish VPN connections. Although configuring PPTP on the server is much simpler, L2TP offers a higher level of security. With PPTP, you can use MPPE to encrypt data. With L2TP, you use IPSec to encrypt data. When using L2TP, you need to ensure that both the VPN client and the VPN server support L2TP and IPSec. In addition, keep in mind that only Windows 2000 and Windows XP support L2TP and IPSec; Windows NT and Windows 9x don't.

Setting Up a Local ISA VPN Server

In the section VPN Support, I mentioned that the ISA Server offers wizards to configure VPNs in two common scenarios: a branch office connecting to another branch office, and an employee connecting to the corporate network. To create a VPN tunnel between two branch offices across the Internet, you will use the Local ISA Server VPN Wizard and the Remote ISA Server VPN Wizard. Later, you will learn how to configure your server for the second scenario so that the users can create a VPN tunnel to access resources on your corporate network.

To create a VPN tunnel between two networks across the Internet, you need to run the Local ISA Server VPN Wizard on one end of the tunnel and the Remote ISA Server VPN Wizard on the other end. For example, if you want to connect two branch offices in Denver and Miami, run the Local ISA Server Wizard first on the ISA Server in Denver, create a .vpc file, and then use this .vpc file when you run the Remote ISA Server Wizard in Miami. Here's the step-by-step procedure to create the first end of the tunnel.

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Network Configuration.

  2. Right-click Network Configuration and select Set Up Local ISA VPN Server to start the Local ISA VPN Wizard.

  3. If Routing and Remote Access service is not running on the ISA Server, you will see a message telling you that the Routing and Remote Access service must be started before the VPN setup wizard can continue. Click Yes to start the service.

  4. On the ISA VPN identification screen, type a short name to identify the local network, such as DENVER. Also, type a name for the remote network, such as MIAMI. Notice that the connection will be identified as DENVER_MIAMI.

  5. On the ISA VPN Protocol screen, select a tunneling protocol that will be used for establishing a VPN. You can use L2TP, PPTP, or both. For our example, we will use PPTP.

  6. On the Two-way Communication screen, select the box Both the Local and Remote ISA VPN Computers Can Initiate Communication, as shown in Figure 3.14, if you want either end to be able to initiate connection. Otherwise, leave the box unchecked so only the remote computer can initiate communication. Also, in this screen enter an IP address and the name of the remote VPN computer or domain. If you use the domain name, make sure you use the NT-style name; for example, TechGalaxy instead of TechGalaxy.net.

  7. Figure 3.14 Enabling two-way communication.

  8. On the Remote VPN Network screen, enter the range of IP addresses on the remote VPN network that can be accessed by the local VPN computer. This will be the range of computers in Miami that can be accessed by the local VPN in Denver. The figure shows one range of IP addresses. You could add additional ranges of addresses if necessary.

  9. On the Local VPN Network screen, select the IP address of the external interface of the local VPN computer and then specify the range of IP addresses on the local VPN that can be accessed by the remote VPN computer, as shown in Figure 3.15. The remote VPN computer in Miami will use the IP address of the local VPN computer in Denver to create the tunnel. Once connected, it will be able to access computers in Denver that fall within the range of IP addresses that you have specified here. These IP address ranges are also used to create static routes that are managed through the Routing and Remote Access console.

  10. Figure 3.15 Configuring local VPN options.

  11. On the ISA VPN Computer Configuration File screen, provide the name of the configuration file that will be used to configure the remote VPN computer. The file will be saved with a .vpc extension, for example denver_miami.vpc. Also provide a password to encrypt this file so that only the administrator of the remote VPN computer will be able to access it.

  12. On the final screen of this wizard click on Details and verify that everything looks right.

  13. Click Finish to complete the wizard.

This will create a Routing and Remote Access demand-dial interface. To verify that the interface was created properly, go to the Routing and Remote Access console in Administrative Tools on the ISA Server computer. Click on the server name and then click Routing Interfaces. In the right-hand pane, verify that a demand-dial interface called DENVER_MIAMI exists. Although you created this interface in ISA Management console, any changes to this interface must be made in Routing and Remote Access.

Remember, now you need to run the Remote ISA VPN Wizard on the remote VPN computer to create the other end of the tunnel.

Setting Up a Remote ISA VPN Server

The procedure for setting up a remote ISA Server VPN is somewhat different to the one discussed previously. At the remote location in Miami, you will use the .vpc file that was created in Denver to create the second end of the tunnel. Here's the step-by-step procedure:

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Network Configuration.

  2. Right-click Network Configuration and select Set Up Remote ISA VPN Server to start the Remote ISA VPN Wizard.

  3. In the ISA VPN Computer Configuration File screen enter the path to the file in the File Name box, such as A:\denver_miami.vpc. This file contains configuration information about the remote VPN computer. Also, in the Password box, enter the password that was used when this file was created so that the file can be decrypted.

  4. On the final screen of this wizard click on Details and verify that everything looks right.

  5. Click Finish to complete the wizard.

When you complete the wizard, it will create the demand-dial interface, configure packet filtering for security, and configure static routes so that traffic from the local network can be forwarded to the remote network. Again, as in the previous section, the interface is created and can now be managed from the Routing and Remote Access console instead of the ISA Management console.

At this point, you have created both ends of the VPN tunnel, and users in Denver and Miami will be able to communicate using it.

Setting Up ISA Server to Accept Client VPN Requests

So far we've talked about the scenario where two branch offices can be connected through a VPN tunnel. Let's look at the second scenario that is used for clients to connect to your corporate network.

ISA server offers this additional wizard that configures your server to accept connections from remote clients. This enables users to create VPN connections from their home computers to the corporate network so they can access resources on the network. Typically, mobile users benefit from this type of connectivity because they can dial-in to their local ISP and then create a VPN tunnel to their company network. This saves money on long distance charges and offers users secure connectivity to the company resources.

Here's how you set up ISA Server to accept VPN requests from the clients:

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Network Configuration.

  2. Right-click Network Configuration and select Allow VPN Client Connections to start the ISA VPN Configuration Wizard.

  3. Click Details to see configuration information and then click Finish to complete the wizard. Congratulations! You just completed the world's shortest wizard with only two steps—start and finish.

  4. If you are prompted to restart the Routing and Remote Access service, click Yes to continue.

What did this wizard do in the background? It configured your Routing and Remote Access server as a VPN server so clients can be properly authenticated. It also automatically configured IP packet filters for you. There is one thing that the wizard doesn't do, and you need to take care of that business manually. You need to give the appropriate rights to the user to dial in to your network. This can be achieved either by configuring user account properties in Active Directory Users and Computers, or through Remote Access Policies.

Allowing Outbound PPTP Access

The previous situation applied to external users coming into your network through the Internet. If your internal clients have a need to create VPN tunnels from the internal network to a server on the Internet, you can enable outbound PPTP on the ISA Server computer. For example, you have some consultants working at your site that require access to their e-mail on their corporate network server. You can allow PPTP through the ISA Server so they can securely access their corporate server and read their e-mail. Here's how to enable the PPTP option:

  1. In the ISA Server Management console, click on Server and Arrays, <your server name>, Access Policy, IP Packet Filters.

  2. Right-click IP Packet Filters and click on Properties.

  3. On the PPTP tab, check the box PPTP Through ISA Firewall.

Comparison of Existing Security Solutions

The main purpose of a firewall is to isolate your network from external threats, just like a firewall in a house prevents fire from spreading through the rest of the house. In order to implement a solution that protects a network from Internet attacks, there are a number of methods that are currently in use. Some of these solutions include implementation of a Proxy server, NAT server, bastion host, a firewall, a demilitarized zone, and so on. Some of these solutions are meant for a small office or home network (such as a NAT server); others are used in large enterprises (such as firewalls).

Both Proxy and NAT servers more or less have similar capabilities. They translate clients' requests so that the external hosts see the requests coming from only one IP address—the server's IP address. You can even run message and Web servers inside your Proxy or NAT server. To the outside world, it looks like they are directly communicating with these servers, although in reality the server is acting as an intermediary.

NOTE

For more details on Proxy Server 2.0, check out my article "Proxy Server 2.0" at http://www.win2000mag.com/Articles/Print.cfm?Action=Print&ArticleID=3848. For more information on NAT Server, check out "Windows 2000's Network Address Translation" at http://www.win2000mag.com/Articles/Print.cfm?Action=Print&ArticleID=7882. The article also compares Proxy server to NAT server.

A bastion host is a single computer that isolates the internal network from the Internet. With a single point of defense against outside intruders, if a bastion host is not secured properly, you run the risk of compromising resources on your internal network. A lot of people that connect to the Internet using Digital Subscriber Lines (DSL) or cable modems use this type of configuration. A bastion host configuration is similar to a Proxy or a NAT server configuration.

All of these solutions offer some type of firewall functionality. To enhance security, organizations that require a higher level of protection implement various types of demilitarized zones (DMZs).

Let's look at how you can use DMZs to protect your network.

DMZ Overview

A demilitarized zone is also referred to as a screened subnet, or a perimeter network. In this book I will refer to it as a DMZ, as it's a common terminology that has been around for a long time.

While a bastion host separates your internal computers from the Internet by using a single computer, a DMZ isolates your network with a small separate network that is in addition to your internal network and separate from the Internet, as shown in Figure 3.16. A DMZ is sort of a neutral zone where clients from the Internet can access resources such as Web servers, but can't access the internal network. Two common implementation of DMZs, three-homed firewalls and back-to back firewalls, are covered later in this chapter.

Figure 3.16 A sample DMZ configuration.

A DMZ provides an extra layer of defense against attacks, because if security is compromised, hackers will only gain access to your DMZ, not your internal network. For example, you can place your Web servers, DNS servers, and e-mail servers in the DMZ and allow both the internal and external clients access to these servers.

DMZ Scenarios

As I mentioned previously, there are a couple of common ways that you can incorporate a DMZ in your network configuration. The first implementation is known as a three-homed firewall configuration, and the second way is known as a back-to-back firewall configuration. Both of these implementations offer better security than a bastion host. There are some other possible scenarios, but we will limit our discussions to the two scenarios I just mentioned.

Three-Homed Firewall Configuration

In a three-homed firewall configuration, you install three network adapters in your ISA Server computer that will act as a firewall. Each network card will route traffic to one of these three networks.

The sample DMZ configuration in Figure 3.16 shows a three-homed firewall configuration. This configuration provides better security than the bastion host configuration, and you have the added benefit of managing both the DMZ and the internal network from one location. However, one disadvantage of this configuration is that if hackers are able to penetrate your firewall, they will have access to both the DMZ and the internal network.

TIP

When working with ISA Server, use IP packet filtering, application filtering, and intrusion detection filtering to secure inbound traffic. Use site and content rules and protocol rules to control outbound traffic.

Back-to-Back Firewall Configuration

A three-homed configuration is a simpler way to add a DMZ to your network, but is not as secure as a back-to-back configuration. A back-to-back firewall configuration is shown in Figure 3.17. In this scenario, two ISA Server computers are used as back-to-back firewalls with a DMZ network sandwiched in between.

Figure 3.17 A back-to-back firewall configuration.

As you can see, one ISA Server (the external firewall) is connected to the Internet and the DMZ network, whereas the other ISA server (the internal firewall) is connected to your internal network and the DMZ network. With this approach, a potential hacker would need to pass through two ISA Server computers to gain access to your internal network.

Another advantage of a back-to-back configuration is that you can better manage your security by configuring rules that are more restrictive, compared to the three-homed configuration. One disadvantage of back-to-back configuration is that your enterprise security picture can get more complicated, as now you have to manage two firewalls.

Summary

This chapter covered the security aspects of ISA Server 2000. We started off by discussing site and content rules concepts. We covered protocol rules, bandwidth rules, and publishing policy rules. The discussion on rules was followed by a comparison of existing security solutions. We compared various security solutions in practice today, such as Proxy servers, NAT servers, bastion hosts, firewalls, and DMZs.

The VPN section included an explanation of VPN tunneling concepts, as well as the procedures for setting up local and remote ISA VPN servers. You also learned how to configure your Routing and Remote Access server as a VPN server, so that the server can accept client VPN requests.

In the DMZ section we covered the two most common types of DMZ implementations, the three-homed firewall and back-to-back firewall configurations.

In the next chapter, we will cover the important concepts of packet filtering. First we will introduce the creation and application of packet filtering. Then we will focus on application filters. Application filters have the capability to redirect, block, or even change the data when it reaches the ISA Server. Finally, you will learn the ins and outs of the built-in application filters that are provided with the ISA Server.

800 East 96th Street, Indianapolis, Indiana 46240