configuring isa server phần 6 pdf

server. On a simple network, the SecureNAT client has it default gateway set to the internal interface of the ISA server. On more complex or routed networks, the SecureNAT client has a default gateway set to a router interface that can route Internet-bound requests to the internal interface of the ISA server. The primary disadvantage of using the SecureNAT client is that it cannot pass authentication information to the ISA server, and therefore you cannot configure access controls based on user or group information. Solutions Fast Track Understanding ISA Server Architecture n Proxy Server 2.0 was built on three basic services: the Web Proxy Service, the Winsock Proxy Service, and the SOCKS Proxy Service. n The four components that form the foundation of the ISA Server are: the Web Proxy Service, the Firewall Service, the Network Address Translation Protocol driver, and the Scheduled Content Download Service n The Web Proxy Service (w3proxy.exe) provides and controls access to the Web protocols, which are Application layer protocols. n The Web Proxy Service is implemented as the w3proxy.exe file. You can start and stop the service via the net start w3proxy.exe and the net stop w3proxy.exe commands. n The Web Proxy Service is also responsible for the Web cache, which provides a mechanism that allows content retrieved from the Internet to be stored on the ISA server. n The Firewall Service (fwsrv.exe) provides the same functionality to network clients as the Winsock Proxy Service did in Proxy Server 2.0. n The firewall client installs a special version of the Windows Sockets (Winsock) interface. The Winsock interface is a Session layer interface and is implemented as an API. n The firewall client software captures Winsock API calls and forwards them to the Firewall Service via the Firewall Service’s control channel. n The Network Address Translation (NAT) Protocol driver allows network clients on a network that uses a private IP addressing scheme to access the Internet. n To solve the problem of Internet access for private network hosts, Windows 2000 provides the Network Address Translation Protocol, or NAT. This protocol allows private network clients to send requests to the NAT server rather then directly to the Internet host. n ISA Server takes advantage of the NAT Protocol driver included with Windows 2000 and extends its functionality so that it is able to work with the other ISA Server services. n The Scheduled Content Download Service provides ISA Server a mechanism to automatically download Web content from sites you want to have available on the ISA server before a user actually makes a request for the content. n All requests, regardless of whether they are from SecureNAT, firewall, or Web proxy clients, must pass though the ISA server’s packet filters. n HTTP requests issued by a Web proxy client, or a SecureNAT or firewall client with the HTTP redirector enabled, can also be subjected to a custom set of Application layer filters known collectively as Web filters. Installing and Configuring ISA Server Clients n The SecureNAT service provides virtually transparent proxy services for your network clients. n Whether you install a DNS server on your internal network or configure your SecureNAT clients to use a DNS server on the Internet, you must have site and content as well as protocol rules in place that will allow your SecureNAT clients to query an external DNS server. n If you choose to implement a single, centralized DHCP server, you must configure multiple scopes to service all network IDs that have DHCP clients. n In order to ping an external client, the ISA Server must be configured to allow IP Routing. n The firewall client installation file can also be accessed via a Web page, but the Web installation information files must be manually moved to a directory in the Internet Information Server WWW service accessible hierarchy. n If you have Mac, UNIX, or other non-Microsoft operating systems on the network, you will not be able to install the firewall client and therefore will not be able to take advantage of the complete range of protocols provided by the firewall client. n You should not configure servers that are published to the Internet to use the firewall client. n When you use the software deployment tools in the Windows 2000 Group Policy objects, you’ll typically have an organizational unit (OU) or a set of OUs to which you will make the software available. n The firewall client supports a process known as autodiscovery, in which the firewall client is able to query either a DHCP server via a DHCPINFORM message or directly query a DNS server via a DNS query for the name wpad.<domain_name>. n The most compelling reason to use DHCP, rather than DNS, when configuring your wpad entries is that DCHP allows you a more granular approach to assigning your ISA servers to the network clients. n ISA Server allows you to publish servers by configuring them as SecureNAT clients, therefore virtually obviating the need to set up the published servers as firewall (Winsock) clients. n A Web proxy client is a CERN-compliant Web browser or other application that can be configured to send requests to the Web Proxy Service on the ISA server. n When the Web proxy client is configured to support autodiscovery, it can take advantage of a wpad entry contained in either a DHCP or DNS server. Frequently Asked Questions Q: Do I have to install Internet Information Server to use the Web Proxy Service, as I did with Proxy Server 2.0? A: No. Unlike Proxy Server 2.0, you do not need to install IIS in order to take advantage of the Web Proxy Service on ISA Server. In fact, it is recommended that you do not install IIS on the same machine as ISA Server. Q: How do I know if my Web browser is CERN compliant? A: The best way for you to determine whether or not your browser is CERN compliant is to configure it to use the Web Proxy Service. You can do this by configuring it to use port 8080 on the internal interface of the ISA server. If it works, it is CERN compliant. If it does not work, it is not CERN compliant. Almost all browsers released in the last three to four years are CERN compliant and will work with the ISA Server Web Proxy Service. Q: Do I have to install the firewall client? I am concerned that if I install the firewall client software, my existing network applications will not work correctly. A: You do not have to install the firewall client software. You can still access the Internet through the ISA server if you configure your clients as SecureNAT clients. However, you lose out on some of the convenience that the firewall client offers, and you also lose authentication information that would allow you to configure access control based on users or groups. Do not worry about the firewall client software breaking your existing applications. We had the same concern with the Proxy Server 2.0 software, but the firewall client software doesn’t break anything, and it is easy to disable or remove if you decide that you do not want to use it. Q: I’ve read a lot of books on Proxy Server 2.0, and it is always said that the control channel uses UDP 1745. What makes you think that it also uses TCP 1745? A: Much of the research we did for this book included network-monitoring sessions that were used to determine ISA Server protocol behavior. We noticed that if we stopped and started the firewall service, the LAT was being transferred from the ISA server’s internal interface’s TCP port 1745 to the firewall clients. UDP is still used for communications that can fit inside a single UDP packet. Larger control messages use TCP instead of UDP. Q: Can I run RRAS and ISA Server on the same machine? Also, can I run the RRAS NAT service at the same time I run ISA Server? A: You should not run the RRAS NAT Protocol on the same machine as ISA Server. Even though ISA Server will disable the RRAS NAT Protocol, we have seen many difficult-to- explain errors when the NAT Protocol was still installed. You should delete it from the RRAS Service. The RRAS Service will run on the ISA server and is used by the ISA server, especially when you want to configure VPN connections. Q: Sometimes when I make a change, it doesn’t seem to work. But then when I come back to the computer later, things suddenly work. What is causing this? A: If the change you’ve made requires the service to restart and you let the ISA server restart the service for you, it could take a few seconds to a few minutes for the service to complete the restart purpose. If you need the change to take effect sooner, tell the ISA server that will you restart the service yourself. Q: Before using ISA Server, I used the RRAS NAT Service. Now my computer seems to be dropping off the network and not receiving IP addresses. What might be the problem? A: Unlike the RRAS NAT Protocol, ISA Server does not include a DHCP allocator. If you want to automatically assign addresses to ISA Server clients, you need to install a DHCP server. Q: I want to run programs like Napster and various Internet games on my ISA Server clients. I do not want to install the firewall client. However, it seems that these things work only with the firewall client installed. What can I do about this? A: Napster and various Internet games required complex protocol connections that require primary connections and often multiple secondary connections. The easiest way to handle these is to use the firewall client. If you use the SecureNAT client, you might have to configure multiple protocol definitions to make them work correctly. Q: When I use the firewall client, I can connect to mail servers on the Internet from my internal computers, but if I use the SecureNAT client, it does not work. I would rather not use the firewall client software, but I can’t connect to mail servers on the Internet without it. Is there anything I can do about this? A: The problem is likely due to the DNS configuration of your SecureNAT clients. The reason that you are able to access your mail servers when the firewall client is installed is that the Firewall Service is able to take advantage of DNS proxy via the Firewall Service. The Firewall Service resolves the name for the firewall client and returns that address to it. The SecureNAT client must have a DNS server address configured on it or it will not be able to resolve Internet names. Chapter 8 Configuring ISA Server for Outbound Access Solutions in this chapter: · Configuring the Server for Outbound Access · Network Configuration Settings · Creating Secure Outbound Access Policy · Configuring Application Filters That Affect Outbound Access · Understanding and Configuring the Web Proxy Cache · Summary · Solutions Fast Track · Frequently Asked Questions Introduction In this chapter we focus on ISA Server configuration issues that have their primary influence on outbound access and outbound access control. Although we often think of a firewall as something to prevent external intruders from accessing internal resources, just as much havoc can result if we fail to control what internal users can access on the Internet. The major issues we tackle in this chapter include: · Configuring ISA Server for outbound access · Understanding and configuring the Network Configuration settings · Creating a secure outbound access policy · Configuring the application filters that affect primarily outbound access · Understanding and configuring the Web proxy cache Once you have a firm grasp on these issues, you will be able to configure a secure outbound access policy and ISA Server configuration. Configuring the Server for Outbound Access Several elements determine how outbound requests for Internet resources are handled. These elements can be broken down roughly into two groups: · Outbound Web protocol requests · Outbound “everything else” The “everything else” includes Winsock application requests that are not wrapped in HTTP headers. Both SecureNAT and firewall clients issue Winsock application requests. Outbound access control for these clients centers around configuring protocol rules. Outbound requests from Web proxy clients are handled a little differently, since they do not have to be run through the Firewall Service. However, they are still bound by protocol rules. You can configure how outbound Web protocol requests are handled on the internal interface of the ISA Server via the Server’s Properties sheet. Note that this is a departure from how things were done in Proxy Server 2.0. With Proxy Server, you configured Web protocol access controls and Winsock access controls through different configuration dialog boxes. In ISA Server, those dialog boxes are consolidated, and Web and Winsock protocols are now configured through the same interface. Configuring Listeners for Outbound Web Requests To access the configuration dialog box for Outgoing Web Requests, perform the following steps: 1. Expand the Servers and Arrays node in the left pane of the ISA Management console. Right-click your server or array, and click Properties. 2. Click the Outgoing Web Requests tab. You will see something like what appears in Figure 8.1. Figure 8.1 The Outgoing Web Requests Tab on the Server Properties Sheet 3. In the Identification frame, you have the option to configure the Outgoing Web Requests Listener for the Web Proxy Service to Use the same listener configuration for all internal IP addresses, or you can Configure listeners individually per IP address. Your decision to use the same listener configuration rather than separate listener configurations for each IP address is determined by the type of authentication you want to require to access Web content via a particular listener. If you wanted to apply the same authentication requirements for all outgoing Web requests, you would choose to apply the same configuration to all IP addresses. If you need a more granular control over the type of authentication accepted for each listener, you should configure listeners individually. Note that even though you can configure each listener to accept a different method of authentication, the decision to require authentication is a global configuration option. You do not have the choice to require authentication on one listener and not require authentication on another listener. To add an Outgoing Web Requests Listener, click the Add button. You’ll see something like Figure 8.2. Figure 8.2 Adding a Listener for Outgoing Web Requests 4. When you add a new listener for outgoing Web requests, you select the Server, which will likely be the server on which you are configuring the listener; the IP address that is associated with this listener; and the type of authentication you want to enable for this listener. You can also configure the listener to use a server certificate to authenticate it to internal Web clients. This allows SSL connections between the Web proxy client on the internal network and the ISA Server’s internal interface. 5. In Figure 8.1, note the TCP port text box. This box defines the port number listening for Web proxy client requests. You can change this number to any port you like, but be sure that no other service is running on that port. You can determine whether or not another service is bound to that port by running the netstat –na command from the command prompt. If the netstat command shows that another service is listening on that port, you need to choose an alternate port assignment. The default port number for outbound Web requests is TCP 8080. We advise you to leave this value as it is, if possible. 6. If you want internal clients to connect to the listener via SSL, you must Enable SSL Listeners and include a port number. Note that the default port number is 8443. You should not change this port number. Furthermore, if you enable SSL on a listener, you must have a certificate installed on that listener. Note that Port 8443 is the port number to which browsers configured as Web proxy clients send their SSL connection requests. If the browser is not a Web proxy client, it does not send SSL requests to this port number. The non-Web proxy client browser doesn’t need to send requests to this port number; because it is not a Web proxy client, it will not be able to authenticate with the Web proxy service. 7. In the Connections frame, decide whether you want to force authentication for Web proxy requests by selecting the Ask unauthenticated users for identification. Recall the effect this option has on SecureNAT or firewall clients that are not also configured as Web proxy clients: Their Web protocol requests fail. If this option is checked and a Web proxy client issues a request, the user will be presented with an authentication dialog box if there is no protocol and site/content rule allowing the request to be passed for anonymous requests. Also note that if you choose to use basic authentication, it will call up the logon dialog box. When integrated authentication is selected, credentials are passed transparently and the user will not need to enter credential information. When you click the Configure button, you see the screen that appears in Figure 8.3. Here you configure the number of simultaneous outgoing connections you want to allow to the Web Proxy Service. The timeout interval for dormant connections can be set here as well. Limiting the maximum number of connections can have the effect of improving the performance for users who are able to make a connection, albeit at the expense of users who are not able to connect. If you do limit the number of connections, be sure to configure the timeout to a low number so that people do not wait a long time for user connections to time out before they can get access to the ISA server. Figure 8.3 The Connection Settings Dialog Box Server Performance You can configure the amount of server memory and other resources dedicated to servicing Web requests via the Performance page. If you click the Performance tab on the server’s Properties sheet, you see the screen that appears in Figure 8.4. Figure 8.4 The Web Proxy Service Performance Page When you configure the Performance tuning slider bar to support more users per day, you dedicate more of the system resources to the ISA Server services. These resources can include memory and thread pools. Note that saying you have more users than you actually do will not improve performance. In this instance, you will be wasting server resources that can be used by other system processes. Network Configuration Settings ISA Server network configuration settings that influence outbound access controls include the following: · Routing SecureNAT and firewall client requests · Routing Web Proxy Service requests · Passing outbound PPTP requests from internal clients · The local address table (LAT) · The local domain table (LDT) Each of these influences how outbound requests are processed. We’ll start with how SecureNAT and firewall client requests are routed in what are known as firewall chains. Firewall Chaining: Routing SecureNAT and Firewall Client Requests ISA Server provides a great deal of flexibility in terms of how client requests are routed. Rather than being limited to using the default connection on the ISA server, you can tell the ISA server to send specific requests via customized routes. When firewall clients send their requests to the ISA server, the requests can be routed directly to the Internet via the primary connection on the ISA server, or you can configure the Firewall Service on the ISA server to forward the request to another ISA server. The question is then, why would you want to do this? The immediate answer is because you can. However, that answer won’t be very satisfying when you are trying to explain the rationale for your network infrastructure design to the network security committee. One reason you might want to forward firewall client requests is that you want to partition the routing of firewall client and SecureNAT client requests from requests made by Web proxy clients. You might want to configure all the computers to use the same ISA server to make the initial connection, but once the connection is made, the Web proxy client requests would go to that server, and the firewall client requests would be routed to another server. In this way, Winsock application requests (such as SMTP, POP3, and NNTP requests) could reach the Internet via a separate computer than the requests made by Web proxy clients. The rationale for doing this might involve the fact that most Web requests do not require a high level of security, since typically a tiny percentage of Web connections are made via HTTPS (SSL-secured HTTP). Therefore, you could forward the Winsock (firewall client and SecureNAT client) requests to another ISA server that has a more “hardened” configuration. Another reason to route firewall client and SecureNAT client requests separately is to apportion bandwidth between the these clients and the Web proxy clients across two separate servers and their associated connections to the Internet. The most common reason to configure firewall client routing is to support chaining of firewall client requests to upstream ISA servers. For example, you might have a branch office in Pasadena, Texas, and a main office in Dallas. When firewall client computers send a request to the ISA server located in Pasadena, you want the ISA server to forward the requests to the Dallas office, because the Internet access point for the organization is located in Dallas. In this example, the ISA server might use a VPN interface to connect to the upstream ISA server. This prevents users in the Pasadena office from accessing content from the Internet directly, and content must be accessed via the upstream ISA server in Dallas. Unfortunately, you cannot configure granular Firewall Service routing rules the way that you can for the Web Proxy Service. For example, it would be nice to configure a firewall routing/chaining rule so that when your users made a request to sites such as Napster, you could selectively redirect those protocol requests to a server that has a 14.4Kbps modem connection. Configuring Firewall and SecureNAT Client Routing To configure the way that firewall and SecureNAT client requests are routed, perform the following steps: 1. In the ISA Management console, expand the Servers and Arrays node, then expand your server or array. Right-click the Network Configuration node, and click Properties. You will see the screen that appears in Figure 8.5. Figure 8.5 The Firewall Chaining Dialog Box 2. The Use primary connection option button is the default setting. When this option is selected, firewall client and SecureNAT client requests are sent out the external interface of the ISA server that receives the request. If you are using a dial-up connection on the ISA server, you must select the Use dial-up entry check box if you want the connection to automatically dial when a firewall client or SecureNAT client request arrives at the ISA server. 3. The Chain to this computer option button configures the ISA server to forward firewall client and SecureNAT client requests to another ISA server. Type in the name of the upstream ISA server in the text box, or you can look for the machine on your network via the Browse button. 4. The Use this account check box should be checked if you need this ISA server to pass credentials to the upstream ISA server. To set the credentials, click the Set Account button. You will see the screen that appears in Figure 8.6. Figure 8.6 The Set Account Dialog Box 5. Enter the User in the text box, then enter the password and confirm the [...]... controls configured on the ISA server When the request arrives at the ISA server, it will be sent through the rules engine, and if there is a site and content and a protocol rule that allows the request, the ISA server will route the Web proxy request to the upstream Squid server When the upstream Squid server retrieves the Web object, it will be returned to the ISA server, and the ISA server will put the... returns the object to the Abilene ISA server without generating any WAN traffic on its Frame Relay link to Dallas The Abilene ISA server then puts the object in its own cache and then returns it to the user who made the request If the object is not contained in the Galveston ISA server s cache, the server forwards the request to the Dallas ISA server The Dallas ISA server checks its cache If the object... the ISA server and then forwarding them as unprotected requests The SSL requests (establish a new secure channel to the site) option allows the ISA server to forward a request made over an SSL channel to the internal Web server as an SSL request In this case, the ISA server will establish a new SSL session with the destination server Note that this is not the same as SSL tunneling, in which the ISA server. .. Routing to a Linux Squid Server Many administrators already have other proxy servers in place but would like to take advantage of the outbound access control features of ISA Server One example of this situation is an organization that wants to use an ISA server downstream from a Linux Squid proxy server You can route Web proxy requests sent from clients to an ISA server to a Squid server and take advantage... support Web proxy chaining Web proxy chains can connect ISA servers located at different sites or LAN segments in a hierarchical fashion so that downstream ISA servers can take advantage of the cache contents of upstream ISA servers Configuring a Web Proxy Service Routing Rule Before configuring a new routing rule, it’s worth mentioning that when ISA Server is installed, a default routing rule is created... to the ISA server at the edge of the user’s network The Abilene ISA server checks its Web proxy cache to see if it contains the object If it does contain the object, it returns the object to the user without generating any WAN traffic If it does not contain the object, the ISA server will route the request to the Galveston office Once the request arrives to the Galveston ISA server, that ISA server. .. option, the ISA server will establish an SSL channel with the destination server and send and receive with that server via SSL You use this option when routing inbound requests to an internal Web server For example, an Internet user makes a connection with the ISA server to access content on an internal Web site You might want to redirect the HTTP request made to the ISA server to the internal Web server. .. cache, it returns it to the Galveston ISA server without generating any traffic on the T1 link to the Internet The Galveston ISA server then puts the object into its cache Then the Galveston ISA server returns the object to the Abilene ISA server, which puts the object in its cache, and then it returns the object to the host that made the initial request If the Dallas ISA server does not contain the object... same online concert simultaneously You can place an ISA server on the edge of each network segment that connects to the backbone and another ISA server that connects the backbone to the Internet Then you configure the segment ISA servers to route Web requests to the ISA server (or array) on the edge of the campus network In this way, the segment ISA server cache is searched first, and only if the object... request sent over the backbone to the campus ISA server or array If that ISA server has the object in cache, it returns it to the ISA server on the segment backbone In actual practice, the ISA server at the edge of the campus network needs a measure of fault tolerance; therefore, you would configure it as an enterprise array When you configure the segment-level ISA servers to route requests to the enterprise . the ISA server will route the Web proxy request to the upstream Squid server. When the upstream Squid server retrieves the Web object, it will be returned to the ISA server, and the ISA server. the Galveston ISA server s cache, the server forwards the request to the Dallas ISA server. The Dallas ISA server checks its cache. If the object is contained in cache, it returns it to the Galveston ISA. requests sent from clients to an ISA server to a Squid server and take advantage of the access controls configured on the ISA server. When the request arrives at the ISA server, it will be sent through