SQL Server Magazine

When a Web site's traffic begins to outweigh the Web server's ability to keep up with incoming client requests, you need to upsize your Web server. This article discusses the security and performance challenges I faced in upsizing my Web site, and how I configured SQL Server to defend my Web site against intruders.

My Web site, http://www.ntsecurity.net, provides information about Microsoft-related security issues. In the past, I used HTML disk files from an Internet Information Server (IIS) to serve the content, as many sites still do. My setup worked well for a long time, but as traffic increased, server performance dropped in proportion to the additional daily traffic. And because bandwidth wasn't a factor in the degradation, I faced the task of reengineering my entire Web system from the ground up. I decided my primary goals were to regain lost performance, add performance, and ease the burden of adding new content to the Web site.

In addition, without a strong database back end, I couldn't add the new features to the site that I wanted. Items on my wish list included dynamic Web page content that changed based on how the stored content was dated, a product database that allowed product owners to manage their database records, and a simplified means of adding new content to the site. I decided that SQL Server and Active Server Pages (ASP) were the ticket I needed to meet these needs.

To drag my Web site out of the past and into the present, I built two new servers: one for IIS and one for SQL Server. With this setup, I could separate the Web client load from SQL query loads, introduce a higher level of subsystem isolation, and add the new features on my wish list. With a two-server configuration, I could use IIS to serve static HTML- and ASP-based Web pages. Also, I could use SQL Server to store Web pages and other HTML-based information in database table records, where IIS could use an ASP application to retrieve those records for display.

In the end, the two-server configuration works well. If you view my home page now, you'll see a long list of news stories. I store every item in SQL table records with a date stamp for the publication date. When the home page loads, an ASP application queries

Configuring a Two-Server Setup
Here's how I structured the two-server setup and how I designed and configured the security aspects of the systems. I used SQL Server 6.5 when I built the new Web site. Also, I assume most readers know how to create user accounts and set table permissions, so I won't go into the details of those basic SQL tasks, but I will give specific information when necessary.

I chose Microsoft Site Server 3.0 Commerce Edition because it offers features that standard IIS doesn't, such as a membership and personalization system, a built-in ad manager system, and a more robust Index Server. And because those technologies rely on a SQL Server back end, Site Server 3.0 Commerce Edition perfectly fit my needs.

In a nutshell, I installed Site Server Commerce on one system, installed SQL Server on another system, and connected those two systems on a network so they could communicate with each other. I discovered that you can run IIS and SQL Server on the same system and get reasonable performance results, as long as the system has plenty of RAM and CPU power. For example, I found that a 233MHz Pentium II server system with 128MB of RAM could deliver at least 1 million pages per month without any noticeable performance degradation. However, deliberately choosing this setup isn't wise. With both sets of software running on one system, security and system failures can jeopardize your Web site's availability. If you have a serious hardware failure, such as a crashed hard disk, you risk losing data, and recovery will take longer to complete than if you had the software running on two systems. In addition, if your single system is compromised, both IIS and SQL Server will be wide open to attack. You're always better off investing in an additional, separate system so you can isolate and control SQL Server. And this point brings me to the first security consideration: connectivity between two machines that work together to deliver Web pages.

SQL Server can communicate across many protocols, including TCP/IP and NetBEUI. But for security's sake, I don't recommend using TCP/IP on a SQL Server unless you have no other choice, because TCP/IP might expose the server to the Internet if the border protection systems, such as firewalls, aren't configured to prevent direct access. If you use NetBEUI instead of TCP/IP, even an improperly configured firewall won't let outsiders into your SQL Server from a TCP/IP network.

I didn't need to provide anyone TCP/IP access to the SQL Server, so during the SQL Server installation process, I structured the server to use named pipes. This setup caused SQL Server to require the use of named pipes and to ignore any available network protocols. Using named pipes on the SQL Server system meant that I also had to configure the IIS server to use the NetBEUI protocol so that the two systems could communicate with each other. During the installation process, I chose not to enable SQL Mail because that technology might grant an intruder an easy means to transmit SQL Server user IDs and passwords to a remote system if the server becomes compromised.

   Prev. page   [1] 2     next page