Export (0) Print
Expand All
5 out of 7 rated this helpful - Rate this topic

Firewall policy best practices

These best practices will help you create a firewall policy that results in the policy behaviors you want and provide security benefits, and they can help you boost the performance of your Microsoft Forefront Threat Management Gateway deployment.

The performance of Forefront TMG is related to the type of information it requires to evaluate the rules. Because rules are evaluated in order, you want to place the rules that can be processed quickly near the top of the rule list if this does not interfere with the behavior of the firewall policy you have designed. This way, if a request matches a rule that is high in the order, Forefront TMG does not have to compare the request to rules that might take longer to process.

Simple Rule Elements

The following rule elements require simple networking information and therefore are evaluated quickly:

  • Protocol definitions
  • Schedules
  • All IP address based network elements (computers, computer sets, subnets, networks, and network sets)

Also, source port information is evaluated quickly.

Rules that use these elements should be placed at the top of the rule list.

Complex Rule Elements

The following rule elements require additional networking information and therefore are evaluated more slowly:

  • Domain name sets and URL sets
  • Users (other than the built-in "All Users" user set)
  • Content type

Rules that contain such elements should be placed at the bottom of the rule list.

Rules Using Application Filters

Rules that use the SMTP filter, HTTP filter, or FTP filter slow performance.

General Rule Order Recommendations

We recommend that you organize your access rules in this order:

  1. Global deny rules . Rules that deny specific access to all users. These rules should use the rule elements that require simple networking information. An example of such a rule would be a rule that denies all users access from anywhere to anywhere on protocols used for peer-to-peer file sharing.
  2. Global allow rules. Rules that allow specific access to all users. These rules should use the rule elements that require simple networking information. An example of this would be a rule allowing access on the DNS protocol from the Internal network to the External network.
  3. Rules for specific computers. Rules that allow or deny access for specific computers, for example, a rule allowing UNIX computers access to the Internet.
  4. Rules for specific users, URLs, and MIME types, and also publishing rules. Rules that contain rule elements that require additional networking information and that enforce policy for specific users, or for specific URLs or Multipurpose Internet Mail Extensions (MIME) types. Publishing rules should also occur at this point in the rule order.
  5. Other allow rules. Rules that handle traffic that does not match rules that occur previously in the list of rules, assuming the traffic is allowed by your corporate policy. For example, a rule allowing all traffic from the Internal network to the Internet.
    Cc995156.note(en-us,TechNet.10).gifNote:
    Server publishing and Web publishing rules can be placed anywhere in the rule order after global allow or deny rules.

The following best practices should be considered when creating firewall policy.

User Sets and Unauthenticated Users

Place rules that are based on user sets lower in the rule order. If you put these rules high in the rule order, you preclude further processing of traffic coming from unauthenticated users who otherwise match the rule definition. This may have the unintended effect of an allow rule functioning as a deny rule for unauthenticated users.

Forefront TMG drops traffic from unauthenticated users after rules based on user sets, to preclude the bypassing by unauthenticated users of the rules based on user sets.

Cc995156.note(en-us,TechNet.10).gifNote:
Forefront TMG can only try to match authenticated users against rules that require client membership in a user set. Authenticated users include Firewall clients, virtual private network (VPN) clients, and authenticated Web clients.

Use IP Addresses

Where possible, use IP addresses rather than DNS names in your firewall policies. This reduces the reliance of Forefront TMG on the DNS servers, and this results in better performance. However, be aware that in some situations, you will not achieve the desired behavior by using IP addresses. For example, if you are trying to deny access to a site and the site’s IP address is assigned dynamically, or if the site has more than one IP address, blocking an IP address does not block the site reliably. In this case, you should use the fully qualified domain name (FQDN) to block the site. For extra reliability, you can use both IP addresses and FQDNs in a rule. Note that you have to create separate rule elements for the IP addresses and for the FQDNs. When you use IP addresses and FQDNs in a single rule, the Forefront TMG rule engine first evaluates the request using the IP addresses, so that if there is a match, there is no need to try to resolve the FQDN to an IP address. This improves the efficiency of the rule. For examples of how Forefront TMG evaluates names and IP addresses in HTTP requests, see Name Evaluation in this document.

Use Fully Qualified Domain Names for URL Sets and Domain Name Sets

Use fully qualified domain names (FQDN) in domain name sets and URL sets.

For examples of how Forefront TMG evaluates URLs and IP addresses in HTTP requests, see Name Evaluation in this document.

User Authentication and Performance

When a rule requires user authentication, it must rely on connectivity to and speed of the authenticating server, such as the domain controller or Remote Authentication Dial-In User Service (RADIUS) server. The authentication process can affect the performance of Forefront TMG. We therefore recommend that rules requiring authentication be placed near the bottom of the list of rules (assuming that this conforms to your policy design), so that only traffic that is not matched by an earlier rule will encounter the authenticating rule.

Cc995156.note(en-us,TechNet.10).gifNote:
You can use Forefront TMG connectivity verifiers to monitor connectivity with various servers. Connectivity verifiers are described in Forefront TMG Help.

Firewall Clients and User Sets

If the firewall policy includes a rule that refers to a user set (other than the default All Users), the Firewall client always tries to authenticate and will fail if in a workgroup or in an untrusted domain. The firewall client will not be able to establish a connection with the Forefront TMG computer, and no traffic will be allowed.

Protocol Definitions

Do not create protocol definitions that duplicate or overlap existing protocol definitions. This can lead to unexpected behavior. For example, you may create a rule that allows all traffic except for a specific protocol, and you may find that the traffic you meant to deny on that protocol is actually allowed because there is a similar protocol defined. We recommend that you check the list of existing protocols carefully before you define additional protocols.

Rules by MIME Type

MIME types should be used as a criterion only in rules that apply solely to HTTP traffic. Because MIME types are not applicable to other types of traffic, a rule that includes any protocol other than HTTP and refers to MIME types is effectively disabled for those protocols.

Access Rules and Network Rules

An access policy that defines access between two networks will not allow access unless there is also a network rule defining the relationship between those two networks. This is also true for server publishing rules, but not for Web publishing rules.

Deny Access Rule on All Protocols with Source Port Restriction

Do not create a deny access rule on all protocols that includes a source port restriction. Because source ports are not checked for secondary connections, all protocols will then be blocked on secondary connections (if the rule allowing the secondary connection is lower in the rule order than the deny access rule with the source port restriction).

Secure the Remote Management Computers Computer Set

Restrict membership in the Remote Management Computers computer set to computers that require remote administration access. For example, do not add entire networks, such as the Internal network, to the computer set. This helps protect the firewall from worms that affect those networks.

Network for Infected Computers

Create a network to contain computers that are infected. Do not create any network rules for the network, so that it will not have any access. When a computer is infected, move it into that network. Note that each computer that you move into this network creates a gap in the address range of the Internal network, thus fragmenting it. Fragmented networks have a negative performance impact on Forefront TMG Network Load Balancing (NLB), so this approach should be used carefully, and computers should be returned to their original network as quickly as possible.

Access Rule for Windows Update

To enable access to the Windows Update servers, create an access rule allowing access for users to the Microsoft Update Domain Name Set. This rule should be placed high in the ordered list of firewall policy rules. In particular, it must precede Web access rules that require authentication, which may block some users from obtaining updates from Windows Update.

Cc995156.note(en-us,TechNet.10).gifNote:
In this scenario, on the Web proxy tab for the user network, after you click Authentication, you should not select Require all users to authenticate, because this will also block access to Windows Update.

When a client makes an HTTP request, it may be a name, an FQDN, or an IP address. This topic provides examples of how Forefront TMG handles these requests.

If an HTTP request uses a site name, such as http://www.fabrikam.com, Forefront TMG recognizes the name in the request and performs a forward name resolution to a DNS server to get the FQDN, aliases, and the IP addresses associated with that name. The result is that Forefront TMG has available the site name, the FQDN, the aliases, and the IP addresses to compare to the access rule requirements. Any one of those elements could be a match to the rule, depending on which element was used in the rule.

In the example of www.fabrikam.com, the following elements could match an access rule:

  • Name: www.fabrikam.com
  • FQDN: fabrikam.com
  • IP addresses: 207.46.250.119, 207.46.130.108

If an HTTP request uses an IP address, Forefront TMG first checks the rules to see if a rule matches that IP address. During this process, if Forefront TMG encounters a rule that requires a name, it performs reverse name resolution to obtain the FQDN for that IP address. Forefront TMG can then compare the FQDN to the access rule definitions.

If the reverse name resolution fails, only the original IP address in the request is used in comparison to the rule definitions.

Cc995156.note(en-us,TechNet.10).gifNote:
In the case of a SecureNAT client requesting a site by name, Forefront TMG first verifies that the host header content is not masking an unrelated IP address requested by the client. If this verification succeeds, the process continues as it would for a Web Proxy client.
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.