The key to ISA's HTTP filtering functionality revolves around the web server publishing rule. This type of rule allows an ISA Server to "pretend" to be the SharePoint server itself, while secretly passing the packets back to the server via a separate process. This has the added advantage of securing the traffic by not directly exposing the SharePoint web servers from direct attack and forcing them to overcome the ISA server before they can overcome the SharePoint server. NOTE Unlike with other types of server publishing rules, ISA does not need to be installed as a multi homed (multiple NICs) server to take advantage of web publishing rules. Instead, ISA allows for the creation of web-based publishing rules as a unihomed server, sometimes set up in the DMZ of an existing packet filter firewall. In fact, this setup is a common deployment model for ISA because there is a strong demand for systems to provide this type of secured reverse proxy capabilities. All the HTTP-based filtering and functionality is stored within the web publishing rule options, and it is therefore critical to become intimately aware of its capabilities. Using the Web Server Publishing Wizard to Publish a SharePoint SiteTo secure a SharePoint server through ISA Server 2004, a basic web server publishing rule must be set up and configured. When this rule is created, it can be modified as necessary to provide additional filter capabilities and other options. To create a simple rule, perform the following steps. These instructions apply to a specific scenario, where a SharePoint Portal Server for a company, using simple HTTP, is published through ISA:
NOTE It is important to note that once the server publishing rule is in place, all HTTP requests sent to the website should point to the IP address of the HTTP listener on the ISA server itself. This includes publicly accessible websites, which must register the DNS namespace with an IP address on the external interface of the ISA Server. When created, the rule itself should be viewed, and the administrator should become aware of the different settings and options available for HTTP filtering, as described in the following sections. Exploring the General Tab OptionsBy double-clicking on the web publishing rule that was created, the properties dialog box is invoked, which allows for the configuration of the HTTP filtering settings. The first tab displayed is the General tab, as shown in Figure 16.3. Figure 16.3. Examining the General tab on an ISA web publishing rule.The General tab allows for the rule to be enabled or disabled with the check box, as well as for the name to be changed and a description added, if necessary. Understanding the Action TabUnder the Action tab of the web publishing rule, the rule can be set up to either allow or deny traffic. For web publishing rules, this is always set to Allow because there is no reason to create a web publishing rule just to deny access to a web server. In addition, a check box on this tab allows specific log requests to be generated that match the rule. Exploring the From Tab OptionsThe From tab of a web publishing rule enables an administrator to limit the scope of where the traffic will be allowed to come from. For example, a rule could be limited to only those users on a particular subnet, or only a specified list of servers. By using the Add button, specific limitations for the rule can be applied. In addition to specifying where the traffic can come from, this tab also allows specific exceptions to be made. For example, if an entire subnet was restricted, specific exceptions can be made. Outlining To Tab OptionsThe To tab of a web publishing rule, as shown in Figure 16.4, allows information to be entered about the particular server being published. This includes the FQDN of the server itself, as well as the option to forward the original host header if necessary. Figure 16.4. Examining the To tab options on an ISA web publishing rule.It may be advantageous to forward the original host header (which takes the form of the FQDN) in cases where specific websites are being restricted by host headers or when a web-based application is expecting host header traffic. Another important option is displayed on this tab: the option of deciding whether the web traffic sees the traffic as originating on the original client or on the ISA Server computer itself. The option to make the traffic appear to come from the original client can help with auditing the traffic and making sure that user access is properly documented. Changing to make all requests come from ISA makes the web server think that the traffic originates from ISA instead. This option is typically more inclusive and works in multiple scenarios. CAUTION If the ISA Server is deployed in unihomed NIC mode in the DMZ of a firewall, the only option that will work properly is to have the requests appear to come from the ISA Server console. This is because most firewalls do not allow the ISA Server to mimic the packets from an untrusted network and subsequently block the traffic. Exploring the Traffic Tab and Filtering HTTP PacketsThe Traffic tab looks relatively innocuous but is actually a launching point to the advanced HTTP filtering options. The basic tab itself shows what type of traffic the rule applies to (HTTP or HTTPS) and provides the option to inform users to use HTTPS if it is enforced. When using SSL, it also gives the option to require the stronger 128-bit encryption to the traffic, a recommended move in most cases. Filtering HTTP TrafficFiltering of the HTTP traffic is made accessible by clicking on the Filtering tab and choosing Configure HTTP, which provides the following HTTP filtering options:
Customizing Allowed MethodsIn addition to these options, the filter definitions also allow for specific HTTP methods (such as GET and POST) to be allowed in the particular rule. By restricting specific HTTP methods, a web server can be made even more secure because many of the exploits take advantage of little-used HTTP methods to gain control of a system. To restrict by a specific HTTP method, do the following steps while in the Methods tab:
Customizing ExtensionsThe Extensions tab of the filtering rules setting allows only specific types of message attachments to be displayed, such as .mpg files, .exe files, or any others defined in this rule. It also allows for the reverse, where all attachments except for specific defined ones will be blocked. This is accomplished by choosing the option Block Specified Extensions (Allow All Others). For additional security, the box on this page can be checked to block ambiguous or ill-defined extensions, which can pose a security risk to an ISA Server. Blocking HeadersSpecific HTTP headers can be blocked on the Headers tab of the filtering options. This enables HTTP request headers or response headers to be blocked, which can be useful in denying certain types of HTTP headers, such as User-Agent or Server, which defines the type of HTTP traffic being used. Restricting SignaturesThe signature restriction tab is one of the most important because it is ground zero for filtering of HTTP traffic to scan for specific exploits and viruses, such as the signature that is defined to block the Kazaa file-sharing application, shown in Figure 16.6. Figure 16.6. Blocking Kazaa HTTP traffic by signature.The Signature dialog box is where the majority of the custom filters can be created and applied. Because so many applications and exploits use the HTTP port to tunnel their traffic, it is useful to configure these settings to block malware, scumware, and any other applications not approved by the organization. This enables blocking of signatures from such applications as Instant Messaging, Gnutella, Kazaa, Morpheus, and many more. For a list of signatures that can be blocked, see the following Microsoft URL:
Understanding Listener Tab Configuration OptionsThe Listener tab of the web publishing tool, shown in Figure 16.7, allows for the customization and creation of various web listeners. A listener is an ISA construct that "listens" for requests made to a specific IP port combination. When that traffic hits the listener, it then processes that traffic back into ISA. Listeners are required for web server publishing rules and are what allows the ISA server to act as a web server to the requesting client. Figure 16.7. Viewing the Listener tab settings.The existing listener created during the Publishing Rule Wizard can be directly modified by selecting the rule from the drop-down box and clicking the Properties button. This enables various settings to be applied, such as the following:
NOTE The most important thing to remember about listeners in ISA Server 2004 is that you can only have a single listener on each IP:Port combination. In cases where additional IP addresses are not a problem, this is a relatively small issue. Viewing Public Name OptionsThe Public Name tab on the web server publishing rule, shown in Figure 16.8, enables an administrator to dictate that the traffic to the ISA Server travels with a specific public name. For example, it could be stipulated that access to a SharePoint site such as sharepoint.companyabc.com only occurs to requests made to that website, rather than requests to an internal server such as \\server20. If a user tries to access that site from an IP address, that request would fail because the web publishing rule is only allowing traffic sent to the sharepoint.companyabc.com website, in this case. Figure 16.8. Viewing Public Name options.Understanding Paths Tab OptionsThe Paths tab allows specific external paths to be mapped to different locations on a web server. For example, it may be helpful to send requests sent to http://sharepoint.companyabc.com to http://sharepoint.companyabc.com/ sites/sales automatically. To add a path to accomplish this example, do the following:
Exploring the Bridging TabThe Bridging tab of an ISA web publishing rule, shown in Figure 16.10, gives an administrator the flexibility to send HTTP and/or SSL traffic to different ports on a web server. This concept can help to support environments that have nonstandard ports set up for their web environment. Figure 16.10. Exploring bridging concepts.For example, an organization may have set up multiple SharePoint web servers on an internal SharePoint server that has a single IP address. Rather than assign multiple IP addresses to that server, the administrators chose to set up different ports for each virtual server and each website. So, internally, users would have to point to http://site1.companyabc.com:8020 and http://site2.companyabc.com:8030, and so on. The Bridging option in ISA Server 2004 allows end users to not have to enter strange port combinations to access websites, and instead relies on the Bridging tab of the rule to direct port 80 traffic to the appropriate ports, such as port 8888 or any other defined port. Understanding the Users TabThe Users tab on a web publishing rule is useful only if the full Firewall client is deployed throughout the organization; otherwise, it is always set to All Users. If the Firewall client is installed, however, per-user based access control can be realized, allowing an administrator to monitor and adjust to traffic and security on a per-user basis. Outlining Schedule Tab OptionsThe Schedule tab of a web publishing rule, shown in Figure 16.11, does not require much explanation. Using this tab, an organization can decide exactly at what times the rule will be in effect. Figure 16.11. Viewing the Schedule tab for the web publishing rule.Exploring the Link Translation TabThe Link Translation tab allows for a great deal of flexibility in searching for unique bits of content and replacing those bits of content with something else. Link translation effectively looks through all the web traffic and replaces specific hypertext links with administrator defined ones. This comes in handy with SharePoint, which too often exposes a bug in the code that allows internal SharePoint Portal identities to be exposed to the Internet. For example, if SERVER15 is a SharePoint server, but the SharePoint site is http://portal.companyabc.com, the pages in SharePoint will sometimes appear with links to //server15, which will not be able to be resolved from the Internet. To enable link translation on a SharePoint site, do the following:
In addition to replacing text links with link translation, the Link Translation tab also has the capability to restrict by content type, by clicking on the Content Types button. The following types of content are available for restriction:
|