configuring isa server phần 7 docx

NNTP supports path processing. When you look at Table 8.4, you can see that NNTP is not contained in the table and therefore does not support path processing. What do you think will happen when you try to access sites contained in this destination set via your newsreader? When you try to access www.potus.net/flotus via your newsreader, you will be able to access the site. The reason is that NNTP does not support path processing, so it ignores the entry for the entire site and allows access (assuming that the default site and content rule is active and allows access to all sites that are not denied). When you try to access www.sawhorse.net via your newsreader, the request will be denied. Why? Because www.sawhorse.net does not have a path statement. Therefore, the destination is processed and the deny rule is applied. SSL requests represent a special case when it comes to destination sets. If a site and content rule denies access to a destination set that includes a site with a path statement, such as www.microsoft.com/memberdownload, and the site is accessed via SSL, not only will the subdirectory be denied but the entire www.microsoft.com site will be denied. Be very wary of denying access to a destination set that includes a path if you expect to access any other area of that site. Protocol Rules Protocol rules determine the TCP/UDP protocols that network clients can access. Protocol rules can be configured to allow primary connections for either inbound or outbound requests. Protocol rules that have primary inbound connections are called server p rotocols because they can be used by server publishing rules. By default, clients are not able to access any protocols, because ISA Server does not include a default protocol rule. Although site and content rules include a default rule that allows access to all sites and content to make administration easier, ISA Server increases the default level of security by disallowing access to all protocols until you create rules to allow access. Protocol rules apply to all ISA Server clients. This includes SecureNAT, firewall client, and Web proxy clients. Even if you have configured your browser to be a Web proxy client, there still must be a protocol rule in place to allow the client to access the HTTP protocol. If there is no protocol rule that allows access to HTTP, the Web proxy client will be presented with a pop-up a dialog box asking for credentials. In spite of entering the correct credentials, you will not be able to access HTTP content and the request will be denied. Protocol Rules Depend on Protocol Definitions Protocol rules depend on the protocol definitions located in the Protocol Definitions node in the ISA Management console. A protocol definition must exist before you create a rule influencing access to any particular protocol. This is especially important for SecureNAT clients because if you create a protocol rule that allows access to all IP traffic, only the protocols that have protocol definitions will be available to SecureNAT clients. If there is no protocol definition, there will be no access for the SecureNAT client. This is in spite of the SecureNAT client having access to “all protocols.” If a protocol requires secondary connections, a SecureNAT client will need an application filter to allow it to access that protocol. Firewall clients do not require applications filters to support protocols with secondary connections because the firewall client software can have the intelligence to manage the connection. For example, to access Napster, you must use secondary connections, as we saw earlier when configuring a protocol definition for Napster. The SecureNAT client depends on the SOCKS4 application filter to access the Napster protocol definition that we created. If the SOCKS4 application filter were disabled, the SecureNAT client would not be able to access the protocol, in spite of the fact that we had configured a protocol definition that supports access. Firewall clients do not require the application filter and can manage their own secondary connections. While you are in the process of learning about ISA Server, it’s a good idea to create a configuration that allows all protocols to all users at all times. This way, you can assess whether your basic configuration is functional. After you confirm the basic functionality of your ISA server, you can begin to tighten the screws on your security configuration. To support this testing mode setup, let’s create a protocol rule that allows access to all protocols. Creating a Protocol Rule To create a protocol rule, perform the following steps: 1. Open the ISA Management console, expand Servers and Arrays, and then expand Access Policy. Right-click Protocol Rules, click New, and then click Rule. 2. On the first page of the New Protocol Rule Wizard, enter the name of the protocol rule. In this example, call it Allow All. After entering the name, click Next. 3. On the Rule Action page, you have two choices (Figure 8.48): · Allow Choose Allow if you want to create a rule that will allow access to a protocol or protocols. · Deny Choose Deny if you want to create a rule that will deny access to a protocol or protocols. For this example, we want to allow access to all protocols, so select Allow and click Next. Figure 8.48 The Rule Action Page 4. On the Protocols page, you will see the screen that appears in Figure 8.49. On this page you have the option to apply this rule to: · All IP Traffic When you select this option, you allow all protocols to be included in the rule. Remember that when you choose All IP Traffic, only the protocols that have protocol definitions defined will be included when accessed by SecureNAT clients. · Selected Protocols The Selected Protocols option allows you to apply the rule to one or more protocols. · All IP Traffic except selected This option allows you to allow all protocols except those you choose to include in the rule. This choice might be useful if you would like a group of employees to have access to all protocols, with the exception of Napster, NNTP, and FTP, in order to reduce the amount of inbound traffic. For this example, select All IP Traffic, and click Next. Figure 8.49 The Protocols Page 5. On the Schedule page (Figure 8.50), you can choose a schedule from your Schedules policy element. In this example, we want this rule to always be applied, so select the Always option, and click Next. Figure 8.50 The Schedule Page 6. On the Client Type page, you have the following options (Figure 8.51): · Any Request This option applies the rule to all requests from all clients and client types. · Specific Computers (client address sets) T his option applies the rule to a selected set of clients as defined by a client address set. · Specific users and groups Use this option when you want to have this rule applied to users or groups in the forest. For this example, select Any Request, and click Next. Figure 8.51 The Client Type Page 7. On the last page of the wizard, confirm your selections and click Finish. After the rule is added, you can access the configuration parameters of the protocol rule by right clicking on the rule and then clicking the Properties command. Creating a Protocol Rule to Allow Multiple Protocol Definitions: PCAnywhere 9.x Let’s look at how to configure a rule that includes multiple protocol definitions. If you want to connect to an external host running PCAnywhere from a client behind an ISA server, you need to first create several protocol definitions and then configure a protocol rule that will allow access to all the protocol definitions. Before creating the protocol rule, you must create the following protocol definitions: TCP 5631 Outbound TCP 5632 Outbound UDP 5631 Send UDP 5631 Send Each of these is a discrete protocol definition, and each one will be included in the rule. Note that you do not need to create secondary connections, because the PCAnywhere host you call will respond to the dynamic response port created by the ISA server. To create the rule: 1. Open the ISA Management console, expand Servers and Arrays, and then expand Access Policy. Right-click Protocol Rules, click New, and then click Rule. 2. On the first page of the New Protocol Rule Wizard, enter the name of the protocol rule. For this example, call it PCAnywhere. After entering the name, click Next. 3. On the Rule Action page, we want to allow access to these protocols, so select the Allow option button. Click Next. 4. On the Protocols page, select the Selected Protocols option, and then place a check mark in the check boxes for each of the protocol definitions you’ve created to support outbound access to PCAnywhere hosts (Figure 8.52). After selecting the protocol definitions, click Next. Figure 8.52 Selecting the Protocol Definitions for PCAnywhere 5. On the Schedule page, select a schedule that meets your requirement, and then click Next. 6. On the Client type page, make a selection that is appropriate for the client type that you want to have access to the external PCAnywhere clients, then click Next. 7. On the last page of the wizard, review the selections you’ve made, and click Finish. This protocol will be available to both SecureNAT and firewall client computers. If you include user or group access controls, you need to use the firewall client. Creating a Protocol Rule to Allow Access to Multiple Primary Port Connections One issue that comes up from time to time is how to create a protocol definition or rule that will allow for a large range of port numbers to be accessed as primary connections. For example, what if you need to have ports 1025–4000 open for primary connections? You cannot create a protocol definition containing more than a single port for a primary connection. In order to allow all these port numbers to be open for a primary connection, you could create thousands of protocol definitions and then create a rule to allows these definitions. However, that option is not very feasible. First, you should consider using another application that allows the primary connection to a single port and then allows secondary connections. But if you don’t have this option, you’ll need another solution. One option is to create a protocol definition that allows all protocols, and then create a protocol rule that allows access to all protocols except the protocols you do not want users to access. This solution is problematic for the SecureNAT client because these ISA Server clients can only use protocols that are included in the protocol definitions folder. Since no specific protocol definition is used in this example, the SecureNAT client won’t be able to access the protocol and port numbers required for this protocol, which requires multiple primary connection ports be available. You need to implement the firewall client software to make this solution work. Managing Protocol Rules Protocol rules are not numbered, and one rule does not have a priority over the other. However, deny rules are processed before allow rules. When the ISA server receives a request for a particular protocol, it searches its deny rules first to see if one applies. If there is no deny rule, the server searches the allow rules for one that will allow the request. If there is no rule that will allow the request, the ISA server rejects the request. If you want to stop using a protocol rule, you can either delete the rule or disable it. It is a good idea to disable rather than delete a rule. That way, if you need to use the rule again, you do not have to recreate it—all you need to do is enable it again. Enterprise Array Reminder Remember that if you are implementing an enterprise array, you might or might not be able to create protocol rules at the array level. If you are using an enterprise policy that allows array-level policies, you will be able to create protocol rules at the array level. However, you will not be able to create allow rules, as shown in Figure 8.53. When an enterprise policy is in effect, you can only create policies at the array level that are more restrictive than those implemented at the enterprise policy level. In practice, this means that you cannot create any allow rules at the array level. Figure 8.53 The Rule Action Page IP Packet Filters IP packet filters are used to determine the packets that can enter and exit the external interface of the ISA server. Packet filters may be required when you enable packet filtering on the external interface of the ISA server. This option can be enabled locally on a stand-alone ISA server or can be enabled via the enterprise policy for an enterprise array. You should always enable packet filtering when the ISA server is located at the edge of the network. Otherwise, all ports on the ISA server’s external interface will be open at all times. This creates a security configuration you can’t defend and in which you never want to find yourself. Packet filtering is a key feature of your network security scheme when ISA Server is at the edge of your network. We will spend more time on the issue of packet filtering in Chapter 9 in our discussion of configuring the ISA Server firewall features, since most of our concerns regarding packet filtering relate to issues of inbound access. However, a few things appropriate to the discussion of outbound access deserve mention at this time. Dynamic Packet Filtering ISA Server creates response ports whenever an outbound request is allowed. These dynamic response ports open only when they are needed for an allowed communication with an external server, and then they close when they are no longer required. By dynamically opening and closing these ports, you reduce the risk of having a large number of ports open on the external interface of the ISA server. Open ports can pose a security risk. For example, suppose an internal client needs to access a Web server on the Internet. It sends its request to port 8080 on the ISA server. The ISA server then changes the header information in the request, replaces both the source IP address and the source TCP port number, and then opens that port to receive the response from the Internet Web server. Once the communication between the client and the Web server has completed, the port on the external interface used for this exchange will be closed. This process eliminates a potential vector of attack by an Internet intruder. Keep in mind that you do not have to create packet filters for these dynamic response ports. They are created automatically for clients behind the ISA server. Packet Filters for Network Services Located on the ISA Server Dynamic packet filtering is not available for services and applications running on the ISA server itself. For example, you might want to use a newsreader or Web browser, send or receive SMTP, receive POP3 mail, resolve DNS names, or run an FTP or Web server directly on the external interface or the ISA server. Since the ISA server is not an ISA client, you must configure packet filters on the external interface to allow applications running on the ISA server to work correctly. By default, the following packet filters are installed and enabled on the ISA server: · DNS filter · ICMP outbound · ICMP ping response (in) · ICMP source quench · ICMP timeout in · ICMP unreachable in The DNS filter is used to allow the ISA server to resolve DNS queries. The ISA server performs a proxy DNS service for both firewall and Web proxy clients. Therefore, a packet filter is provided that allows outbound access for DNS queries from the external interface of the ISA server. The ICMP filters are used by ISA Server to send and receive ICMP messages that are required to assess network status and error conditions. The ICMP outbound filter allows all types and codes of ICMP messages to leave the external interface of the ISA server. The ICMP ping response (in) filter allows the ISA server to receive ICMP echo response messages in reply to pings sent from the ISA server’s external interface. The ICMP source quench, ICMP timeout, and ICMP unreachable filters allow the ISA server to receive responses from routers informing it of various network error conditions. If you want to use applications or services other than those included with the default filters, you must create your own packet filters. NOTE The default ICMP filters will not allow you to ping the external interface of the ISA server from a remote host. In order to ping from a remote host, you need to enable the ICMP query filter. Note that when you ping the external interface of the ISA server from an internal SecureNAT client, it appears that the external interface is able to respond to ICMP echo requests, even if the ICMP query filter is not enabled. However, if you ping the same interface from an external client, the ping will fail. For security reasons, we strongly recommend against enabling the inbound ICMP query request filter. Examples of Custom Packet Filters Supportin g Applications on the ISA Server Let’s look at two examples demonstrating how you would create packet filters to support popular applications. In this section, we’ll look at packet filters for: · Supporting a Web browser on the ISA Server · Supporting a terminal server on the ISA Server I f you want to use the Web browser on the ISA server, you have two options: · Create a packet filter to allow outbound access to port 80 · Make the Web browser a Web proxy client The best solution to this problem is to make the Web browser a Web proxy client. W hen configuring the browser as a Web proxy client, you should use the internal IP a ddress of the ISA server. Do not use the server name, because the ISA server will try to resolve the name using the DNS server configured on its external interface. This likely will not work, since the public DNS server will not have a host mapping for the internal interface of the ISA server. The problem with this solution is that it doesn’t seem to work on ISA servers using d ial-up connections. If you are using an analog, ISDN, or PPPoE dial-up connection, making the browser a Web proxy client does not seem to work. If you use a dedicated (permanent) connection (not dedicated ISDN) for the external interface, you will be able t o use this method. If you cannot or do not want to set the browser as a Web proxy c lient, you can create a packet filter to allow outbound access. In the packet filter, you w ould use the following parameters: Protocol: TCP Direction: Outbound Local Port: Dynamic (ports 1025-5000) Remote Port: Fixed Port Remote port number: 80 T his allows outbound requests to the Web server’s port 80 and opens a response port in t he dynamic response port range. Packet filters for other services follow a similar pattern. Suppose you have Terminal S ervices running in remote administration mode on the ISA server. You want to make the t erminal server available so that you can administer it over the Internet. You can create a packet filter such as the following: Protocol: TCP Direction: Inbound Local Port: Fixed Port Local port number: 3389 Remote port: All ports Although you can do this to make the terminal server available on the external interface of the ISA Server computer, we strongly recommend against doing so. The T erminal Service port is a well-known port number, and leaving this port number open using a static packet filter could open you up to exploits aimed against Microsoft Terminal S erver. Enablin g PPTP Clients Outbound Access to VPN Servers Y ou can configure SecureNAT clients to call external VPN servers. In order to do this, right-click the IP Packet Filters node in the left pane of the ISA Management console, c lick Properties, and then click the PPTP tab. You will see the screen that appears in Figure 8.54. Figure 8.54 The PPTP Tab After you place a check mark in the check box for PPTP through ISA Firewall, a packet filter will be created. The name of the filter is SecureNAT PPTP. Note that you cannot use this packet filter to make outbound PPTP calls if your computer is a firewall client. If your machine is currently a firewall client, you can disable the firewall client and then configure a default gateway that routes to the internal interface of the ISA server. If there are any active firewall sessions for your computer, you will not be able to make the PPTP call. You can wait for the session to time out, or you can force the session to disconnect via the ISA Management console. Configuring Application Filters That Affect Outbound Access ISA Server includes a group of application filters that listen to inbound and outbound connections and can influence communications intercepted by the application filters. These filters are registered with the Firewall Service and therefore are dependent on the Firewall Service. Application filters are not available for ISA servers that are installed in Web proxy (cache mode) only. The built-in application filters can examine and influence both inbound and outbound access. In this section, we focus on the application filters that affect outbound access. Filters that mainly influence inbound traffic are covered Chapter 9 on configuring ISA Server’s firewall features. FTP Access Filter The FTP access filter provides a full range of FTP services to SecureNAT clients. This filter manages secondary connections on the behalf of SecureNAT clients and makes it possible to use secondary connections without having to create protocol definitions that support secondary connections. The FTP access filter works for both internal clients attempting to access an external FTP server and for external clients attempting to access an internal FTP server. Note that this application filter provides functionality for FTP clients that send a [...]... downstream ISA servers can take advantage of the cache contents of upstream ISA servers · You can route Web proxy requests sent from clients to an ISA server to a Squid server and take advantage of the access controls configured on the ISA server · ISA Server supports outbound PPTP sessions between an internal network client behind an ISA server and a PPTP server located on an external network · The ISA server. .. 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 most common application of routing rules is to support Web proxy chaining Web proxy chains can connect ISA servers located at different sites or... not require that the ISA server in front of the FTP client open new back channels from the FTP server for inbound data Since the FTP client initiates all connections with the FTP server, the FTP server never has to initiate any non-ACK connections with the ISA server SECURITY ALERT! If you have FTP clients sitting behind a firewall other than ISA server and they try to access an FTP server that has been... to enter the local network Configuring ISA Server Packet Filtering 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 With ISA Server, you can choose to enable or disable packet filtering We recommend that you enable packet filtering on the ISA server to ensure the highest... servers if you want to use these on the ISA server TIP You can configure packet filters if you have installed ISA Server in firewall or integrated mode Static packet filters are not available if ISA is installed in caching mode Caching-only ISA Servers are still able to create dynamic packet filters for inbound and outbound requests Enabling Packet Filtering To enable packet filtering on your ISA server, ... and IP routing must be enabled on the ISA server When Packet Filtering Is Disabled If packet filtering is not enabled, the ISA server s external interface listens on all ports that have running services on the ISA Server computer The default installation of Windows 2000 includes many network services that open ports that could allow an intruder to attack the ISA server and potentially gain valuable... authenticate to the Web Proxy Service before accessing Web content Chapter 9 Configuring ISA Server for Inbound Access Solutions in this chapter: · Configuring ISA Server Packet Filtering · Application Filters That Affect Inbound Access · Designing Perimeter Networks Introduction In Chapter 8, we focused on how to configure an ISA server to allow for outbound access and how to configure outbound access... the external interface of the ISA server If you don’t have a packet filter in place to allow a particular packet through the ISA server, the packet will be dropped If there is a packet filter, the header information in the packet must match parameters in a packet filter rule before the packet will be accepted and passed through the ISA server Default Packet Filters ISA Server includes packet filters... internal interface of the ISA server, and tell it to use port 1080 (or an alternate port if you have changed the SOCKS V4 filter settings) Streaming Media Filter The streaming media filter allows you to make multimedia protocols available to your ISA Server clients The client can be internal computer behind the ISA server or an external client accessing a Windows Media Services server that has been published... the following options: · Disable WMT live stream splitting Select this option if you do not want to use live stream splitting You will still have access to the protocols installed by the streaming media filter · Split live streams using a local WMT server If you select this option, Windows Media Server must be installed on the ISA server Use this option if you have a single ISA server · Split live streams . for: · Supporting a Web browser on the ISA Server · Supporting a terminal server on the ISA Server I f you want to use the Web browser on the ISA server, you have two options: · Create. with the ISA server. SECURITY ALERT! If you have FTP clients sitting behind a firewall other than ISA server and they try to access an FTP server that has been published by an ISA server, . POP3 mail, resolve DNS names, or run an FTP or Web server directly on the external interface or the ISA server. Since the ISA server is not an ISA client, you must configure packet filters on