کد:
http://articles.techrepublic.com.com/5100-22_11-5845113.html?tag=rbxccnbtr1
Takeaway: If you're using ISA Server 2004 as a firewall on your network, you know that there are lots of different settings you can use to set it up. Here are 12 tips to help make the most of ISA Server 2004 as a firewall.
In the article "Twenty ISA Server 2004 tips to fine-tune your firewall", I shared twenty of my favorite ISA secrets that I've learned in working closely with many different ISA firewall configurations in a number of different networking environments. This article continues in that tradition, with twelve more tips that will help you get the best protection for your network out of your ISA firewall while providing seamless accessibility for your users.
Avoid creating Deny rules

A key principle when implementing any kind of security, whether it is network or host security, is the principle of least privilege. The principle of least privilege dictates that users should have access to resources and protocols they require to get their jobs done. They should not have access to any other protocols or sites.
That part is no secret, but it's not always as easy to put into practice as it sounds. Your ability to implement least privilege depends on the networking and social environment. If you use the ISA firewall to provide stateful packet and application layer inspection in an ISP environment, then least privilege can't be meaningfully applied, because your job is to enable access to a wide range of resources that you can't predict. However, if you manage a business network, then implementing least privilege should always be in the forefront of your mind when planning the network security infrastructure and you should do everything you can to get executive buy-in for the application of least privilege for Internet access (and corporate network resource access as well).
The secret is that when least privilege is applied, there is no reason to create Deny rules because users only have access to what is required. This is a much better approach to firewall policy than playing the losing game of creating deny rule after deny rule as you discover threats or sites that need to be blocked. You'll end up chasing your tail if you manage firewall policy with a default "All Open" rule and then layer deny rules on top of it. This has been the traditional "hardware" firewall approach to network security, and you don't want to reduce your security to that provided by a conventional stateful packet inspection-only "hardware" firewall when you have a sophisticated application layer firewall to work with.
Use the All Protected Networks network object when applicable

The ISA firewall includes a number of Network Objects you can use to define the source and destination in ISA firewall Access Rules. One group that's especially useful is the Network Set, shown in Figure A.
Figure A:

The Network Objects group

Many administrators don't understand how to use this object, so they just ignore it. Network Sets allow you to group ISA firewall Networks into meaningful collections and apply those collections of ISA firewall Networks to source and destination entries in ISA firewall Access Rules.
The All Protected Networks Network Set can be used when you want to allow or deny access from all ISA firewall Networks except for the default External Network. This exclusion is shown in Figure B.
Figure B:

Definition of the All Protected Networks object

For example, suppose a new network worm is released into the wild and uses a specific port to gain access to victim computers. You can block that port for all ISA firewall Networks using the All Protected Networks Network Set. You don't have to worry about blocking the worm port inbound, because you would have to explicitly create a publishing rule or access rule to allow the inbound connections to the worm port, which you wouldn't do.
Use RADIUS authentication only when required

The ISA firewall supports RADIUS authentication for Web proxy and VPN clients. The primary reason for using RADIUS authentication is to support authentication of VPN and Web proxy clients (which includes reverse proxy support via Web Publishing Rules) for ISA firewalls that aren't domain members. In general, you should avoid using RADIUS authentication because it is an ISA firewall best practice to make the ISA firewall a domain member, and RADIUS authentication is neither required nor desired when the ISA firewall is a domain member.
However, there are times when RADIUS authentication is required, such as when corporate security "experts" try to harpoon your ISA firewall's security posture by insisting that it shouldn't be part of the domain. Another time when you might want to use RADIUS authentication is when the ISA firewall is a member of a domain, but you have a Web Publishing Rule that publishes a server that's a member of a different domain, and the users are members of the other domain; in this case, you can use RADIUS to authenticate users who aren't members of the ISA firewall's domain, as shown in Figure C.
Figure C:

Web publishing rule that uses RADIUS authentication

There is another scenario in which RADIUS authentication and RADIUS remote access policy are required, and that's when you deploy remote access VPN quarantine on the ISA firewall. While this feature unfortunately hasn't found widespread adoption (probably because of the significant programming overhead required to make it work), there's a good chance that we'll see a major fix to this issue later this year and VPN-Q will become more popular. However, keep in mind that you don't need to subvert your ISA firewall's security by removing it from the domain in this scenario. You can have the ISA firewall as a domain member and still use RADIUS authentication for VPN clients (or Web proxy clients, if you need to).
Use the FWENGMON utility to determine port bindings

With the ISA Server 2000 firewall, you could determine whether your Web or Server Publishing Rule was working by using the netstat na command and looking for the appropriate listening socket. That approach won't work with the new ISA firewall because the 2004 ISA firewall uses an approach called "port stealing" that effectively hides the listening port from the netstat command.
Here's a useful secret: You can still check on the status of the publishing rule's listener using the FWENGMON utility, which you can download from the Microsoft Web site. The FWENGMON tool can do many more things in addition to checking listener status, so make sure to read the accompanying documentation to get the most out of this very cool tool.
Disable the Web proxy filter to enforce direct access

Direct Access takes place when the client system bypasses the ISA firewall's Web proxy filter to access Internet content. Some Web sites require Direct Access. Common sites requiring Direct Access are the MSN and Hotmail sites (when authentication is required at the ISA firewall to access the Web proxy filter component, and when using Outlook Express to access a Hotmail account).
Direct Access is also often required to bypass architectural and coding flaws in Java sites. You can configure Direct Access at the ISA firewall, at the client, or both. However, there's a secret to making it work: in order to complete the process of Direct Access, you must unbind the Web Proxy filter from the HTTP protocol.
When the Web proxy filter is bound to the HTTP protocol, connections from SecureNAT and Firewall clients are automatically forwarded to the Web proxy filter and work like de facto Web proxy clients (with the exception that SecureNAT clients cannot authenticate to the ISA firewall). What happens is that even if you configure the sites for Direct Access and the client machine knows that it should bypass its Web proxy configuration to access the site, the Web proxy filter will "hijack" the connection from Firewall and SecureNAT clients and prevent the Direct Access connection you desire.
A side-effect of unbinding the Web proxy filter from the HTTP protocol is that the HTTP Security Filter configuration interface is no longer visible in the ISA firewall console. Note that even though the configuration interface is not visible, HTTP Security Filter settings are still applied to Web Proxy clients when they connect to non-Direct Access sites.
You can remove the Web proxy filter from the HTTP protocol by removing the checkmark from the checkbox in the definition of the HTTP protocol, as shown in Figure D.
Figure D:

Removing the Web proxy filter from the HTTP protocol definition

Use PerfMon to troubleshoot performance issues

It seems as if a day doesn't go by when I don't hear a fledgling ISA firewall admin say, "The Internet is slow ever since I put in the ISA firewall." Since the ISA firewall is a gigabit firewall, it's unlikely that the ISA firewall architecture is the reason for the network slowness. So what's the secret to this common performance problem?
It's almost always a software configuration or a hardware issue that's causing the "slowness." There are two tools that hold the keys to success in troubleshooting performance problems with the ISA firewall: Network Monitor (packet traces) and the Windows Performance Monitor. Start by running the ISA firewall Performance Monitor, as shown in Figure E, and then add more ISA firewall-specific monitoring objects to the console.
Figure E:

The ISA firewall's Performance Monitor console

Don't publish Web sites using an IP address as the public name

The ISA firewall's Web Publishing Rule Wizard allows you to enter either an IP address or a Fully Qualified Domain Name (FQDN) that the remote user must use to connect to the Web site published by the Web Publishing Rule. However, one of the worst things you can do is publish a site using an IP address. That's because automated attacks and network worms almost exclusively use only IP addresses to connect to Web sites.
If you enter an IP address in the Public Name tab of the Web Publishing Rule, then you potentially open your sites up for worms and similar automated attacks. The secret to protecting against these threats is simple: You can easily bypass this security risk by always using FQDNs in your Web Publishing Rules, as shown in Figure F.
Figure F:

Always use FQDNs on for the public name used to access your Web sites

Check the Windows event viewer to troubleshoot ISA firewall problems

I review well over two hundred ISAServer.org Web board and mailing list messages a day. One of the most common responses I give when answering questions is "what does the Event Log have to say about this?" I never cease to be amazed by the number of ISA firewall admins who haven't checked the Event Viewer for potential hints at what the configuration error might be. The Event Viewer seems to be one of ISA's best kept secrets, but we need to get it out in the open. Always check the ISA firewall device's Event Viewer for diagnostic information useful in troubleshooting ISA firewall problems. You'll find a lot of useful info there, as shown in Figure G.
Figure G:

The Windows Event Viewer often provides valuable troubleshooting information

Check the ISA Alert tab for detailed information on troubleshooting issues

While almost all of the information regarding ISA firewall troubleshooting issues will appear in the Event Viewer, there may be some "secret" information that the ISA firewall keeps in its own Alerts section in the ISA firewall console (I say "may" because I'm not aware of whether it's been documented anywhere as to whether the ISA firewall's Alerts tab shows the exact same information as the Event Viewer). Always check the ISA firewall's Alerts tab on the Monitoring node, as shown in Figure H, when you're trying to figure out a problem with the ISA firewall.
Figure H:

Checking the Alerts tab

Solve MTU issues with an upstream router for SMB/SOHO networks

h6/Medium Business (SMB) and h6 Office/Home Office (SOHO) networks often need to use PPP over Ethernet (PPPoE) when using DSL connections to the Internet, because PPPoE is required by their ISPs. DSL is well known for causing MTU issues when using PPPoE. (MTU stands for maximum transmission unit, and refers to the largest packet size that can be transferred in a single physical frame.)
Another problem with h6 networks is that they often use DHCP addressing for the public interface. This means the address can change.
Here's the secret: You can solve both the MTU and the DHCP issues by putting a DSL router in front of the ISA firewall.
If you still want to connect a DSL modem to the ISA firewall instead of using a DSL router, you can solve the MTU issue by using the principles and procedures contained in David Fosbenner's article ISA Server 2000 and DSL.The referenced article describes how to edit the registry to solve your MTU issues, as shown in Figure I.
Figure I:

Fixing MTU issues by editing the registry

Dedicate different ISA firewalls for inbound and outbound connections

Here's a secret that will speed up access to your published Web sites. If you have published an even moderately busy Web site through your ISA firewall, you can get significant performance benefits by deploying two different ISA firewalls for inbound and outbound access. The inbound access ISA firewall is dedicated to Web and Server Publishing Rules and the outbound access ISA firewall is used to control Internet access for users connecting from ISA firewall Protected Networks.
You benefit from each ISA firewall needing to maintain a h6er firewall state table, and also you can focus your attention on the unique requirements and configuration for inbound and outbound access on ISA firewalls dedicated to those purposes. I do this routinely and find that performance and stability are measurably better.
Force firewall policy on VPN clients

In contrast to the typical "hardware" firewall, the ISA firewall's VPN server and gateway components enable you to get very fine tuned access control over what moves between VPN clients/gateways and Networks to which these hosts connect through the ISA firewall. Because the VPN client connection is an authenticated connection, you can use user/group based access controls on VPN users, and that's the secret to granular control.
For example, you might let all domain users connect to the VPN server, but you do not want all VPN users to have the same level of access to corporate network or Internet resources when connected to the network through the VPN link. This is a no-brainer for the ISA firewall. Create your access policies for VPN client connections and assign them to users who require access to a specific resource on the corporate network or the Internet



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