Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

ISA Firewall Access Rule Elements

You construct Access Rules using Policy Elements. One of the major improvements in the new ISA firewall over ISA Server 2000 is the ability to create all Policy Elements 'on the fly'. That is, you can create all Policy Elements from within the New Access Rule Wizard. This greatly improves on ISA Server 2000, where you have to plan out your Policy Elements in advance and then create Protocol Rules and Publishing Rules after you configure your Policy Elements.

The ISA firewall includes the following Policy Elements:

• 
  

  Protocols



• 
  

  User Sets



• 
  

  Content Types



• 
  

  Schedules



• 
  

  Network Objects

Protocols

The ISA firewall includes a number of built-in protocols that you can use right out of the box to create Access Rules, Web Publishing Rules and Server Publishing Rules.

In addition to the built-in protocols, you can create your own protocols by using the ISA firewall's New Protocol Wizard. The pre-built protocols cannot be modified or deleted. However, you can edit or delete protocols you create yourself. There are some protocols that are installed with application filters that cannot be modified, but they can be deleted. You do have the option to unbind application filters from protocols. For example, if you don't want Web requests for SecureNAT and Firewall clients to be forwarded to the Web Proxy filter, you can unbind the Web Proxy filter from the HTTP protocol. We'll examine this issue in more detail later in this chapter.

When you create a new Protocol Definition, you'll need to specify the following information:

• 
  

  Protocol Type. TCP, UDP, ICMP, or IP-level protocol. If you specify an ICMP protocol, then you'll need to include the ICMP type and code. Note that you cannot publish IP-level or ICMP protocols.



• 
  

  Direction. For UDP, this includes Send, Receive, Send Receive, or Receive Send. For TCP, this includes Inbound and Outbound. For ICMP and IP-level, this includes Send and Receive.



• 
  

  Port range. (for TCP and UDP protocols) This is a range of ports between 1 and 65535 that is used for the initial connection. IP-level and ICMP protocols do not use ports, as ports are part of the transport layer header.



• 
  

  Protocol number. (for IP-level protocols). This is the protocol number. For example, GRE uses IP protocol number 47.



• 
  

  ICMP properties. (for ICMP protocol). This is the ICMP code and type.



• 
  

  (Optional) Secondary connections. This is the range of ports, protocol types, and direction used for additional connections or packets that follow the initial connection. You can configure one or more secondary connections. Secondary connections can be inbound, outbound or both inbound and outbound.

  
  

  
  
  
  
  

  Note

  You cannot define secondary connections for IP-level primary protocols.

  
  

User Sets

In order to enable outbound access control, you can create Access Rules and apply them to specific Internet Protocol (IP) addresses or to specific users or groups of users. When Access Rules are applied to a user or group, the users will have to authenticate using the appropriate authentication protocol. The Firewall client always uses integrated authentication and always sends the user credentials transparently. The Web Proxy client can use a number of different authentication methods.

The ISA firewall allows you to group users and user groups together in User Sets or what we like to call 'firewall groups'. User sets include one or more users or groups from any authentication scheme supported by the ISA firewall. For example, a user set might include a Windows user, a user from a RADIUS namespace, and another user from the SecurID namespace. The Windows, RADIUS and SecurID namespaces all use different authentication schemes, but users from each of these can be included in a single User Set.

The ISA firewall comes preconfigured with the following user sets:

• 
  

  All Authenticated Users. This predefined user set represents all authenticated users, regardless of the method used to authenticate. An Access Rule using this set applies to authenticated users. When a rule applies to authenticated users, connections from SecureNAT clients will fail. An exception to this is when the SecureNAT client is also a VPN client. When a user creates a VPN connection to the ISA firewall, the VPN client automatically becomes a SecureNAT client. Although normally a SecureNAT client cannot send user credentials to the ISA firewall, when the SecureNAT client is also a VPN client, the VPN log on credentials can be used to authenticate the user.



• 
  

  All Users. This predefined User Set represents all users. A rule defined using this set will apply to all users, both authenticated and unauthenticated, and no credentials are required to access a rule configured to use this User Set. However, the Firewall client will always send credentials to the ISA firewall, even when authentication is not required. You'll see this in effect in the Microsoft Internet Security and Acceleration Server 2004 management console, in the Sessions tab when a user name has a question mark next to it.



• 
  

  System and Network Service. This pre-built User Set represents the Local System service and the Network service on the ISA firewall machine itself. This User Set is used in some System Policy Rules.

Content Types

Content types specify Multipurpose Internet Mail Extensions (MIME) types and file extensions. When you create an access rule that applies to the HTTP protocol, you can limit what Content Types the Access Rule applies to. Content Type control allows you to be very granular when configuring Access Policy because you can control access not only on a protocol and destination basis, but also by specific content.

Content Type control only works with HTTP and tunneled FTP traffic. Content Type control will not work with FTP traffic that isn't handled by the ISA firewall's Web Proxy filter.

When an FTP request is made by a host on an ISA firewall Protected Network, the ISA firewall will check the file extension in the request. The ISA firewall then determines if the rule applies to a Content Type that includes the requested file extension and processes the rule accordingly. If the Content Type doesn't match, then the rule is ignored and the next rule in the Access Policy is checked.

When a host on an ISA firewall Protected Network makes an outbound HTTP request, the ISA firewall sends the request to the Web server via the Web Proxy filter (by default). When the Web server returns the requested Web object, the ISA firewall checks the object's MIME type (which is found in the HTTP header information) or its file extension (depending on the header information returned by the Web server.) The ISA firewall determines if the rule applies to the specified Content Type including the requested file extension, and processes the rule accordingly.

The ISA firewall comes with a pre-built list of Content Types that you can use right out of the box. You can also create your own Content Types. When you create your own Content Types, you should specify both MIME type and file extension.

For example, to include all Director files in a content type, select the following file name extensions and MIME types:

• 
  

  .dir



• 
  

  .dxr



• 
  

  .dcr



• 
  

  application/x-director

You can use an asterisk (*) as a wildcard character when configuring a MIME type. For example, to include all application types, enter application/*.

The ISA firewall comes with the following pre-built Content Types:

• 
  

  Application



• 
  

  Application data files
  



• 
  

  Audio,



• 
  

  Compressed files



• 
  

  Documents



• 
  

  HTML documents



• 
  

  Images



• 
  

  Macro documents



• 
  

  Text



• 
  

  Video



• 
  

  VRML.

Controlling access via MIME type can be challenging because different MIME types are associated with different file name extensions. The reason for this is that the Web server controls the MIME type associated with the Web object returned to the user. While there is general agreement on how MIME types are defined, a Web site administrator has complete control over the MIME type associated with any content hosted by his Web server. Because of this, you will sometimes see that content that you had thought you had blocked using Content Types is not blocked. You can determine the MIME type used by the Web server returning the response by doing a Network Monitor trace. The HTTP header will show the MIME type returned by the Web server for the Web content requested by the requesting client.

The following table lists the Internet Information Services (IIS) default associations. You can use these for general reference.

Schedules

You can apply a Schedule to an Access Rule to control when the rule should be applied. There are three built-in schedules:

• 
  

  Work Hours Permits access between 09:00 (9:00 A.M.) and 17:00 (5:00 P.M.) on Monday through Friday (to this rule)



• 
  

  Weekends Permits access at all times on Saturday and Sunday (to this rule)
  



• 
  

  Always Permits access at all times (to this rule)

Note that rules can be allow or deny rules. The Schedules apply to all Access Rules, not just allow rules.

Network Objects

Network Objects are used to control the source and destination of connections moving through the ISA firewall. We discussed the Network Objects Policy Elements in Chapter 4.