Attacks against Web servers are the most common form of attack against corporate resources. Web sites exposed to Internet users must be secured to the greatest extent possible in order to successfully fend off repeated attacks from Internet intruders.
The first step in protecting publicly available Web servers is to harden the underlying operating system and the Web server components as much as possible, while leaving the Web applications’ functionality intact. The next step is to place an application-layer-aware firewall in front of the Web server. Such a firewall inspects incoming and outgoing Web communications moving through the firewall, assesses their safety and validity, and then allows or denies communications based on this assessment.
While security is a primary concern when allowing Internet users access to corporate Web resources, security without accessibility is of marginal value. A firewall must be able to provide a high level of security while at the same time giving the firewall administrator a high level of control over how Internet users access corporate Web resources.
Microsoft® Internet Security and Acceleration (ISA) Server 2004 is an application-layer-aware firewall that can inspect communications moving through the firewall and make intelligent allow-or-deny decisions based on an analysis of their safety and validity. The intelligent application-layer filtering mechanisms in ISA Server 2004 not only provide a high level of security for corporate Web servers, but also give the firewall administrator a high level of control over how these resources are accessed through the firewall.
This white paper will discuss the ISA Server 2004 technologies that provide secure access to Internet Information Server (IIS) Web servers located behind the firewall. These technologies include:
· Advanced HTTP filtering
· Delegation of basic authentication
· Authentication based on Microsoft Outlook® Web Access (OWA) forms
· Remote Access Dial-In User Service (RADIUS) authentication for incoming Web site connections
· SecurID authentication for incoming Web site connections
· SSL-to-SSL bridging
· Flexible Web site redirection
· Secure Web server publishing wizard
· Protection of internal server names with link translation
· Use of custom firewall groups to control Web site access
Advanced HTTP Filtering
The HTTP protocol, used to access Web servers on the corporate network, is the most commonly used protocol on the Internet. ISA Server 2004 includes an advanced HTTP application filter that inspects all connections made by Internet users to Web sites on the corporate network and enables you to control virtually any aspect of an HTTP communication moving through the ISA Server 2004 firewall.
For example, hackers commonly take control of Web servers by accessing Microsoft Windows® executable files, which they use to run programs on the Web server. An attacker can control virtually any aspect of a Web server if he can successfully run executable applications on the server. You can configure the ISA Server 2004 firewall to block all attempts to access and run a Windows executable file on the Web server. Such a step prevents attackers from using programs such as cmd.exe to run commands on the Web server through command-line input.
Another way you can protect the Web server is to limit the HTTP methods that can be used to control interactions between the Web client and the Web server. For example, the POST and PUT methods are used to write data to locations on the Web server. You can use the advanced HTTP filtering built into ISA Server 2004 to block incoming requests that include the POST and PUT methods.
The advanced HTTP filter in ISA Server 2004 also enables you to create custom signatures that can be used to block access to the Web server. For example, you may run a Web discussion board on an IIS Web server. By creating signature entries that include a standard list of words that you do not wish to appear on the Web boards and applying this list to the filter, you can ensure that only appropriate language is used on the Web boards and that comments containing offense language are not posted.
These are just a few examples of how you can protect your Web sites using the advanced HTTP application-layer filtering in ISA Server 2004. With this filtering, you can stop virtually all known attacks—and many unknown ones—at the perimeter, before they reach your corporate Web server.
Delegation of Basic Authentication
Many secure Web sites require Internet users to authenticate themselves by sending credentials in the form of user name and password before they can access Web site resources. Since not all IIS-hosted Web content is meant for all users, user authentication enables the firewall administrator to control who is able to access specific content on the Web server.
While authentication provides access control over Web-based content, it also opens up the Web server to all users, even those who do not successfully authenticate themselves. The reason is that when an Internet user requests information from the Web server, the user connects to the Web server itself. Even though the Web server will not return the requested content to a user who does not possess the proper credentials, an attacker can take advantage of the initial unauthenticated connection to break into the Web server and potentially compromise, deface, or change Web pages and content. An attacker could even take over the Web server and use it to launch an attack against other machines on the corporate network.
ISA Server 2004 helps protect your corporate Web site from attacks by authenticating users at the firewall. Only those users who successfully authenticate themselves will be allowed to connect to the Web server. When users do not successfully authenticate themselves, ISA Server 2004 simply drops the connection. In this way, ISA Server 2004 blocks hackers and other inappropriate user connections at the firewall.
Delegation of basic authentication is a powerful mechanism that you can use to protect all Web sites located behind the ISA Server 2004 firewall. You can also use delegation of basic authentication on a per-Web-site basis to control which Web sites this feature protects.
Outlook Web Access Forms-based Authentication Outlook Web Access (OWA) sites are special Web sites that enable users to access Microsoft Exchange Server e-mail from remote locations using the HTTP protocol. In addition to the protection that ISA Server 2004 provides to all Internet Information Server Web sites, its forms-based authentication capabilities offer special protection to OWA Web sites.
To understand how forms-based authentication works, we will first look at what happens without such authentication when an Internet user connects to an OWA Web site. In response to the user’s request for Web site content, the OWA Web site generates a logon form and sends it to the user. The user enters a user name and password and sends that information back to the OWA Web server. The Web server authenticates the user and, if the user has permission to access information on the OWA Web site, allows the connection and transfers the requested information to the user.
The problem with this scenario is that attackers can take advantage of the initial, unauthenticated connection to attack the OWA Web site. ISA Server 2004 solves this problem by generating the logon form itself, thereby preventing unauthenticated users from making any connection to the OWA Web site.
When a user connects to OWA through ISA Server 2004, the ISA Server 2004 firewall accepts the connection request from the Internet user, generates the OWA logon form, and sends it to the Internet user. The user enters a user name and password and sends that information to the ISA Server 2004 firewall. To authenticate the user, the firewall then sends the credentials to a domain controller or RADIUS server. If the authentication is successful and the user has permission to access the OWA Web site, the firewall allows the connection, and the user can then access mailbox information on the OWA Web site.
The forms-based authentication in ISA Server 2004 provides another advantage to organizations using Microsoft Exchange Server: it provides forms-based authentication for all versions of Exchange Server. Without ISA Server 2004, only Microsoft Exchange Server 2003 supports forms-based authentication. With ISA Server 2004, you can provide forms-based authentication protection for Microsoft Exchange Server 5.5 and Microsoft Exchange Server 2000 as well.
RADIUS Authentication of Incoming Web Site Connections
Support for RADIUS (Remote Access Dial-In User Service) authentication enables the ISA Server 2004 firewall machine to authenticate users that are not included in the local user database. You can use RADIUS to authenticate users belonging to Active Directory® domains, Windows NT 4.0 domains, or other user directories before allowing them to connect to your corporate Web site.
For example, suppose your corporate network has an Active Directory domain with 6,500 users, and you want to use its database to authenticate employees who need to access corporate information from remote locations. One approach is to join the ISA Server 2004 firewall to the same domain to which the users belong. The problem with this configuration, however, is that if an attacker were able to compromise the firewall, the attacker could potentially leverage the firewall’s domain member status to magnify the effectiveness of an attack against corporate network servers. That is why it is generally considered a higher security option to not join the ISA Server 2004 firewall to the internal network domain.
A better solution is to configure the ISA Server 2004 firewall to use RADIUS authentication for incoming Web requests. With this approach, the firewall forwards the request to a RADIUS server located behind the firewall. The RADIUS server then forwards the authentication request to a machine that has the information required to authenticate the user. This machine could be an Active Directory domain controller, another RADIUS server, or a directory server created by a third party that accepts RADIUS authentication messages.
Another good approach is to use the Internet Authentication Server (IAS) built into Microsoft Windows 2000 and Microsoft Windows ServerÔ 2003. The ISA Server 2004 firewall can forward authentication requests from Internet users to an IAS server on the corporate network, and the IAS Server can then forward the request to an Active Directory domain controller. The Active Directory domain controller authenticates the user and sends the successful authentication result to the RADIUS server, which in turn sends the successful authentication result to the ISA Server 2004 firewall.
SecurID Authentication of Incoming Web Site Connections
RSA SecurID authentication is a two-factor user-authentication solution. Before allowing users to access Web sites on the corporate network, it requires not only that they have a secret Personal Identification Number (PIN), but also that they present a token (or authenticator). This approach is more secure than a user name/password combination because the user must both know something (the PIN) and have something (the token) to access corporate Web resources.
Each token has a unique symmetric key that is combined with an encryption algorithm to generate a new code every minute. Only the RSA ACE/Server software knows which code is valid at any moment for a particular user/token combination. Users combine the code with their PIN to log into protected resources.
SecurID tokens are available in several forms. Hardware tokens are available in key fob, card, and PINPad formats. Software tokens are available for Windows workstations, Pocket PCs, Palm and Blackberry handheld devices, and DoCoMo wireless phones.
ISA Server 2004 firewalls support SecurID authentication through the use of a SecurID application filter. The application filter receives incoming SecurID authentication requests and forwards them to the ACE server on the corporate network. The ACE server authenticates the user and sends the results to the ISA Server 2004 firewall. If authentication is successful, the firewall allows the user to access the corporate Web site.
For example, suppose your organization would like to provide traveling executives with remote access to sales summaries and competitive data through a secure Web connection. This data is highly proprietary and cannot be released to the general population. You could use single-factor authentication to provide executives with this access, but because of the highly private nature of this information, you would prefer a higher level of security. If you implement a SecurID solution and supply the executives with SecurID keyfob tokens, only users with the appropriate PINs and hardware tokens can access the secure Web site.
SSL-to-SSL Bridging
SSL-to-SSL bridging is another ISA Server 2004 feature that provides a high level of remote access security for corporate Web sites—in this case, by preventing hackers from hiding attacks within SSL tunnels. A typical network firewall cannot perform deep application-layer inspection of SSL-protected communications because those communications are hidden inside an SSL tunnel. The ISA Server 2004 firewall, however, can decrypt SSL-protected communications, analyze them to determine their safety, re-encrypt those that are safe, and pass them on through the tunnel to their destination.
To better understand why the SSL-to-SSL bridging capability in ISA Server 2004 provides a superior level of Web site protection, let us first examine what happens when a user attempts to access a secure SSL Web site through a conventional, non-ISA Server 2004 firewall. In such a case, the Internet user sends an SSL request to the Web site. The conventional firewall sees that this is an SSL connection and passes the request to the Web site. The Internet user’s browser and the Web site then negotiate a series of parameters that define the SSL connection, and the SSL connection encrypts the information moving between the Internet user’s browser and Web site. Because the information being passed back and forth is hidden inside the encrypted SSL tunnel, a conventional firewall cannot make an assessment regarding the nature of this information. As the firewall passes messages back and forth, it sees only that they are encrypted. Consequently, any security applied to this connection must be implemented at the Web server itself—and this security can be applied only after the Web server decrypts the packets and examines the unencrypted information. If the information is in fact dangerous, this point may be too late to apply security: the damage may have already occurred.
Savvy Internet attackers can leverage this weakness in conventional firewalls by creating SSL-encrypted sessions with Web sites located behind the firewall. The firewall cannot determine if there is attack code contained in the SSL connection between the attacker and the Web site because the attack code is hidden inside the SSL tunnel.
In contrast, ISA Server 2004 firewalls are able to access and evaluate communications moving through the SSL tunnel by decrypting these communications and exposing them to sophisticated and powerful HTTP application filters. When an Internet user attempts to connect to a Web site located behind the ISA Server 2004 firewall, the initial connection is made to the external interface of the firewall. The Internet user’s browser and the external interface of the ISA Server 2004 firewall then negotiate a secure SSL session, the ISA Server 2004 firewall decrypts the SSL-encrypted data, and its HTTP application filters examine the data. If the filters identify suspicious or dangerous commands or data, the ISA Server 2004 firewall drops the connection. If the firewall determines that the connection is safe, then it re-encrypts the data and establishes a second SSL connection, this time between its internal interface and the Web server on the corporate network. It then forwards the connection request to the Web server on the internal network.
The same process takes place when the Web server returns its responses to the Internet user. The responses move through the SSL tunnel between the Web server and the internal interface of the ISA Server 2004 firewall. The ISA Server 2004 firewall decrypts the packets and examines them. If the firewall determines that the responses are not safe or otherwise violate HTTP policy, it drops them. If it determines that the responses are valid and safe, the firewall re-encrypts the responses and forwards them through the SSL tunnel between its external interface and the Internet user. In this way, the SSL-to-SSL bridging capabilities in ISA Server 2004 prevent attackers from hiding attacks inside an SSL tunnel.
Flexible Web Site Redirection
Firewall administrators often need to provide Internet users with access to multiple Web servers on the corporate network. Because Web sites may contain links that use the same fully qualified domain name as the one used by the remote user, but a different path, the firewall needs both the names and the paths included in user requests in order to forward them.
For example, suppose your organization has two Web servers on the corporate network— SERVER1 and SERVER2—and uses a single, domain name to give Internet users access to all corporate Web resources. You want to use a different path for each server but keep the same domain name for both.
ISA Server 2004 firewalls can provide access to multiple Web servers by using path statements to redirect incoming requests to the appropriate server. For example, you can set up the path statements so that when users request http://www.domain.com/sales, the firewall redirects them to SERVER1, and when they request http://www.domain.com/catalog, the firewall redirects them to SERVER2. This redirection is completely transparent to the user: the ISA Server 2004 firewall handles the redirection automatically by examining the HTTP header information and making routing decisions based on this inspection.
ISA Server 2004 firewalls also make it easy to provide remote access to existing Web sites that have a complex folder hierarchy in place. For example, suppose the Web site on the corporate network has the folders /payroll and /hr on it. The Web site operator does not want you to expose the actual names of these folders to Internet users, but does want you to provide secure authenticated access to them. You can do so with ISA Server 2004 by taking advantage of its ability to perform Web site redirection. That is, you can configure the Web publishing rules in ISA Server 2004 to forward requests for http://www.domain.com/information to http://SERVER1/payroll and forward requests for http://www.domain.com/employees to http://SERVER2/hr.
As in the earlier example, the ISA Server 2004 firewall performs this redirection transparently. Internet users see only that they are connecting to the Web sites and paths they entered into the browsers (or the those shown on links they clicked). The ISA Server 2004 firewall tracks the requests and forwards them to the appropriate Web server. It also automatically enters all redirection information into the Web proxy and firewall logs, so you can analyze access patterns at your convenience at a later time—or, if you prefer, view them in real time using the ISA Server 2004 real-time log analyzer.
Secure Web Server Publishing Wizards
Publishing Web sites, especially secure Web sites, can be difficult. The publishing has to be done correctly because an error can lead to a significant security beach, with possible loss of data and compromise of the Web server. ISA Server 2004 simplifies publishing secure Web sites through its powerful and effective Web publishing wizards.
ISA Server 2004 uses Web publishing to enable Internet users to access Web resources on the corporate network. When the ISA Server 2004 firewall receives a request for a Web server on the corporate network, it redirects the request to the Web server. You can also configure the firewall to authenticate the user before forwarding the connection to the Web server. In addition, ISA Server 2004 can perform application-layer inspection of the connection and confirm that it is safe and does not contain evidence of an attack pattern before forwarding the request.
ISA Server 2004 includes three Web publishing wizards you can use to publish corporate Web sites:
· Publish a Web Server
· Publish a Secure Web Server
· Publish a Mail Server
The Publish a Web Server wizard enables you to publish corporate Web servers that do not require SSL connections. You can still secure the published Web server by requiring users to authenticate themselves with the ISA Server 2004 firewall before allowing them to access the Web server.
The Publish a Secure Web Server wizard simplifies the task of publishing an SSL Web server. SSL encrypts data moving between the Internet Explorer Web client on the Internet and the secure Web site on the corporate network. You can publish the secure Web site using SSL tunneling, in which case the ISA Server 2004 firewall will emulate the behavior of a conventional firewall; or you can publish it using the unique and highly secure SSL-to-SSL bridging feature in ISA Server 2004 (see earlier section on SSL-to-SSL bridging for more information).
The Publish a Mail Server wizard enables you to publish secure Outlook Web Access sites. The wizard walks you through the process of setting up secure, SSL encrypted connections to the OWA site resources and also takes you through the steps required to use the forms-based authentication feature in ISA Server 2004.
All of these wizards not only take the guesswork out of publishing secure Web sites located on the corporate network, but also prevent configuration errors that could lead to undesirable and unintended results.
Protection of Internal Server Names with Link Translation
Many Web applications embed private network server names in the links they return to Internet users. For example, suppose your company has a Web application that is used extensively by users on the corporate network. Because this Web application was designed for intranet use only, it returns private network server names to clients requesting information from the Web server. You now wish to make this application available to customers and partners in remote locations. The problem is that users in remote locations cannot access your private network servers by machine name; therefore, they will be unable to access the information they need from these servers. For example, Microsoft SharePoint® Portal Server might respond to a user’s request for content located on SERVER1 by returning a link to http://server1/. Since SERVER1 is a private server, a remote user will not be able to access it by clicking this link.
ISA Server 2004 firewalls solve this problem using the built-in link translator feature. This feature enables you to create a dictionary that translates private server names in Web server responses to public names that remote users can access.
For example, you can configure the ISA Server 2004 link translator to translate SERVER1 to http://www.domain.com/. When the Web server responds to a user request for information by providing a hard-coded link to http://server1/, the ISA Server 2004 firewall will intercept the response and change SERVER1 to http://www.domain.com/. That way, the link the Internet user sees will be to http://www.domain.com/ instead of to http://server1/. Users on the corporate network, however, will still receive pages with links to http://server1/ because they are inside the firewall and therefore do not go through the firewall to access the Web server.
Another advantage of link translation is that it prevents attackers from learning the names of servers on the private network. If an Internet-based attacker learns that the Web server on the private network has the computer name SERVER1, the attacker can use that information to launch an attack against that server in the future—perhaps from another machine on the private network that has been compromised by other means. The link translator prevents attackers from learning the actual names of the servers on the private network because the actual server name is always translated to a publicly accessible name by the link translator’s dictionary.
The ISA Server 2004 link translator provides an additional level of flexibility by enabling you to configure the link translation dictionary on a per-Web-publishing-rule basis. As a result, you are not locked into using a single global link translation dictionary for all Web sites published by the ISA Server 2004 firewall. Instead, you can create separate dictionaries for each Web publishing rule.
Use of Custom Firewall Groups to Control Web Site Access
ISA Server 2004 can use the Active Directory user accounts database to control access to corporate Web sites published by the ISA Server 2004 firewall. You can configure access policy based on group membership, so that only members of specific groups can access the resources of a specific Web server.
Configuring access based on group membership has been difficult in the past because, typically, only domain administrators can set up the custom groups within Active Directory. Firewall administrators generally are not members of the domain administrators’ group, so they could set up custom groups only by working through a member of that group—an approach that not only often led to delays in implementing firewall access policy, but also could potentially cause the wrong members to be placed in a security group.
ISA Server 2004 solves this problem by enabling you to set up custom firewall groups that it can use for access control, rather than having to set up groups within the actual directories that store user and group information. You can use ISA Server 2004 to access existing user databases through Active Directory and also through RADIUS, or SecurID and then use the data in these databases to create custom firewall groups.
For example, suppose your company wishes to publish an Outlook Web Access site on the corporate network and set up two groups of users: one that can access the OWA site both from the corporate network and from remote sites and one that can access the OWA site only from the corporate network. Instead of having to work with a domain administrator to create a special OWA Remote Users group in the Active Directory , your firewall administrator can create an OWA Remote Users group on the firewall and add the user accounts that need remote access to the OWA site to that group. Since the firewall administrator needs only to be able to read the information in the Active Directory to add the users to the firewall group—as opposed to creating new accounts or groups in the Active Directory domain—he can take this action himself, without having to work with a domain administrator. The firewall administrator can then create an OWA Web publishing rule that limits access to the OWA site to members of the OWA Remote Users group. Users who want to access the OWA site from within the corporate network will not be affected by this rule, as they are already inside the firewall.
Conclusion
ISA Server 2004 sets a new level of firewall functionality for Windows Server System with its rich set of enterprise-level firewall, Web publishing, and VPN security capabilities. The ISA Server 2004 firewall can monitor all communications moving through it, including VPN client connections. In addition, administrators can monitor and configure all ISA Server 2004 computers in their organization from a single desktop, using a centralized administrative interface.
The firewall features of ISA Server 2004 are ideal for protecting the Internet and LAN perimeters of an organization’s network, as well as for securing key portions of its private, internal network. ISA Server 2004 inspects all traffic and forwards or rejects it based on a wide range of criteria, including who sent it, where it is going, and what application is sending or receiving it. The acceptance/rejection criteria can even be extended to include specific rules, such as rules relating to schedules and groups.
ISA Server 2004 includes a number of technologies focused on protecting Microsoft Internet Information Server Web sites. These technologies work together to provide a high level of security and accessibility for information hosted on IIS sites, placing ISA Server 2004 in a solid position for protecting IIS Web sites against both known and unknown Internet based attackers.
No comments:
Post a Comment