Este conteúdo não está disponível em seu idioma, mas aqui está a versão em inglês.
Esta documentação foi arquivada e não está sendo atualizada.
Improve Your Web Security With Encryption And Firewall Technologies
At a Glance:
- How ISA Server secures Web traffic
- How ISA Server inspects packets
- How authentication works in ISA Server
- Step-by-step instructions for using certificates
If you're like most IT professionals, your work life is an ongoing balancing act in which you aim to adopt the latest technological innovations while keeping your enterprise secure. So you welcome any software that makes the whole
process easier. Fortunately, security features in IIS, ISA Server, and secure sockets layer (SSL) can all be applied to your Web transactions to improve your Web security. In this article, I'll show you how to take advantages of these technologies painlessly.
Define Your Needs
Whether you're a home user or architecting a solution for a large enterprise, the first step towards security nirvana is a survey of your landscape. You need to take a look at what information assets you have that must be protected, how information flows into and out of your infrastructure, and how customers can be sure that they are really dealing with your actual Web site and not that of an impostor. In addition, you must find a way to make sure that the customers' Personally Identifiable Information (PII) remains confidential as mandated by legal regulations such as Sarbanes-Oxley (SOX) and European Privacy legislation. But all legalities aside, the fact is that poor security practices put your company's reputation at risk. Let's take a look at some strategies you can employ to beef up your security.
The SSL Solution
The majority of transactional Web sites implement server-side SSL, whereby the server authenticates itself to the browser (client), although SSL can also authenticate the client if a prior relationship has been established.
To employ SSL Authentication, each entity to be authenticated must obtain a certificate (and associated private key) whose issuer is trusted by the system. You can get IIS ready to use certificates by following the steps outlined in the "Enabling Certificates in IIS" sidebar. After you have completed that process, you need to obtain your certificate from a trusted certificate authority (CA) such as VeriSign, Valicert, or others.
Once you have the certificate, you must activate it in the IIS Manager console by going into the Website Properties and selecting the Directory Security tab. Select Server Certificate, click the Next button, and in the resulting dialog click Next again. The default action will be to process the pending request and install the certificate. Enter the name of the file you received from the CA and click Next to complete the wizard.
Be aware, though, that it can be dangerous to allow even inbound SSL traffic to pass directly to your Web servers. Attackers are now starting to use SSL to encrypt their attack traffic, and uninspected SSL traffic can present a threat. How, then, do you inspect this traffic while simultaneously maintaining wire privacy? Through the use of an application-layer firewall.
ISA Server Basics
HTTPS (the "S" indicates secure through the use of SSL) provides the means to authenticate the Web server to the client and encrypt the traffic in transit. Unfortunately, HTTPS is not a silver bullet, so an application layer firewall such as Microsoft® Internet Security and Acceleration Server (ISA) 2004 should be considered to address the remaining requirements. ISA provides a wide range of firewall, Virtual Private Networking (VPN), and cache capabilities. ISA can be purchased in the form of software to be installed on Windows Server™ 2003 (and Windows® 2000 Server) or in the form of a dedicated hardware appliance. Full details of ISA Server are located at ISA Server.
The following actions taken by ISA provide the means to secure the Web server above and beyond HTTPS. ISA inspects the content to ensure it is RFC-compliant HTTP as opposed to malicious traffic. Contrast the behavior of ISA to most firewalls which simply operate on the premise that incoming traffic bound for port 80 (in the case of HTTP) and port 443 (for HTTPS) must be valid.
ISA decrypts incoming SSL traffic, inspects the content, and in the recommended configuration, reestablishes an encrypted communication link (via SSL) between the ISA Server and the actual Web server. The ISA term for this is SSL-bridging.
ISA reverses incoming proxy traffic by accepting incoming page requests and serving the pages on behalf of the internal Web server. Incidentally, ISA can also act as a forward proxy, sending page requests from internal machines to those on the external network. In both proxy scenarios ISA can improve network performance by caching popular content and then serving it from a local store.
ISA also authenticates incoming traffic and forwards the credentials together with the traffic to the Web server, which ensures that only valid users are able to communicate with the Web server. The ISA term for this is preauthentication and the result is a single authentication for the user.
Finally, ISA also performs Fully Qualified Domain Name (FQDN) validation. Incoming requests are assessed to make sure that requests for specific IP addresses are rejected. Many Internet worms are blocked by this feature as such automated tools tend to use ranges of IP addresses as opposed to resolved domain names.
An additional feature of ISA is known as Link Translation. ISA translates the addresses used in page requests to alternatives based on a find-and-replace approach. Link Translation is handy in many situations, including those in which you have an existing Web site that you want to upgrade to use HTTPS. When URLs are hardcoded in a third-party application, you can use Link Translation to translate HTTP requests to HTTPS requests.
Application Layer Firewalling
Traditional firewalls inspect packet headers and ignore the payload (data) contained within each packet. An application layer firewall inspects the entire packet and thus is able to detect attacks contained deep within the packet. This is absolutely necessary these days, as the majority of modern attacks occur at the application layer.
The text in Figure 1 was taken from a network trace via Microsoft Network Monitor, which is an optional component of Windows Server 2003. Note that I show only a portion of the trace in Figure 1. I have used RFC1918 (private) addresses as the example was taken from a test system.
ETHERNET ETHERNET: Destination address = 0003FF4249BC ETHERNET: Source address = 0003FF7C49BC ETHERNET: Ethernet Type : 0x0800 (Internet IP (IPv4)) IP IP:Protocol = TCP IP:Checksum = 44571 (0xAE1B) IP:Source Address = 172.16.101.101 IP:Destination Address = 172.16.101.10 TCP TCP: Source Port = 0x05DB TCP: Destination Port = World Wide Web HTTP TCP: Checksum = 0x167B HTTP: GET Request from client HTTP: Request Method = GET HTTP: Uniform Resource Identifier =/ HTTP: Protocol Version =HTTP/1.1 HTTP: Host=172.16.101.10
The packet in question was produced by a Web browser issuing an HTTP Get Request when connecting to the Web server via HTTPS. The packet flow resulting from the equivalent HTTPS connection request would be more complex due to the server authentication and data encryption.
Figure 1 shows the layered nature of the packet. In particular it is worth noting that the items are listed in the opposite order to the Open System Interconnection (OSI) stack and therefore the application layer is presented last. The Ethernet component refers to hardware-specific media access control (MAC) addresses. The IP layer refers to IP addresses. The TCP layer deals with ports—the tool has port 80 set to be World Wide Web HTTP. All of the information can be spoofed by the sender (even when HTTPS is being used)—the checksum entries in the IP layer and TCP layer do not mitigate this threat as the entries are not cryptographically signed. The HTTP component is the application layer. Another way of looking at the illustration is that HTTP is being carried over TCP, which itself is being carried over IP (hence TCP/IP) which is using Ethernet.
The Web Publishing feature of ISA allows ISA to respond to Web requests on behalf of the Web server. ISA inspects the traffic to ensure that it contains only valid HTTP methods (such as GET) and appropriate syntax. Valid requests are forwarded to the internal Web server that is located behind the ISA Server computer.
ISA provides the facility to block specific methods as defined by the administrator. Say, for example, that your Web server contains purely read-only pages—you could configure ISA to block the "POST" method and hence protect against malicious changes to the configuration of the Web server or source HTML.
Decrypting Incoming HTTPS Traffic
So how does ISA decrypt incoming HTTPS traffic? ISA is placed between the external (untrusted) network and the Web server. To keep the description simple I have assumed one ISA Server and one IIS Web server. Production environments typically operate additional servers to provide fault tolerance and increased performance.
The ability to inspect incoming SSL traffic is one of the most important security features of ISA Server. The incoming HTTP traffic is encrypted via SSL, so you must configure ISA to be the SSL termination point. This is achieved by exporting the server certificate and associated private key from the Web server and importing it onto the ISA Server computer. Once the certificate (and private key) is available to ISA, you can configure the Web publishing rule to use it to impersonate the Web server and hence decrypt the content.
Let's recap where we are. The client browser has established an SSL connection to ISA Server in the belief that it is actually the Web server. ISA will inspect the traffic and, assuming it is valid, will communicate with the Web server on behalf of the client. Some people would argue that this approach invalidates the protection of SSL as the client is not aware that the traffic is being inspected. In order to safeguard the security of the traffic I recommend configuring ISA to use an SSL connection between itself and the target Web server (using SSL-bridging) as well.
As you may have guessed, the Web server will require a server certificate and an associated private key so that ISA can establish an SSL connection to it. The least complicated way to accomplish this is to use the same certificate (and private key) on both ISA and the Web server though you should make sure that this does not breach the terms of the issuing certification authority. An alternative approach would be to either request an additional server certificate from a third-party CA or request one from your own CA if you have one. The certificate only has to be trusted by the ISA Server so you may consider installing a CA purely to issue the Web server certificate and therefore avoid the cost of having to purchase an additional third-party certificate.
Native Web server authentication can be dangerous as all users are able to perform an initial unauthenticated connection for the purpose of providing their credentials. The initial connection can provide the opportunity for a malicious user to attack the Web server itself.
Preauthentication (also known as delegated authentication) is, as I mentioned earlier, the mechanism by which ISA authenticates the user on behalf of the Web server. In this scheme, the user is only prompted to authenticate once. And because only authenticated users are able to communicate with the Web server, anonymous hacking attacks (including denial of service) do not reach the Web server.
ISA supports delegation for both Basic authentication and forms-based authentication. With both forms of authentication, you should use SSL to encrypt the traffic because by default data will be transmitted in clear text.
Microsoft Windows Server 2003 (and Windows 2000 Server) includes the optional installation of a RADIUS server, also referred to as the Internet Authentication Server (IAS). The use of RADIUS allows for integrated authentication with an existing directory structure, such as Active Directory®. Microsoft IAS complies with the RADIUS standard protocol definition described in RFC 2865.
The delegated Basic Authentication process takes place as follows:
- The client browser issues an HTTP Get request for the required URL
- The ISA Server computer receives the request
- ISA responds with a 401 error (indicating unauthorized access)
- The browser resends the request together with the credentials of the user.
ISA validates the credentials either by sending an access-request to a RADIUS server or by attempting a WinLogon to Active Directory. The benefit of using RADIUS is that the ISA Server does not need to be a member of the domain and therefore there is greater separation between internal and perimeter servers. If RADIUS is used then the RADIUS server authenticates the credentials against Active Directory. If the credentials are valid then the RADIUS server sends an access-accept message along with a RADIUS attribute containing the security groups of the user, back to the ISA Server.
If the authentication request fails then the ISA Server will decline the access request. If the credentials are valid then both the HTTP Get request and user credentials will be forwarded to the Web server. The Web server will use the credentials to perform a WinLogon as it is not aware that ISA has already authenticated the user.
As you can see, the combination of IIS, SSL, and ISA Server offer several options for helping to secure your Web site and keep prying eyes away from your customers' personal data. By following these and other security best practices, you will help to ensure that your customers feel safe using your Web applications and help protect your most important assets—your company's reputation and bottom line.
Enabling Certificates in IIS
- To get IIS ready for a certificate, log into the Web Server computer with Administrative privelages.
- Run the IIS Manager from Start | All Programs | Administrative Tools | IIS Manager.
- Select the Web site (<server hostname>, Web Sites, default Web site).
- Click the right mouse button, then choose Properties from the menu. You'll get the dialog shown in Figure A.
- In the Properties dialog, select the Directory Security tab, then select the Server Certificate button on the resulting dialog (see Figure B).
- The Web server certificate wizard shown in Figure C will guide you through the process of administering the certificate.
- Click on the Next button and the Server Certificate panel will be displayed.
- If you don't already have a Web Server certificate, then the Create a new certificate option will be selected by default.
- Click on the Next button and the Delayed or Immediate Request panel will be displayed, as you can see in Figure D.
- If you have your own CA, select Send the request immediately to an online certification authority, otherwise select the Prepare the request now, but send it later option (See Figure D).
- Click the Next button and the Name and Security Settings panel will be displayed.
- Enter a descriptive name for the Web site, as Figure E illustrates.
- Click on the Next button—the Organization Information panel will be displayed.
- Enter the appropriate Organization and Organizational unit details (see Figure F).
- Click the Next button and the Your Site's Common Name panel will be displayed, as shown in Figure G.
- Enter the fully qualified name of your server. It's important to enter the correct details for this field otherwise the browser user will receive an error stating that the certificate doesn't match the URL of the Web site.
- Click the Next button and the Geographical Information panel will be displayed. Enter the appropriate Country, State and City details, as I did in Figure H.
- Enter the appropriate Country, State, and City details, as I did in Figure H.
- Click the Next button, then enter a file name in the Certificate Request File Name panel.
- Click Next and the Request File Summary button will be displayed.
- Now, click Next again—the Completing the Web Server Certificate Wizard panel will be displayed.
- Click Finish.