کد:
http://articles.techrepublic.com.com/5100-22_11-5845110.html?tag=rbxccnbtr1
Takeaway: ISA Server 2004 can be a powerful firewall, but there are tricks to making it work efficiently. Here are 20 tips to help you tune ISA Server 2004 as a firewall in your organization.
In most shops, firewall configuration is something left to the consultant. For some reason, many organizations are very wary of installing, configuring and managing their own network firewalls. It might be that no one is interested in managing the firewall, but more likely, it's that there is a perceived complexity and massive learning curve that leads more network admins to avoid the firewall.
However, things seem to be changing with the introduction of ISA Server 2004 (ISA firewall). The ISA firewall brings all the stateful packet and application layer inspection capabilities seen in firewalls costing five to ten times that of the ISA firewall. But more significant than the impressive price point, is the ISA firewall's ease of use compared to other enterprise level firewalls. Now more general practice network administrators are willing to install, configure and manage the network firewall, because they don't have to make it a vocation to learn an interminable list of arcane commands and the infinite number of switches associated with these commands.
If you have an ISA firewall in production now, you're probably happy with the current configuration and it's running quietly and without fail. Now you want to move your knowledge, and the ISA firewall's reliability and performance to the next level. What you need to know are the secrets of ISA firewall professionals: those tips, tricks and field practices that ISA firewall pros use everyday. Here are 20 secrets, tips, tricks and best field practices that ISA firewall pros use everyday to insure that their ISA firewall installations are reliable and provide the best performance and user experience possible.
Consider the type of logging you want to perform and what features you need

The ISA firewall supports three types of logging: text file, MSDE, and SQL. Text file logging provides the best performance, MSDE provides the best features and flexibility, and SQL provides for off-box logging, but the worst performance. Also consider whether you want to log using W3C format or ISA file format; the latter enables you to get the local time in the ISA firewall logs, which W3C format is more useful in world-wide distributed network where GMT is better to use for event correlation. The Logging Properties dialog box is shown in Figure A.
Figure A

The Firewall Logging Properties dialog box Don't use the ISA firewall as a router; it's a stateful deep packet inspection firewall

The ISA firewall is a stateful packet and application layer inspection firewall, it's not a glorified router like some of the "hardware" firewalls you might be accustomed to using. Because the ISA firewall is a stateful packet inspection firewall, the ISA firewall must be aware of the network layer "state" of a connection in progress, or the ISA firewall will drop the connection. For that reason, don't use the ISA firewall in the same way you use a router. While the ISA firewall does support both Route and NAT relationships between source and destination networks, the ISA firewall still performs stateful packet inspection so the request and response paths must be the same in certain scenarios. Check out the KB article "ISA Server 2004 does not support traffic redirection."
Remove the all-subnets broadcast network entry from the definition of the ISA firewall network

By default, the ISA firewall will enter the all subnets broadcast address range to the definition of the ISA firewall Network if you select the Adapter option when defining an ISA firewall Network. If you use multiple subnets in the same classfull network ID, then you should remove the all subnets broadcast address range to prevent error messages from being generated when you try to create a new ISA firewall Network using another subnet of the same classfull network ID, as shown in Figure B.
Figure B

The Select Network Adapters dialog box used to define ISA firewall Networks Policy changes take place only for new connections. The Firewall state table isn't changed for existing connections unless you restart the Firewall service

The ISA firewall does not apply firewall policy changes to established connections. The ISA firewall maintains a connection table and the connection table is not automatically updated to reflect changes in firewall policy. If you want to force the new firewall policy on active connections, then restart the firewall service, or manually disconnect sessions reflecting sessions that should be denied by the new firewall policy. Check out the article titled Changes to the firewall policy only affect new connections in ISA Server 2004 for more info.
Put the ISA firewall in the path to increase security

One of the worst things you can do to an ISA firewall (from the perspective of an organization's overall security posture) is to deploy a single NIC/unihomed ISA firewall. In order for firewalls to provide network security, they must be in the request/response path. It's quite simple for attackers (and even casual users) to bypass access controls configured on unihomed ISA firewalls.
Make sure that:

  • The ISA firewall has two or more NICs
  • The ISA firewall is deployed in full firewall mode
  • The ISA firewall is the request/response path for all hosts requiring the ISA firewall's stateful packet and application layer inspection security.

Deploy the ISA firewall consistent with its design spec: as a stateful packet and application layer inspection firewall, as shown in Figure C.
Figure C

Put the ISA firewall in the request/response path to obtain superior network firewall protection Learn to use the ISA firewall's log filtering to solve problems, track users, etc.

The ISA firewall includes a powerful log query system right out of the box. When the ISA firewall is deployed together with Web proxy and Firewall clients, you can get a complete view of what users are accessing what resources at what time using what application from what machine name. You also get full URLs for sites user site access.
The ISA firewall's log filtering capabilities enable you to drill down on what users are doing, what applications they use to access Internet sites, determine the amount of traffic generated per user and much more. Take some time to learn how to use the ISA firewall's filtering feature and how to export the filtered information to a database or spreadsheet file to get the most out of your investigations.
Plan your route relationships

The ISA firewall uses Network Rules to connect ISA firewall networks. If a Network Rule defining how the source and destination Network is connected doesn't exist, then the connection is dropped. Consider in advance whether you want to use a Route or NAT relationship between source and destination Networks, as shown in Figure D.
Figure D

Network Rules define either a Route or NAT relationship NAT is a bit more secure because it hides the source IP address of the host on the NATed site of the connection. Route is more flexible because not all protocols support NAT, and because routed connections allow you to use both Publishing and Access Rules to control traffic between the source and destination ISA firewall Networks.
Create ISA firewall networks for all known networks

One problem many ISA firewall admins have is that they carry over ISA Server 2000 concepts and practices over to their ISA 2004 firewalls. ISA 2000 firewall admins tend to think that the network to which the external interface of the ISA firewall is connected as being part of the default External Network. This isn't true with the new ISA firewall.
The default External Network is defined as all addresses that aren't included in any other ISA firewall Network definition. For example, if you have a DMZ between a front-end and back-end ISA firewall, then on the back-end ISA firewall you can define an ISA firewall Network for the DMZ segment, and then configure a Route relationship between Protected Networks behind the back-end ISA firewall and the DMZ. At the same time, you can configure a NAT relationship between Protected Networks behind the back-end ISA firewall and the default External Network (which is the Internet and any other addresses that aren't included in an ISA firewall Network definition). You should shy away from concepts of "internal" and "external" and think in terms of ISA firewall Networks and how you want to route connections between any two ISA firewall Networks.
Turn on the Web proxy cache

While the ISA firewall supports Web caching via its Web Proxy filter, the caching feature is not enabled by default. Even with the caching feature disabled, the ISA firewall's Web proxy filter will continue to function, as Web caching and Web proxy are not the same thing. ISA firewall admins often confuse Web proxy with Web caching; I see this on an almost daily basis where ISA firewall admins refer to the unihomed Web proxy configuration as caching-only mode. A unihomed ISA firewall is actually in Web proxy mode, since you can configure the unihomed ISA firewall as a Web proxy server without using the caching component.
You need to define a cache drive before Web caching is enabled on the ISA firewall. Each cache drive supports up to 10GB of cached Web data. For example, if you have multiple partitions on multiple disks, you can create a cache drives on each of the partitions, with each partition hosting up to 10GB of cached Web data. In practice, you should place the Web cache on different spindles from drives where the ISA firewall and operating system software is located. Log files (if on-box logging is used), should be placed on a different spindle from both the operating system/firewall software and cache drives. The Cache Rules Tasks are shown in Figure E.
Figure E

Define Cache Drives to enable Web proxy Filter mediated caching Turn off the RPC filter for autoenrollment and MMC
certificate requests

The easiest way to obtain a certificate is to use the Certificates MMC snap-in. However, if you want to obtain a machine or user certificate for the ISA firewall using the Certificates MMC, you'll need to disable the RPC filter for the duration of the certificate request, as shown in Figure F. If you tried to obtain a certificate using the Certificates MMC and the attempt failed, and then disable the RPC filter, you'll find that request will fail again.
Figure F

The solution to this problem is to restart the ISA firewall. Once you obtain your certificates, make sure you re-enable the ISA firewall's RPC filter (you won't have to restart the Firewall again). Also, be aware that the RPC filter on the ISA firewall will prevent the ISA firewall from using autoenrollment of machine certificates; if and also prevents hosts separated from the enterprise CA by an ISA firewall from obtaining a machine certificate using autoenrollment.
Put network servers and services on a dedicated
network services segment

This is a critical component of your ISA firewall's defense in depth plan. The ISA firewall was designed based on the realities of 21st-century network environments: no networks can be trusted. You can significantly improve your level of security by placing critical network services on one or more network services segments. For example, you might want to create a network services segment for you Exchange Server organization, another network services segment for your domain controllers, and another network services segment for your Web and database servers.
Then you create firewall policy that allows only the required communications between these segment with each other, and with the user network segments. The ISA firewall enables you to get this granular level of access control for traffic traversing the ISA firewall. Check out the article titled Configuring Multiple DMZs with ISA Firewalls for some examples of creating security zones using the ISA firewall.
Make the ISA firewall a domain member

This is a key issue in getting the highest level of security for your ISA firewall. Yes, I know there are security wankers out there who think this is not a secure configuration, but they are unequivocally and incontrovertibly incorrect. While there are purely theoretical reasons for this being a potential security issue (none of which has ever seen an actual proof of concept), there are many security advantages to making the ISA firewall a member of the domain:

  • Transparent authentication for Web proxy and Firewall clients
  • The ability to fully leverage the Firewall client,
  • The ability to use user certificate authentication for Web publishing rules,
  • Centralized management of the ISA firewall devices via Group Policy
  • Superior logging and reporting

In most deployments scenarios, the ISA firewall should be a domain member. However, the ISA firewall doesn't need to be made a domain member if domain membership doesn't add to the deployment's overall security position. For example, if you have a back to back ISA firewall configuration, there's no reason to make the front-end ISA firewall a domain member, since users won't be authenticating with the front-end ISA firewall.
Order access rules appropriately

Constructing firewall policy correctly is tricky for all firewalls and the ISA firewall is no exception. If you really want to get your firewall policy down right, then check out Optimizing ISA Server 2004 Firewall Policies. However, if you don't have the time or the inclination to get into the details of constructing an effective firewall policy rule set, you can do yourself a favor and put your anonymous deny rules before your anonymous allow rules, and put your authenticated deny rules before you authenticated allow rules. Finally, put all anonymous rules before authenticated rules.
Configure separate listeners for HTTP and SSL

One of the major limitations of the ISA Server 2000 firewall was the global nature of Web listener settings; you didn't have the ability to set custom authentication, time outs, connections limits and other settings for each listener. The new ISA firewall fixes this problem by enabling you to create multiple listeners using the same IP address, through the interface shown in Figure G.
Figure G

Granular Web Listener control introduced with ISA 2004 firewalls For example, suppose you have a single IP address bound to the external interface of the ISA firewall. With ISA Server 2000, you could create one listener with this address. With ISA Server 2004, you can create two listeners, one SSL listener and one HTTP listener. You can then bind a certificate to the SSL listener and configure custom authentication and other options for that listener. Then you can create an HTTP listener using the same IP address, and configure different authentication, time outs, connections limits and other settings. Whenever you create a new listener, make sure you have configured it to listen for either HTTP or SSL, but not both.
Configure System Policy to meet your network's custom requirements

A default System Policy is applied to the ISA firewall after installation is complete. System Policy is used to define what communicates are allowed from the ISA firewall and to the ISA firewall. System Policy does not control communications moving through the ISA firewall. Because System Policy controls the most critical communications directly to and from the ISA firewall device itself, its mandatory that you check the default System Policy assigned to the ISA firewall after installation. Review each System Policy Rule and determine if you need that rule, and if you don't, disable the System Policy Rule.
Configure Web proxy clients to use the autoconfiguration script or autodiscovery

There are several ways ISA clients can benefit from the ISA firewall's Web proxy filter (note that there is no longer a Web proxy service; the Web proxy filter is just a filter add-on to the ISA firewall's firewall feature set). SecureNAT clients can automatically benefit from the Web proxy filter when the Web proxy filter is bound to the HTTP protocol (which is the default setting). Web browsers can be configured as Web proxy clients.
Web proxy clients experience much better Web performance and user satisfaction because of the Web proxy client's superior Web performance. You can configure the browser to be a Web proxy clients by using WPAD/autodiscovery, by manually configuring the browser to use the URL to access the autoconfiguration script, by automatically configuring the browser during Firewall client setup, or to configure the Web browser to use the address and port number to connect to the Web proxy filter.
The best options are autodiscovery or configuring the client to use the autoconfiguration script (either manually or via Group Policy). Both autodiscovery and configuration of the autoconfiguration script have the same results. You want the Web proxy clients to have access to the autoconfiguration information because this enables you to configure Web browser settings at the ISA firewall.
The most important Web browser configuration is that for Direct Access. When you configure sites and addresses for Direct Access, the machine bypasses the Web proxy client configuration and leverages its SecureNAT or Firewall client configuration to make the connection. Stefaan Pouseele has done a great article on autoconfigure for Firewall and Web proxy clients. Check out Understanding the Web Proxy and Firewall Client Automatic Configuration. The firewall client configuration dialog box is shown in Figure H.
Figure H

Configuring interface for Web proxy client settings during Firewall client configuration Install the firewall client share on a file server, not on the ISA firewall device

Most ISA firewall admins install the Firewall client share on the ISA firewall itself. This is unfortunate, because this requires that you allow users to establish a CIFS/SMB connection to the ISA firewall. In general, its poor security practice to allow file sharing protocols directly to the firewall. You can avoid this problem by placing the Firewall client share on a dedicated file server. Then you can instruct users, log on scripts, or Group Policy to deliver the Firewall client software to the client workstations from the dedicated file server.
Store the WPAD.DAT file on a Web server

When a Web browser or Firewall client uses autodiscovery to access autoconfiguration information, the WPAD information provided by DNS or DHCP instructs the client machine to connect to the ISA firewall to obtain this information from the ISA firewall device itself. Our ultimate goal is always to minimize all possible connections to and from the ISA firewall device itself. You can get around that problem by copying the wpad.dat file from the ISA firewall and hosting it on a Web server on your corporate network. You can download the wpad.dat file by requesting it from the ISA firewall using the http://isafirewall_name/wpad.dat.
Create network objects for granular access control

The ISA firewall allows you to get very fine tuned access control by creating all types of network objects representing source and destination locations. Network objects include ISA firewall Networks, Computers, Computer Sets, Network Sets, Address Ranges, Subnets, URL Sets, Domain Name Sets and Web Listeners. You can use all of these Network Objects to obtain very finely tuned access control over source and destination for any rule. Make use of the default Network Objects and create your own whenever policy would benefit from a custom Network Objects.
Avoid the SecureNAT configuration whenever possible

The SecureNAT client was designed to support hosts that cannot be configured as Web proxy or Firewall clients, or for network servers. The SecureNAT client was not designed to support fear, mistrust, or misunderstanding of the Firewall and Web proxy client configurations.
The only circumstances when you should configure a host as only a SecureNAT client is when:

  • The host does not support the Firewall client software, or
  • The machine is a server.

Only Windows operating systems support the Firewall client software, so all non-Windows machine may require SecureNAT configuration. However, if the non-Windows operating systems only require Web proxy access, then configure them only as Web proxy clients only. Almost all operating systems support the Web proxy client configuration. Servers should not have logged on users, therefore, there is no reason to configure them as Web proxy or Firewall clients, in addition to the fact that you should not install the Firewall client on servers.
But wait--there's more!

Well, that brings us up to number 20 on our hit list of ISA firewall optimization secrets. I initially intended for this to be a two part article, but it looks like it's going to be at least three parts. There are a lot of ISA secrets yet to be told. See you for part 2



موضوعات مشابه: