Publishing content on the Internet is one of the best ways a company can increase its exposure to customers, and having a place on the Web is quickly becoming a business necessity. Many companies spend a lot of cash to buy a strong Web presence. A company needs to obtain space, decide on a name, and write content. Unfortunately, some companies stop there, and the content becomes static—sitting in a file on a server, abandoned within the outdated content wilderness of the Internet. The key is to use company data to both spruce up your site and make it more dynamic while protecting sensitive data and not publishing incorrect data.
Have you ever wanted to publish content on the Internet or tie your Web server to an existing company database, but you were afraid to place the server directly in harm's way? Have you ever been unable to publish dynamic content because the server was inside the firewall? Connecting database servers directly to the Internet without some sort of protection isn't a good way to stay employed. In this third article in my Microsoft Proxy Server 2.0 series, I show you three methods for publishing Web content and other applications from behind your proxy server:
- Reverse Proxy
- Reverse Hosting
- Server Proxy
Each of these methods requires the use of a multihomed proxy server—that is, two interfaces delineating the internal network from the external network.
Reverse Proxy. Reverse Proxy redirects incoming Web requests to another server on the internal network. This method lets you take advantage of Proxy Server's caching feature to serve your Web site's pages. If the content isn't in the cache, Proxy Server retrieves the content from the real Web server on the internal network and, in turn, serves that content to the requesting browser on the external network.
Reverse Hosting. This second method borrows from the virtual-Web-site-hosting features of Microsoft Internet Information Server (IIS). With Reverse Hosting, you can publish a Web server as a virtual directory of the IIS installation on the proxy server. Because you need IIS to operate Proxy Server, you already have a fully functional Web server supporting the proxy server that you're using. Most serious Proxy Server administrators wouldn't consider hosting a large, bustling Web site in conjunction with a large Proxy Server user base on the same server, but the publishing features are present nonetheless.
Server Proxy. In my experience, Server Proxy is the best of the three methods. Reverse Proxy and Reverse Hosting can proxy only for Web sites; Server Proxy can help you publish Web sites from behind your proxy server and even publish some applications that require listening ports (e.g., Microsoft SQL Server, Microsoft Exchange Server). Your listening application must be running on a Microsoft Windows OS, support the Microsoft Proxy client, and connect to the Winsock Proxy service. UNIX applications and other applications running on non-Microsoft OSs can't support the use of Server Proxy.
When a Windows-based application uses Server Proxy, it uses the Microsoft Proxy client to request that Proxy Server open a new configurable port (e.g., the alternative Web port 8080) on the external interface to listen for new inbound connections on behalf of the Windows application. Everything received on that port is blindly passed to the intranet server without regard to content and vice versa, as though that Web server were running directly on the external interface of the proxy server. The chief benefit of using Server Proxy is that you can hide a Web server behind your proxy server and expose only those ports needed to publish Web pages.
Special Notes for SSL-Dependent Applications
If your application requires the use of Secure Sockets Layer (SSL), your only option is Server Proxy. Reverse Proxy and Reverse Hosting can't support passing encrypted data through a proxy server because they must evaluate each HTML request as it arrives and direct it to the proper Web server. Reverse Proxy can't properly evaluate the encrypted data and still maintain security. Reverse Proxy would have to decode the packets on the proxy server and send them unencrypted to the Web server—a configuration Microsoft doesn't recommend. (For more information about Proxy Server and SSL, see the Microsoft article "Using Server Proxy with SSL in Proxy Server 2.0" at http://support.microsoft.com/support/kb/articles/q184/0/30.asp.) Server Proxy gets around this roadblock by blindly passing requests between the client and the server without regard for packet (i.e., request) contents.
Setting Up Reverse Proxy
To set up Reverse Proxy, follow these steps:
- Open the proxy server's Microsoft Management Console (MMC).
- Double-click your computer to expand the list of services you can manage. The list might include Default FTP Site, Socks Proxy, Default Web Site, Web Proxy, and Winsock Proxy. (You might have more or fewer services, depending on the options you've installed.)
- Right-click Web Proxy to manage that service, then select Properties, as Screen 1 shows.
- In the Web Proxy Service Properties dialog box, click the Publishing tab. If you haven't enabled publishing on this proxy server, the only available option is the Enable Web publishing check box. Select the Enable Web publishing check box to enable publishing.
- Choose the default option—discarded, sent to the local web server, or sent to another web server—that best coincides with your publishing strategy. Screen 2 shows these publishing options. For example, if you want to establish Reverse Proxy on an internal Web server, choose sent to another web server, then enter the host name and port number of the real Web server.
Setting Up Reverse Hosting
To set up Reverse Hosting, follow steps 1 through 4 for Reverse Proxy (above). If you have no local content on your Web server to publish or you won't be establishing Reverse Proxy in addition to Reverse Hosting,
- Choose discarded from the incoming Web server request options you see in Screen 2.
- Click Add.
- In the Mapping dialog box, which Screen 3 shows, enter the path or URL that the Web server will be expecting. Reverse Hosting redirects all requests to another server. In the To this URL text box, enter the URL to which Reverse Hosting will redirect the inbound request.
Setting Up Server Proxy
For simplicity's sake, let's assume that you're going to set up a Web server from behind your proxy server. You can set up other listening applications by modifying the wspcfg.ini file, which I discuss later in this article. If you're using access controls on the Winsock Proxy service, check out the Microsoft article "Using Server Proxy with SSL in Proxy Server 2.0" at http://support.microsoft.com/support/kb/articles/q184/0/30.asp before proceeding.
To set up Server Proxy, follow these steps:
- Install the Microsoft Proxy client on the internal Web server. You can usually find this installation directory on the proxy server in the \mspclnts share, such as \\yourproxyservername\
mspclts. You must reboot after installing the client.
- If you want to install an SSL certificate, install it now on the internal Web server. If your Web application doesn't require SSL, ignore this step and move to step 3.
- In the directory in which you installed the Microsoft Proxy client (e.g., C:\mspclnt), run chkwsp32.exe with the f parameter to get some diagnostic information about your client and the proxy server. The utility returns a lot of diagnostic information, but you're looking for the last sentence only, which should read Client control protocol version MATCHES the server control protocol. If the protocols don't match, chances are you haven't installed TCP/IP or IPX correctly on either the server or the client, or the client can't reach the proxy server.
- Create a text file called wspcfg.ini, and place it into the directory in which inetinfo.exe resides on the internal Web server. (If you're using Server Proxy with SQL Server, Novell GroupWise, or another Windows-based product, place the wspcfg.ini file in the same directory in which the main executable resides.) The .ini file will look something like this: \[Inetinfo\]
- Restart the Web service on the internal Web server.
When you've restarted the Web Service, you can connect to your site on the port number specified in \[ServerBindTcpPorts\] in the wspcfg.ini file. Note that from the inside, you can't point to your Web site by using the external proxy address; you must use the internal server's real IP address instead, which can sometimes create confusion (especially in environments with internal and external DNS tables). You might have to get creative about how you name things internally and externally to accomplish this task.
Server Proxy takes a bit more work to set up than the Reverse Proxy and Reverse Hosting methods, and it won't work with every application. If the above steps fail to punch your application through the proxy server, recheck your steps. If the setup is still failing, check out the following Microsoft articles regarding Server Proxy setup:
- "Using Server Proxy with SSL in Proxy Server 2.0" at http://support .microsoft.com/support/kb/articles/q184/0/30.asp
- "Additional Proxy Server 2.0 Configurations" at http://support.microsoft .com/support/kb/articles/q177/1/53.asp
- "Accessing Intranet Data Protected by Microsoft Proxy Server 2.0" at http://support.microsoft.com/support/kb/articles/q187/6/52.asp
Constructing wspcfg.ini manually. If these articles don't mention your application directly, you might be able to modify wspcfg.ini to fit your needs. Let's examine the contents of the file and explain each of the fields used.
- \[Inetinfo\]—This line matches the main executable of the application on which you're establishing Proxy Server. If you were trying to establish Server Proxy on SQL Server, the line would appear as \[sqlservr\]. If you were establishing Server Proxy on pcAnywhere, the line would appear as \[awhost32\].
- \[ServerBindTcpPorts\]—This line declares the ports on the proxy server that will open and start listening. You can state the line as a single port, a list of ports separated by commas, or a range of ports.
- \[LocalBindTcpPorts\] (optional)—This line names the ports on the local host that will open and start listening. You can specify multiple ports for each executable. You can state this line as a single port, a list of ports separated by commas, or a range of ports.
- \[Persistent\] (optional)—If you set this value to 1, it maintains the server's state when services restart. Any existing ports won't be reset upon the restart of services.
- \[KillOldSession\] (optional)—When you set this value to 1, it terminates any old Microsoft Proxy client sessions that might have the port locked for use.
- \[Force Credentials\] (optional)—Use this line with the credtool.exe utility to provide credentials to the Winsock Proxy service. If you set the value to 1, the line supplies credentials.
When you save the wspcfg.ini file, be sure to save it in plaintext. If you're using Notepad, be certain that you're not saving the file in Unicode format. Store the file in the same directory in which the executable exists.
Note that you can use a combination of any of the methods I've discussed on the same proxy server to fit your needs. For example, if you need to add a second Web site to the same IIS server from the internal network, you can use Server Proxy to establish the second server behind the proxy server, then use Reverse Hosting to redirect the inbound HTML request on port 80 to any other port you need.
Performance and Security Considerations
Reverse Hosting and Reverse Proxy can serve pages back to clients faster than Server Proxy can because Server Proxy must act as the intermediary between the requesting browser and the server holding the content. Reverse Hosting and Reverse Proxy can benefit from the use of Proxy Server's caching feature. However, Reverse Hosting and Reverse Proxy require additional resources on the local Proxy Server, such as processor, memory, and disk resources. Server Proxy, therefore, is the most efficient method in terms of proxy resources. Depending on the type of content that you serve, however, and because of the speed of Proxy Server's caching feature, you might be able to get faster responses to your requesting browsers by using Reverse Hosting and Reverse Proxy.
Because you're publishing from behind the proxy server, you're more secure than if you simply attached the server directly to the Internet. Remember, however, that you still need to establish and maintain good security habits on your Web server. You can have the most secure firewall and proxy server configuration, but if you haven't secured your published Web server, you can easily become the latest defacement victim. These publishing methods use Proxy Server to help you protect the OS, not the application.
Proxy Server offers you several options for publishing your content safely and securely from behind your proxy server. In environments that contain both a proxy server and a firewall, publishing from behind Proxy Server eliminates the need for having busy Web servers crossing a firewall. If you set up Proxy Server correctly, it's a smart move that will increase the value of your Proxy Server installation.
In the next installment of the Proxy Server series, I'll concentrate more on Proxy Server's caching feature. I'll also look at what it takes to make the caching feature run efficiently.