configuring isa server phần 8 potx

Limitations of Perimeter Networks While placing servers such as E-mail, FTP, and Web on a perimeter network does have some advantages, there are some significant disadvantages to using

This example represents only one of many possible scenarios in which you can deploy the SMTP Message Screener Other scenarios include having Exchange Server on the ISA server and running the Message Screener on the same machine

as the Exchange server We have found this configuration to be the most reliable and easy to set up Note that with this configuration, inbound mail is limited to the mail domain you configured in the IIS 5.0 SMTP server, and the internal

Exchange (or other) mail server is able to accept SMTP messages destined for all domains The IIS SMTP server protects your mail server from spammers trying to spam other domains through your server, because it drops messages destined for domains outside the ones you configure on the IIS 5.0 SMTP server External

SMTP messages never arrive at the internal mail server without being handled by

the IIS SMTP server

Designing Perimeter Networks

A perimeter network is a security zone where all hosts on the network have public IP

addresses ISA Server supports perimeter network configuration by placing the perimeter network segment on a third interface on the ISA server or by placing the perimeter

network between two ISA servers You also have the option of mixing ISA Server with another firewall product in the back-to-back perimeter network configuration

Perimeter networks allow you to publish servers without needing to change your IP addressing scheme or DNS server configuration Requests into and out of a perimeter network are routed by the ISA server rather than being translated, as they are when servers are contained within an internal network

Another advantage of using perimeter networks is that Internet traffic never enters your internal network All Internet traffic can be segregated by placing all servers that receive requests from the Internet on a perimeter network This has beneficial security implications If an intruder is able to break into a server on the perimeter network, they

do not automatically have access to your internal network The reason for this is that the perimeter is just another untrusted network to machines on the internal network

When you partition your Internet traffic on the perimeter network, you also reduce the amount of bandwidth required on the internal network used up by Internet users accessing resources on Web servers However, we should point out that you can

accomplish this by routing your internal network scheme in such a way that prevents Internet traffic from impacting your internal network’s available bandwidth

Limitations of Perimeter Networks

While placing servers such as E-mail, FTP, and Web on a perimeter network does have some advantages, there are some significant disadvantages to using perimeter network configurations with ISA Server:

· You cannot use Web or Server Publishing Rules to publish servers

· All access into and out of the perimeter network is controlled by static packet filters

· Packet filters access control is limited to an IP address or a subnet

· Configuring communications between perimeter network hosts and the internal network is cumbersome

Because communications between the perimeter network are not run through the ISA Server rules engine, you must use packet filters to control access to servers on the perimeter network As you have seen, access control using packet filters is somewhat

limited When using the wizard to create the packet filter, you can configure a Remote Host entry for a single IP address After creating the packet filter you can open the

Properties dialog box for the filter and include an entire subnet However, you cannot

use Client Address Sets to control access

Controlling communications between internal network clients and hosts on the perimeter network can be somewhat challenging Since the hosts on the perimeter network are treated like any other untrusted external network host, you must create publishing rules for the services on the internal network in order for the perimeter

network hosts to communicate with the internal clients

This might present a problem in the rare event that you might need to publish a NetBIOS dependent server on the internal network An example might be a SQL server that is not using SQL authentication However, in this instance, you can configure it to use SQL authentication and obviate the need for NetBIOS Another example might be an ISA server that is a member of a Windows NT 4.0 domain which requires NetBIOS

communications for authentication

One way to work around this is to configure the perimeter network host to use a VPN connection to the internal network client By using a VPN connection, the nature of the communications between the perimeter network hosts and the internal networks hosts are not exposed even if security is breached and an intruder is able to install

sniffing software on a perimeter network server

Perimeter Network Configurations

Two types of perimeter network configurations are popular with ISA Server:

· Tri-homed ISA Server

· Back-to-Back ISA Servers

Let’s take a closer look at each of these perimeter network configurations

Back-to-Back ISA Server Perimeter Networks

A back-to-back perimeter network consists of two ISA server computers:

· An ISA server directly connected to the Internet

· An ISA server connected to the internal network

The ISA server connected to the Internet can be considered the “external” ISA server and the ISA server connected to the internal network can be considered the

“internal” ISA server

Figure 9.26 shows how you might configure such a back-to-back perimeter

network

Figure 9.26 Back-to-Back Perimeter Network Configuration

When configuring a back-to-back perimeter network, you need to do the following:

1 On the external ISA server, place the IP addresses of the hosts on the

perimeter network in the LAT

2 Use Server and Web Publishing Rules on the external ISA server to make

servers on the perimeter network available to external clients

3 On the internal ISA server, include only the internal network IP addresses in the LAT Do not put the perimeter network IP addresses in the LAT of the internal

ISA server

4 Use Server and Web Publishing Rules to allow perimeter network hosts to

communicate with internal network clients

If you notice something a little funny here, then you have been paying attention Remember we said that you must use packet filters to publish services on a perimeter network? If that is true, then why are we now saying that you can use Publishing Rules to allow access to resources on the back-to-back perimeter network?

The reason is that when you configure a perimeter network in this way, without doing anything else, communications between Internet clients and hosts on the perimeter network are translated rather than routed By virtue of placing the perimeter network host IP addresses on the LAT, you have made them part of the “internal” network, from

the vantage point of the external ISA server All communications between computers on

the LAT and external network hosts are translated and not routed You do not have the option of changing this behavior unless you remove the clients on the perimeter network from the LAT

The problem is that when you try to remove the perimeter host IP addresses from the LAT, ISA Server gets upset You will get an error message indicating that there must

be at least one IP address in the LAT You’ll see the same error message if you try to install ISA Server and not include any IP addresses in the LAT

There is a way to work around this situation If you do not want your perimeter network communications to be translated, you have to add another network adapter that will support what we’ll call a “bogus” interface The bogus interface will be used for the IP address to put into the LAT

You can create such an interface by installing the Microsoft Loopback Adapter

After the loopback adapter is installed, configure it to use a private IP address such as 192.168.254.1 After installing the loopback adapter, you can then remove the perimeter network addresses from the LAT The will allow you to route, rather than translate,

communications between the perimeter network and the external network At this point

you will need to configure packet filters to support communications between the external network and the perimeter network

If you do choose to add a third interface on the external ISA server to support routing packets to the perimeter network in a back-to-back configuration, you will also need to make the following changes:

1 On the external ISA Server enable IP r outing

2 On the external ISA Server enable packet filtering

Keep in mind that with this kind of configuration, services can be published only by using packet filters You will not be able to use Server and Web Publishing Rules

SECURITY ALERT!

Note that while you can configure your back-to-back network to route packets through the ISA Server, this is not the preferred configuration Remember that the purpose of the perimeter network is isolate your internal network from

Internet traffic You are able to accomplish this even when the traffic moving to and from the perimeter network is translated Given that the server publishing method is more secure, you should consider this the preferred method of

publishing services on the back-to-back perimeter network

Tri-homed ISA Server Perimeter Networks

A tri-homed perimeter network configuration has the internal network interface and the perimeter network interface directly connected to the same ISA server In this case, a single standalone ISA erver or an ISA server array member is used to connect all three interfaces

As we noted previously, this is the only configuration in which you can route

packets to the perimeter network rather than translating them In fact, the workaround

we came up with creates a tri-homed ISA server although, in the above example, the third interface to the internal network was a “dummy” interface

A tri-homed ISA server configuration would look something like what is seen in Figure 9.27

Figure 9.27 A Tri-homed ISA Server

When configuring a tri-homed ISA server, perform the following steps:

1 Install an interface with a public IP address that is directly connected to the Internet

2 Install a second interface with a public IP address that will be used for the

ISA Server

Tri-Homed ISA Server DMZ

Mail Web

Private Network

DMZ Network

perimeter network

3 Install a third interface that will be used for the private network

4 Place only the private network IP addresses in the LAT Do not place the

perimeter network IP addresses into the LAT

5 Enable IP routing

6 Enable packet filtering

To publish resources on the perimeter network, you will need to use packet filters There are too many reasons to publish servers in a tri-homed DMZ configuration Server and Web Publishing offer a lot more features and are a more secure configuration The one instance where publishing servers on a perimeter network might be useful is when you wish to publish an FTP server on an alternate port number If you try to create a Protocol Definition and and a Server Publishing Rule that allows inbound access to an alternate port number to a FTP server, it will fail While you could make the FTP server a

Firewall Client and then create a wspcfg.ini file to support the alternate port, it is

better to put the FTP server on a perimeter network that does not perform translation The external clients will be able to access the FTP server on the perimeter network

through the alternate port number

Publishing Services on a Perimeter Network

When using packet filters to publish servers on a perimeter network, you have to be mindful of all required communications that must move into and out of the perimeter network For example, suppose you want to publish a Web server on the perimeter

network You would need to configure a packet filter that allowed inbound access to port

80 to the perimeter network To do this, perform the following steps:

1 Right click on the IP Packet Filters node in the left pane, click New, and then click Filter

2 On the Welcome page, give the filter a name, and click Next

3 On the Filter Mode page, select the Allow packet transmission option, and click Next

4 On the Filter Type page, select the HTTP servers (port 80) predefined

packet filter, and click Next

5 On the Local Computer page, select the This computer (on the perimeter network)option button, and type in the IP address of the Web server on the perimeter network Then click Next

6 On the Remote Computers page, select the All remote computers or the Only this remote computer, and then type in the IP address of the remote

computer If you need to allow a group of remote computers, you can configure

a subnet of computers to allow access This option is available after you have

completed the wizard Click Next

7 After reviewing your selections, click Finish

8 Double click on the packet filter you created, and click on the Remote

Computer tab Note that you have the options to apply the filter to a single remote computer or a range of computers In addition, if you click on the Local Computer tab, you can allow packets through to the entire subnet, or to a

group of computers denoted by a network ID and subnet mask

What if you need to provide access to a Web server on the perimeter network to more than one client, or to several groups of clients? It’s clear that you cannot do this by creating a single packet filter because you only have the option to control access by

Remote Computer by specifying a single IP address or subnet There are likely to be

many occasions where you would like to limit access to a select few computers or

subnets, but a single filter won’t accomplish the task

You can solve this problem by creating multiple packet filters for port 80 Each

packet filter will be searched by the ISA server to allow access from the

appropriate client Therefore, if you created one packet filter that allowed for inbound port 80 from remote hosts 222.222.222.0/24, you can create a second packet filter that would allow access from 111.111.111.0/24 All hosts from both network IDs would then have access to port 80 on the perimeter network client

After the server is published by the packet filter, inbound requests to port 80 to that perimeter network host will be allowed The ISA server will automatically allow the response to the external host by opening a dynamic packet filter

If your perimeter network hosts need access to name resolution services, you will need to configure a packet filter that allows DNS queries outbound from the perimeter network Its very common for administrators to forget about name services for the

perimeter network We recommend that the first packet filter you create for the

perimeter network be one that allows DNS queries

Publishing FTP Servers on a Perimeter Network

Publishing FTP servers on the perimeter network presents a special challenge The reason

is that there are two types of FTP clients that may connect to your FTP server The two types of FTP server connections you might want to support on the perimeter network are:

· PASV servers

· Standard servers

To create a packet filter to support FTP servers to work with PASV mode FTP

clients, you need to create a packet filter with the following specifications:

FTP Server – PASV

Protocol: TCP

Direction: Both

Local Port: Dynamic (Ports 1025-5000)

Remote Port: Any

To create a packet filter to support FTP servers to work with standard FTP clients

(that send PORT commands), you need to create two packet filters:

Remote Port: All Ports

Enabling Communication between Perimeter Hosts and the Internal

Network

As we mentioned earlier, servers on the perimeter network are considered external, untrusted network hosts In order to allow machines on the perimeter network to initiate communications with those on the internal network, you will need to publish those

servers on the internal network Perimeter network hosts will access the published

servers as would any other external network client

The main difference in the publishing of the internal server is that instead of

allowing all hosts on the external network to communicate with the internal server, you

will just let the server on the perimeter network communicate with it If you

require multiple servers on the internal network to communicate with an internal server, you can take advantage of Client Address Sets and include the perimeter network servers

in a Client Address Set that you would use in your publishing rule

For example, suppose you need your Web server on the perimeter network to communicate with a SQL server on the internal network You can use the Microsoft SQL Server Protocol Definition to create the rule After publishing the internal SQL Server, the Web server on the perimeter network will be able to initate an inbound connection to the private network to the published server

If the Web server, or any other server on the perimeter network, needs to resolve names on the internal network, you will need to publish the internal DNS server and allowthe servers on the perimeter network to access this server This can get tricky because if the server on the perimeter network needs to resolve both internal and external host names, there’s no way for you to get the server to “switch” what server it uses to resolve names

Therefore, consider having the perimeter network host always use the internal DNSserver and then configure the internal DNS server to use a Forwarder that can resolve Internet names There internal DNS server then will be able to resolve the external host names for the perimeter network server Remember, only allow the perimeter network servers access to the internal DNS server You do not want to publish the internal

network’s DNS server to all other external network users

Bastion Host Considerations

A bastion host is a machine that interacts with the Internet and protects your internal

resources There are actually a number of definitions for basion host For example, your ISA server that directly connects to the Internet is a bastion host Another example of a bastion host is the Web or E-mail server you put on the perimeter network What all of these machines have in common is that they directly interact with computers on the external network Servers on the internal network are not bastion hosts because the ISA server mediates all communications between the internal servers and the Internet clients

The purpose of the bastion host is to protect your internal network While many observers feel that the bastion host should be considered a form of “sacrificial lamb,” many others feel that the bastion host should be the most secure machine under your control

When Windows 2000 is installed, as a lot of services are installed by default, any service running on the bastion host provides a potential vector for attack by an intruder The key to good bastion host configuration is to remove all services and applications that are not required in order for the bastion host to do its job

And here lies the rub The job of the ISA server acting as a bastion host is to

protect the internal network and provide sophisticated packet filtering routing to servers

on perimeter networks The job of the ISA server acting as bastion host is not to run

Exchange 2000 or SQL 2000 or any other memory, disk, or network intensive application These applications tend to be mission critical, and in the event of a break-in, the ISA server and whatever else is on it will be the first to be destroyed or compromised

Therefore, we strongly recommend that you do not install any other server

application on the ISA server acting as bastion host However, if you are implementing the ISA server as a Caching-only server on the edge of a departmental network

connecting to the corporate backbone then you may consider such a configuration

Configuring the Windows 2000 Bastion Host

When configuring the Windows 2000 machine that runs ISA server as a bastion host, the

first thing you should do is disable the Client for Microsoft Networks However, if you are

running IIS on the ISA server machine, you should not do this because IIS will not start ifyou disable the Client for Microsoft Networks Be sure to disable this service on each network adapter

Another networking feature that is not required on the ISA server is the NetBIOS

interface You can disable the NetBIOS interface from the Advanced TCP/IP

dialog box However, this only disables attaching to Windows shares through the NetBIOSinterface Windows 2000 features a new way to access SMB shares through a method

called direct hosting This method uses DNS for name resolution, and shares are

connected to via TCP Port 445 In order to prevent an intruder from attaching to a share

via direct hosting, you need to disable the nbt.sys (the NetBIOS over TCP/IP driver) To

do this, perform the following steps:

1 Right click on the My Computer object on the desktop, and click Manage

2 Click on the Device Manager node in the left pane Then click the View menu, and click Show Hidden Devices

3 Right click on the NetBIOS over Tcip node in the right pane, and click

Disable

This procedure will disable connecting to SMB shares on the ISA Server

Disabling Services

Now it's time to take a sledge hammer to the machine What we want to do here is

disable all services that are not absolutely required The point is to run only the

absolutely required services To begin, open the Services applet from the

Adminsitrative Tools menu After the Services applet is opened, disable all services

except the following:

· Windows Management Instrumentation

· Windows Management Instrumentation Driver Extensions

· Windows Media Services (if you are running live stream splitting) Including the Monitor service, Program service, Station service, and Unicast service

· Windows Time Service

· System Event Notification

· Routing and Remote Access Service (unless you are using VPN)

· QoS RSVP

· Performance Logs and Alerts

· Microsoft Web Proxy

· Microsoft Scheduled Content Download Service

· Microsoft ISA Server Server Control

· Microsoft Identd Simulation Service

· Microsoft H.323 Gatekeeper

· Microsoft Firewall

· COM+ Event System

· Remote Access Connection Manager

· Telephony

You may be able to get away with fewer services, and you may require more After making the changes, reboot the system If the system does not boot, then reboot and enter the Last Known Good configuration and check the Event Log to see what service have stalled the reboot If the system is able to start, but something doesn’t work

correctly, check the Event Log to assess what the problem might be

Summary

In this chapter, we covered some important concepts in inbound access control Packet filters are used to control ingress and egress through the external interface Application filters can be used to affect the flow of information through the ISA server to the internal network

You learned the difference between static packet filtering and dynamic—or

stateful—packet filtering, and you found out when and how to create manual packet

filters

We discussed “routing” between public and private networks and the implications

of various packet-filtering and IP-routing scenarios that you might encounter on a

Windows network on which ISA Server is deployed

You learned how you can run applications and services on your ISA server (and received a strong suggestion that you dedicate a machine to running ISA and run few, if any, other applications on that machine) We also discussed how to use the built-in

intrusion detection functionality of ISA, and finally, we gave you some tips on how to bestdesign a DMZ, or perimeter network, using ISA Server

In the next chapter, you will find out how to publish servers and services to the Internet

Solutions Fast Track

Configuring ISA Server Packet Filtering

n Packet filtering is the process of examining the TCP and IP header information

to assess whether a packet should be allowed to enter or leave the external interface of the ISA server

n When packet filtering is enabled, only packets for which a filter has been

configured are allowed to pass through the external interface of the ISA server

n Static packet filters allow you to permanently open or close access to packets of your choice

n Packet filtering must be enabled in order to enable intrusion detection ISA Server can be configured to detect a limited number of intrusion types

Application Filters That Affect Inbound Access

n The RPC filter, when enabled, allows you to publish internal servers that use

RPC communications RPC, or remote procedure call, is message-passing

mechanism that allows a distributed application to call services that are

available on various computers on a network

n SMTP is a member of the TCP/IP protocol suite, used for exchanging e-mail across the Internet

Designing Perimeter Networks

n A perimeter network is a security zone where all hosts on the network have

The reason is that there are two types of FTP clients that may connect to your FTP server: PASV servers, and Standard servers

n A bastion host is a machine that interacts with the Internet and protects your

internal resources

Frequently Asked Questions

Q: How can I allow an internal client to ping an external address?

A: In order for an internal client to ping an external IP address, you must configure the client as a SecureNAT client and enable IP routing on the ISA server Note that you do not need to disable the Firewall Client software to do this All you need is to configure

a default gateway that routes to the internal interface of the ISA server, and it will be able to ping external hosts

Q: I want to be able to ping internal clients from a computer on the Internet However, when I enable IP routing and configure the ICMP Ping Query filters, it does not work Why is this?

A: You cannot ping clients on the internal network from the Internet or from any external network The reason is that external clients can only access internal clients when the internal clients have been published In essence, you would have to make the internal clients a “ping server.” However, the Server Publishing Rules only support TCP and UDP protocols, so you cannot even create such a server

Q: How can I filter attachments on inbound e-mail?

A: Enable and configure the SMTP filter, then install and configure the Message Screener Remember that the Message Screener needs to be installed on a computer running IIS5.0 The preferred configuration is to place the Message Screener on an IIS server on the internal network

Q: How can I allow internal clients to use PPTP to access external VPN servers?

A: Enable the SecureNAT PPTP packet filter Keep in mind that once the PPTP filter is

enabled, all computers on the network will have access to this filter The reason is that

you can only create access controls for TCP and UDP based protocols Since PPTP uses GRE, you cannot place access controls over this protocol

Q: I would like to attach a modem to my computer that already has an external interface and use it for a backup route for both inbound and outbound access Can I do that? A: No ISA Server was designed, for security reasons, to have a single external network access point If you want to use the modem for a backup route, install a second ISA server and configure it as backup to the main ISA erver

Chapter 10

Publishing Services to the Internet

Solutions in this chapter:

· Types of Publishing

· Web Server Publishing

· Publishing services

· The H.323 Gatekeeper Service

· Virtual Private Networking

Introduction

In this chapter, we’ll move our attention to making services on the internal network available to external network users Typically, these external network users will be on the Internet

The process of making services on the internal network available to external

network users is known as publishing When you publish content on the private network,

ISA Server handles all inbound requests from external clients, and forwards those

requests to the appropriate server on the internal network

Publishing services on the internal network allows you to maintain publicly

available services on the internal network in a safe manner, because external users never directly connect to machines on the internal network All requests are mediated by the ISA server, and only requests that you have configured to allow to be forwarded are sent

to the published servers The ISA server drops all other requests for internal network resources

Types of Publishing

When we talk about publishing resources, we refer to making resources located on a private network, using private network IDs, available to users on an external network The process of publishing services involves the use of wizards built into ISA Server to complete the publishing process

The are three methods of publishing services:

The Web Publishing wizards simplify the process of making these services available

to external users The wizards can also allow you to redirect requests on alternate ports

on the internal server This type of port redirection allows you to publish multiple Web sites on a single internal Web server by having each site listen on a different port number

In addition to port redirection, the Web Publishing wizard allows you to perform protocol redirection For example, a user can request http://exeter.tacteam.net, and the ISA server will redirect the request to the internal Web server as an FTP request, even though the user’s request was for an HTTP object The ISA server fetches the file from the internal FTP site and returns the file to the external user

Web publishing is mediated by the Web Proxy Service and uses the Web Proxy Service’s Incoming Web Requests Listener to intercept requests from external hosts

Rules are applied to incoming requests to published servers You can configure a Web publishing rule to limit inbound access to a select group of IP addresses or

users/groups This allows you to fine-tune access to internal Web resources

Server Publishing

The Server Publishing wizard allows you to publish services on the internal network In

order to do so, there must be a protocol definition to support that service After a

protocol definition is defined for inbound access, the Server Publishing wizard can use that definition to publish a server on the internal network using that protocol

For example, you might want to publish an internal terminal server To do this, you need a protocol definition allowing inbound access to the Terminal Services port After creating the protocol definition for Terminal Services, you can use the Server Publishing wizard to make that server available to external network users

Inbound requests handled by server publishing rules are not processed by the Web

Proxy Service; they are handled by the Firewall Service This introduces a few limitations

to what you can do with server publishing compared to what you can do with Web

publishing

For example, you can publishing multiple internal Web sites, and the ISA server will listen for requests for all those sites on the same Web Proxy Service Incoming Web Requests Listener port (which by default is TCP port 80) Server publishing does not allowmultiple services to listen on the same external port number

Let’s look at an example to illustrate this problem If you publish an internal

terminal server on TCP port 3389 on the external interface of the ISA server, that port can be used only once per IP address bound to the external interface of the ISA server, and for only the single server published on that port If you wanted to publish a second terminal server, you would have to create a protocol definition that used an alternate port, and then configure the terminal server to listen on the alternate port Another

alternative is to bind multiple IP addresses to the external interface(s)

The requests for services published through via server publishing are also subject

to rules However, your control over who can access internal services is less robust than what is available for Web publishing, since you can only limit access by client address sets (IP address) Web publishing allows you to control access through client address sets and users/groups

“Publishing” Services on a Perimeter Network

When making services available on a perimeter network, the requests are handled a bit differently Since inbound requests to the perimeter network are actually routed to

machines on the perimeter network, they are not able to take advantage of the features provided by the Firewall Service such as application-aware protocol filters that allow management of complex protocols You need to configure filters for each port required forinbound and outbound access through the perimeter network

For example, when you publish an FTP server on the internal network using server

publishing, the FTP access filter listens to the traffic, dynamically opens ports on the ISA

server, and allows negotiation of the appropriate ports However, this is not available with

publishing services on the perimeter network, because the application filter is bypassed

Another issue with publishing services on a perimeter network relates to complex protocols requiring secondary connections When you publish a server on the internal network using the Server Publishing wizard, you include the server protocol definition required to publish the server The protocol definition can include secondary connections required by the protocol Since you cannot use protocol definitions to publish services on

a perimeter network, you must configure packet filters individually to meet the

requirements of your protocol

Web Server Publishing

The Web Publishing wizard makes the process of publishing an internal Web server very easy The wizard will walk you through the process of choosing the internal Web server and the ports you want to use on it Once the Web publishing rule is created, you can begin to use it immediately

NOTE

Administrators sometimes feel that the wizard is too easy, and feel compelled to

create packet filters to support their publishing efforts Don’t do this! You do not need to create packet filters to support your publishing rules; the publishing rule will handle the opening and closing of ports as needed

However, before you can be assured that your Web publishing rules will work, you have to make some preparations in your network infrastructure

· ISA client configuration

· ISA Server Incoming Web Requests Listener configuration

Let’s look at each of these and see how to get them set up so that our Web

publishing rules work correctly

You will need to include a Host (A) entry for the internal Web server you wish to publish For example, if you are managing your own DNS, and have a zone for

“domain.com,” you must create a Host (A) record for “www” within that zone file This way, external users will be able to access your internal Web server using

www.domain.com as the address

TIP

You can make your site accessible by multiple names, such as ftp.domain.com, www.domain.com, and mail.domain.com You can enter multiple Host (A)

entries; one for each host name, or you can make a single Host (A) entry and use CNAME (alias) records for the other names The CNAME approach is a bit easier to manage if you change the IP address of the server from time to time

Alternatively, you could forget about DNS entries, and make everyone connects to your Web site via an IP address on the external interface of the ISA server While this is doable, most people can hardly remember their own telephone number, much less a 12-digit IP address As it stands with ISA Server, using IP addresses

in destination sets used for inbound access to the external interface of the ISA server doesn’t work

DNS Client/Server Infrastructure

In order for your publishing rules to work, make sure you have your DNS client/server infrastructure in place Remember, your published servers are SecureNAT clients of the ISA server

ISA Server DNS Client Infrastructure

The DNS infrastructure must be in place to support name resolution requests, both for internal resources and resources contained on the Internet This is one of the most

common pitfalls we encounter when working with new ISA Server administrators

First, you need to understand how the ISA server clients handle name resolution

SecureNAT clients must perform their own name resolution; the ISA server will not

resolve requests on the behalf of a SecureNAT client You must configure each SecureNAT client with the IP address of a DNS server to send queries for host name resolution

Firewall clients allow the ISA server to resolve requests on their behalf This is

referred to as DNS proxy After the ISA server resolves the name, it sends the name back

to the firewall client, and then the firewall client issues the request for the resource

When ISA Server performs this DNS proxy function, its uses the DNS server

configured on its external interface This is great for resolving host names located on the

Internet, but it falls down badly when you also need to resolve names on the internal network To get around this problem, be sure to configure the local domain table with the domain name(s) included on your internal network The ISA server will not resolve any domain included in the local domain table For these local domains, the ISA server will allow the firewall client to resolve the requests This means that you need to configure thefirewall clients with an IP address of an internal DNS server to resolve local domain

names Note that the local domain table is used only by firewall clients

Web proxy clients query DNS in the same way as firewall clients; they allow the ISA server to do the work for them However, since the Web proxy clients do not use the local domain table, you must use another method to allow them to resolve FQDNs that reside on the local network In this case, you can configure the browsers individually,

using the Advanced settings in the browser Connections dialog box A better way to solve this problem is to go to the Client Configuration node in the ISA Management console, and use the Web Browser Properties Direct Access tab to configure the

domain names that are considered local

DNS Server Infrastructure

The external DNS server must be set up with the appropriate resource records, so that requests from external clients can be resolved to the external interface of the ISA server

As we’ve mentioned, you can have the ISP handle this for you, or you can do it yourself

If you choose to host your own DNS, you will have publish the DNS server using server publishing rules The server publishing rules should be configured to allow both DNS queries and DNS zone transfers (if you required this) The internal DNS server

should be set up as a SecureNAT client, and it must have permissions to use the DNS query and zone transfer rules

You can put both your internal and your external zones on the internal DNS server, but we strongly discourage this approach If, for some reason, your publicly available internal DNS server is compromised, you do not want the intruder to gain information

about your internal network It is best to put the public DNS server on a machine separate from your private DNS

If you wish to use internal host names when configuring your rules, you must be sure that the internal interface of the ISA server is configured with the IP address of your private DNS server Your internal DNS server should be configured with all your internal domains, and it should be configured to use a forwarder on the Internet to resolve

external host names

Destination Sets

Once the DNS entries have been made, you can start configuring destination sets for yoursite A destination set is used by ISA server to identify which site the external user

requests Remember, when working with destination sets and publishing, you are looking

at it from the vantage point of the external user, not the internal user The destination forthe external user is going to the FQDN of your site that can be resolved by a publicly available DNS server

I point this out because often administrators will configure a destination set that

uses the name of the internal server, and try to use that in the Web publishing rule For

example, we want to publish a Web site on our internal network The server’s name on

the internal network is webserver.internaldomain.net The administrator then creates a destination set for the site that includes the name Webserver.internaldomain.net , and

uses that in the publishing rule

The problem with this is that the DNS entry for webserver.externaldomain.com is

the one we want users to use when connecting to our published server If you create a publishing rule using a destination set with the internal name of the server, it will not work, because the request sent by the user is for the external domain name of the

4 Enter the name of the destination set in the Name text box Enter a description for the destination set in the Description (optional) text box You should put each destination you plan to enter in this destination set in the Description

text box This will make it easier for you to figure out what the destination set ispointing to when you configure your publishing rules The reason for this is that the description information will appear in the wizards, making it easy for you to figure out exactly what sites the destination set references

5 To add a new destination to the set, click the Add button You will see the Add/Edit destination dialog box as seen in Figure 10.2

Figure 10.2 The Add/Edit Destination Dialog Box

6 In the Add/Edit Destination dialog box, type in the FQDN for your site in the Destination text box Note that you can use an asterisk as a wild card to

represent all the host names in a domain After entering the FQDN, click OK

After creating the destination set, it will appear in the right pane of the ISA

Management console When the ISA server receives a request for one of these

destinations, it will examine the headers in the request and see if it has the destination listed in the header that matches a name included in a destination set for a published server

ISA Client Configuration

You should configure the published server as a SecureNAT client This departs from how Proxy Server 2.0 did server publishing In Proxy Server 2.0, the only way you could publish a server was to make the server a Winsock proxy client, and then hammer away

at a wspcfg.ini file ISA Server allows you to escape that pain (in most instances) by configuring published servers as SecureNAT clients

SecureNAT client configuration is easy; the only thing you need to do is set the default gateway on the published server to an address that routes Internet-bound

requests to the internal interface of the ISA server If the published server is on the same logical network as the internal interface of the ISA server, you can set the default

gateway to be the IP address of the internal interface of the ISA server

If the published server is on a logical network ID remote from the internal network interface of the ISA server, then you must configure the default gateway on the publishedserver to be a router interface that will route packets destined for the Internet to the internal interface of the ISA server

When working with a routed network, make sure the routing table on the ISA server is configured properly before even setting up ISA Server Remember that packets need to know the path from the ISA server to all subnets on the internal network, and all the subnets need to know the path to the internal interface of the ISA server

In order for the ISA server to know the paths to the internal network IDs, you must configure the routing table on the ISA server with the appropriate gateway address(es) for each of the internal network IDs You must configure the routing table, because you cannot configure a default gateway on the internal interface Windows 2000 supports

a single network adapter with a default gateway, and that adapter must be the external interface of the ISA server

An alternative to configuring the routing table manually would be to implement a routing protocol on your network In this case, a simple routing protocol such as the Routing Information Protocol (RIP), can share routing information with other router

interfaces on the network that listen for RIP broadcast announcements For large and more complex networks, you might consider using OSPF (Open Shortest Path First), which is supported by Windows 2000 RRAS

Some published servers may not work correctly using SecureNAT You’ll see this if you plan on publishing certain Internet-enabled multiplayer games In this case, you’ll need to configure the server as a firewall client, and then configure a wspcfg.ini file on that server If that sounds too painful, you can place the game server on a DMZ segment,and create packet filters to allow the required ports

Configuring the Inbound Web Requests Listener

The ISA server listens for incoming Web requests on what is called the Incoming Web

Requests Listener By default, the Incoming Web Requests Listener uses port 80 on the

external interface of the ISA server You can change this if you like, but then everyone who needs to connect to your Web site will have to include the alternate port number in his or her request

If you want to make your site easy to access, don’t change the default listener port setting Note that the requests accepted by the Incoming Web Requests Listener are intercepted by the Web Proxy Service The Web Proxy Service handles all inbound HTTP

requests directed to the listener’s port number

You can configure the ISA Server Incoming Web Requests Listener to use the same configuration for all IP addresses on the external interface, or you can configure each external IP address individually The latter configuration expands the flexibility you have when publishing Web sites, especially if you want to use SSL You will have to add the inbound listener for the IP address(es) on which you want the ISA server to listen

To configure the Incoming Web Requests Listener, perform the following steps:

1 Open the ISA Server Management console, expand the Servers and Arrays

node, and then click on your server If you are running an array,

right-click on the array name Then right-click the Properties command In the dialog box that appears, click the Incoming Web Requests tab You will see something

like what appears in Figure 10.3

Figure 10.3 The Incoming Web Requests Tab

2 On the Incoming Web Requests page, you can make the configuration

changes on your inbound Web Requests Listener Note that there are two

options: Use the same listener configuration for all IP addresses, and Configure listeners individually per IP address If you have multiple IP

addresses bound to the external interface, you should configure the listeners separately I like to configure the listeners separately even if I have a single IP address, because it give me a better idea of what’s going on

One situation in which it’s a good idea to use the Use the same listener configuration for all IP addresses is if you have a dial-up connection

Although server publishing rules will break each time your IP address changes, you can prevent your Web publishing rules from breaking by selecting this option If you were to configure Web listeners individually, the listener address would change each time the dial-up connection is established and your Web listener would not be functional

3 Select the Configure listeners individually per IP addresses, and then click the Add button That brings up the Add/Edit Listeners dialog box shown in

Figure 10.4

Figure 10.4 The Add/Edit Listeners Dialog Box

In the Server drop-down list box, select the server that you want to

configure

In the IP Address drop-down list box, choose the IP address you wish to

assign to this listener

The Display Name text box allows you to type in a friendly name for this listener, which will appear on the Incoming Web Requests page

The Use a server certificate to authenticate to Web clients allows you

to configure this listener with a certificate that can be used when publishing secure Web sites Note that only a single certificate can be configured per

listener This means that you must use the same certificate for all the Web sites published through this listener We’ll talk more about this issue when we

discuss secure Web site publishing

The Authentication frame contains four choices:

· Basic with this domain

· Digest with this domain

· Integrated

· Client certificate (secure channel only)

These choices determine what type of authentication will be accepted by the Listener if you decide on forced authentication

The Basic with this domain option allows users to use clear-text

usernames and passwords to authenticate with the listener Use this if your

clients are not using Internet Explorer 4.0 or later The Select domain allows

you to select the authentication domain You must provide a single domain against which the users will authenticate If you do not specify a domain, the local accounts database will be used

The Digest with this domain option allows digest authentication by clients

connecting to this Web listener Digest authentication is only available to

Windows 2000 clients Do not use this option if you have downlevel client

operating systems that need to authenticate

Integrated authentication can use either Kerberos or NT

Challenge/Response Note that in passthrough authentication scenarios,

Kerberos will not work, because Kerberos requires that the client be able to identify the authenticating server

The Client certificate (secure channel only) option allow clients to

provide client certificates to identify themselves and authenticate Select this option if you have clients that have been configured with client certificates to access a secure site and have a Public Key Infrastructure (PKI) in place

Note that all of these authentication options pertain to authenticating with the ISA server; they do not pertain to authenticating against the Web site itself

If you have configured authentication for the Web site, you will have to enter credentials again to access the site

If you do configure authentication at the Web site, remember that ISA

server will only pass basic and anonymous credentials You will not be able to use Digest or Integrated authentication at the Web site

4 Click OK, and you’ll see something similar to Figure 10.5

Figure 10.5 The Incoming Web Requests Tab

5 You should now see the new listener in the list box

In the TCP Port text box, you can change the port number used by the

listeners Note that this setting applies to all listeners, not just the one you

selected in the box above You cannot use a different listener port number for each specific listener; this setting is a global one

If you want to force authentication before accessing any internal Web site,

put a check mark in the check box for Ask unauthenticated users for

identification Note that this is also a global option and cannot be configured

on a per-listener basis

The Resolve requests within array before routing option forces the

inbound request to be resolved in the array before forwarding to an internal

Web site This option enables CARP for inbound Web requests Generally, its not

a good idea to enable CARP for inbound Web requests, because it will reduce perceived performance on the user’s end, and increase the amount of traffic on the internal interfaces of the servers in the array as the requested is resolved within the array

6 The Configure button allows you to set a couple of connection settings When you click the Configure button, you’ll see what appears in Figure

10.6

Figure 10.6 The Connection Settings Dialog Box

You have two options for the Number of connections:

· Unlimited This option places no limit on the number of inbound connections.

· Maximum When you select this option, you can place a limit on the number

of simultaneous connections to the Web listeners

· Connection timeout (seconds) Configure the number of seconds you want

the ISA server to wait before dropping idle connections by typing the number of seconds into the text box

7 Click Apply, and you will see the ISA Server Warning text box shown in

Figure 10.7

Figure 10.7 The ISA Server Warning Dialog Box

8 If you want the ISA server to restart the service, choose the Save the

changes and restart the service(s) option If you want to restart the service yourself, choose the Save the changes, but don’t restart the services(s)

option We like to select the latter option, because when you let the ISA server

do it for you, it might take awhile before the server actually gets around to doing it When you do it yourself, you know exactly when the service is

restarted

After you complete the preparatory work, you’re ready to publish your Web site

Web Publishing Walkthrough—Basic Web Publishing

In this walkthrough, we’ll do some basic publishing of an internal Web site This will allow you to understanding the basics of Web publishing and expose you to the interface After you understand these basics, we’ll go through some more complex or unusual

configurations

1 In the ISA Management console, expand your computer or array name, and then expand the Publishing node in the left pane Right-click on the Web Publishing Rules node Click New, and then Rule

2 In the first page of the wizard, type in a name for this rule We’ll call this one

Exeter Web Click Next

3 The Destination Sets page appears as shown in Figure 10.8

Figure 10.8 The Destination Sets Page

In this example, we selected the Specified destination set option in the Apply this rule to drop-down list box When you select this option, the Name

drop-down list box appears You can choose from the list of all the destination

sets you’ve created We’ll select the Exeter destination set, which includes the FQDN exeter.isa.tzo.com Click Next

4 The Client Type page appears as shown in Figure 10.9

Figure 10.9 The Client Type Page

You have three options:

· Any request This option allows anybody access to the internal server.

· Specific computers (client address sets) This option allows computers,

identified by the IP addresses in a client address set, access to the Web site

· Specific users and groups This option allows you to control access to the

Web site via users and groups Authentication will need to be enabled on the external interface of the ISA server in order to limit access by account

In this example, we’ll select Any request, and then click Next

5 On the Rule Action page, you’ll see what appears in Figure 10.10

Figure 10.10 The Rule Action Page

There are several important configuration settings on this page:

· Discard the request Select this option if you want requests sent to the

computer(s) named in the destination set to be dropped

· Redirect the request to this internal Web server (name or IP

address) Select this option if you want to publish the internal Web server

In the text box, you can type in either the IP address or the computer name

of the internal computer If you use the computer name, be sure that the internal interface of the ISA server is configured with either a WINS or DNS

server that can resolve the name You can use the Browse button to find

the server on the internal network

· Send the original host header to the publishing server instead of the actual one (specified above) This option allows the ISA server to send

the original host header to the internal server, rather than the actual host header In this example, the actual host header would be

exeter.tacteam.net, since that is the name of the internal server, and the

ISA server in the process of forwarding the request would include the

server’s internal name to complete the request However, if you are using host headers to publish multiple sites on an internal server and you have mapped all those sites to an external IP address on the ISA server, you want

to preserve the original header The reason is that you want the FQDN in the original request to be forwarded to the internal server, so that the Web server can process the header and direct it to the appropriate web Enable this option if you need to preserve the original host header to send to the

internal Web server

· Connect to this port when bridging request as HTTP This option allows

you to use alternate ports on the internal Web server Some Web admins like to create Web sites on different ports, rather than using host headers For example, you can create a Web site that listens on port 80, another that listens on port 81, and another that listens on port 82 You can create a Webpublishing rule for each of these sites, pointing to a different port on the same server in each publishing rule If you use alternate ports on the Web server, make sure those ports are not in use by any other service

· Connect to this port when bridging request as SSL You have the same

option here You can redirect requests to use different SSL ports on the internal Web server If you have multiple SSL sites on the Web server, you can have sites listen on a different port

· Connect to this port when bridging request as FTP You can redirect

ports to the Web server’s FTP site using this option

In this example, we’ll use the defaults, and click Next

6 You can review your choices on the last page of the wizard If all looks well,

click Finish

After you create the rule, wait a minute or two for the ISA server to incorporate the rule into its policy set After the short wait, try to connect to the Web site using the FQDN included in the destination set that you used to create the rule You should be redirected to the internal Web site!

UNDOCUMENTED ISA SERVER

You should test your configuration from a machine on an external network If you try to access the published server from a machine on the internal network, the

request may fail, even though it works perfectly when accessed from an external

computer

Publishing a Web Site on the ISA Server

Publishing a Web site located on the ISA server creates some problems that you need to address before you begin publishing By default, IIS wants to use port 80 to listen for inbound Web requests The problem is that the ISA server’s Web Proxy Service uses port

80 to listen for inbound Web requests You cannot have both the ISA server and the IIS WWW Service listening on the same port

To solve this problem, you should configure IIS to listen only on the internal

interface of the ISA server This prevents conflict with the Web Proxy Service’s Incoming Web Requests Listener However, if you publish autoconfiguration information on the internal interface of the ISA server, it will use port 80 by default

You could change the port number that ISA server uses to listen for

autoconfiguration requests and try to make it work that way From our experience with ISA Server, it does not seem to want to work on the internal interface's port 80 This may

be a problem related to the configurations we have worked with, but we have never been able to publish a Web site on port 80 of the internal interface, in spite of the

documentation saying this is possible If you wish to try this option, be sure to test it thoroughly before putting it into production, and let us know about your success!

Before publishing a Web site located on the ISA server, you first need to change the IP address and listening port number that IIS uses to listen for inbound Web

requests

Readying IIS for Publishing

To ready IIS for publishing:

1 Open the Internet Services Manager from the Administrative Tools menu

2 Right-click on Default Web Site, and then click the Properties command Click on the Web Site tab You’ll see what appears in Figure 10.11

Figure 10.11 The Default Web Site Properties Dialog Box

3 In the IP Address drop-down list box, click the down-arrow and select the IP address of your internal interface In the TCP Port text box, type in a port

number that is not already in use You can determine which ports are already in

use by opening a command prompt and typing netstat –na This will list all

currently open ports Note that ports listening on 0.0.0.0 are listening on all

interfaces You’ll be fairly safe if you use a high number port, because relatively few of those are used by Windows network services But make sure first! For a list of reserved ports, see www.isi.edu/in-notes/iana/assignments/port-

5 After making the changes to the IP Address and TCP Port number, stop, and then restart the WWW Service You can do this via the control buttons in the

Internet Information Services console

Creating the Publishing Rule

Now that IIS is ready, we can get to the job of publishing our Web site To create a Web publishing rule, we can take advantage of the Web Publishing wizard Perform the

following steps to publish your Web site

1 Open the ISA Management console, expand the Servers and Arrays node,

and then expand your server or array name

2 Expand the Publishing node, and then right-click on the Web Publishing Rules node Click New, and then Rule This will start the Web Publishing

4 Click Next On the Destination Sets page, Select the Specified destination set option, and then select the name of the destination set that you want to use

for this publishing rule You will see something similar to Figure 10.14

Figure 10.14 The Destination Sets Page

5 Note that I have included in the Description of the destination set the FQDN

used to access the published Web site It’s always a good idea to include the FQDNs used in the destination set in the description box That way, you’ll know exactly what FQDNs are used when you configure your publishing rules Click

Next

6 This takes you to the Client Type page If you want everybody in the world to

be able to access the Web site, select the Any request option If you want to limit who can access the site, select Specific computer (client address sets), or the Specific users and groups option You might want to limit site access if you are making it available only to partners The Client Type page should look

like Figure 10.15

Figure 10.15 The Client Type Page

7 After configuring the client type, click Next This takes you to the Rule Action

page On this page, configure how you want ISA Server’s publishing rule to handle inbound requests for the FQDNs included in the destination set Select

the Redirect the request to this internal Web server (name or IP

address)

Note that if you use a name, rather than an IP address, the internal interface

of the ISA server must be configured with a DNS server address that can

resolve the name You might be able to get away with the NetBIOS name

resolution sequence, but don’t tempt fate Make sure your internal DNS

infrastructure is in place before working with ISA Server

Change the port number in the text box for Connect to this port when bridging request as HTTP to the port number that you configured in IIS for

the Web site You can change the other options if you made changes to the other ports in IIS The dialog box should look like Figure 10.16

Figure 10.16 The Rule Action Page

8 You can confirm your settings on the last page of the wizard If all looks good,

click Finish

Now, when we type in the URL http://www.isa.tzo.com, we see the screen shown in Figure 10.17

Figure 10.17 Connecting to the Web Site

Note that I’ve changed the default page This helps you know what Web site and server are accessed Changing the default page to give server identification information is

a good idea if you’re working with a number of publishing rules and servers and you need

to get a grip on "which is which." If you find yourself configuring a number of publishing rules during the same session, it’s easy to get things mixed up and configure the same publishing rule twice You’ll be able to easily identify your errors if you change the default page to contain identifying information during your test

After everything is configured and working correctly, change the default page on your IIS Web sites to reflect the actual content you want to present to the public or your