Step 4: Design a Secure Architecture

You should use a distributed architecture design, putting key components on separate computers. This builds in protection against any single point of failure. For example, Figure 13-1 takes a first stab at a secure architecture for a Web application that serves pages using http and https.

Figure 13-1: Secure Web application architecture 1

The client computer (a) browses through the Internet to the Web site. When the user’s computer sends a request to the Web site, it first encounters a firewall that blocks all communications except those on ports 80 (http) and 443 (https). After the firewall, the only computer connected to the Internet is the server running Internet Information Services (IIS) and URLScan (c). URLScan further monitors the request, filtering out long strings and suspicious http verbs such as FPSE (which is used for Microsoft FrontPage server extensions). Most Web sites need allow only three HTTP verbs: GET, POST, and HEAD. (GET requests a Web page, POST submits information from the browser to the server, and HEAD requests just the header of a Web page—typically to check whether the page has changed from a cached version.) If the request makes it through the firewall and URLScan, IIS then processes the request. IIS is configured to run under a low-privileged domain account. Both the Domain Controller (d) and SQL Server (e) are running on separate computers. The SQL Server machine is also running IPSec, which is configured to accept communication only from the IIS machine.

Let’s see what happens when an intruder or virus attempts to attack the Web site. First, most unusual communication is filtered out by the firewall (for example, the SQL Slammer virus wouldn’t make it past the firewall because it uses port 1434). If the request is using port 80, URLScan further analyzes the request and will filter out anything suspicious (such as a long string that attempts to create a buffer overflow). If the intruder somehow manages to beat the firewall, as well as URLScan and gets access to the IIS computer, he is limited in the amount of damage he can perform outside the IIS machine because the only two accounts running are the local system account (which has no permissions on other machines) and the user account that IIS uses (which is a low-privilege domain account). The intruder might be able to access the SQL Server database, but only within the restrictions of what the Web application is allowed to perform. Performing a destructive action, such as formatting the hard disk on the IIS machine, will not affect the domain controller or SQL Server.

While this is a good architecture for a simple system, with additional effort (and extra hardware), you can choose an even more secure architecture, which further isolates the IIS machine, as in Figure 13-2.

Figure 13-2: Secure Web application architecture 2

In this model, the Internet-facing Web server is isolated on its own domain, in a DMZ (from the military term demilitarized zone). This server is a proxy for the Web site, passing all user requests through a firewall using a Web service to another IIS server, which itself is on the domain with SQL Server and the domain controller. This second IIS server processes the user’s request and returns Web pages to the Internet-facing Web Server, which returns the page to the user. This architecture, which some of the world’s largest Web sites use, requires some effort to configure. For more information, see the MSDN article at http://msdn.microsoft.com/library/en-us/dndna/html/dnablueprint.asp.

For intranet Web applications, you should again put IIS, SQL Server, and the domain controller on separate machines, as in Figure 13-3.

Figure 13-3: Secure intranet Web architecture

Users have to log on to the domain before accessing IIS. IIS uses Windows authentication to ensure the client is a valid user. IIS then accesses SQL Server. The SQL Server machine uses IPSec to ensure only the IIS machine can access the database. This is also a good architecture to use for applications with a middle tier—that is, the IIS computer represents either a Web server or a COM+ application server.

For client-server applications, again put SQL Server and the domain controller on separate machines as in Figure 13-4.

Figure 13-4: Secure client-server architecture

A client-server application is similar to an intranet application—users are first authenticated by the domain controller, after which they can access SQL Server.

Named-Pipes vs. TCP-IP

When SQL Server is installed, out of the box it supports two network access protocols: named-pipes and TCP-IP. Should you leave this configuration as is or change it? If you change the configuration, should you use named-pipes only, TCP/IP only, or something else? Both protocols have the edge in different circumstances. The recommendation is: if the client application and SQL Server are both on the local machine, use named-pipes. Named-pipes are very fast on a local machine. If you are using SQL Server clustering, again use named-pipes. Clustering requires named-pipes. In all other circumstances, use TCP/IP. TCP/IP is slightly faster over a network because it’s less chatty than named-pipes. TCP/IP can be used to access a SQL Server across a firewall, whereas named-pipes cannot communicate across a firewall.

Named-pipes is not a network transport; instead, it’s a protocol that uses the existing underlying network transport for communication. On most networks, the network transport is TCP/IP, which means that named-pipes actually uses TCP/IP. For this reason, both named-pipes and TCP/IP can be used in conjunction with IPSec to limit which computers are accessing the SQL Server and to filter the types of TCP/IP communication that the server will respond to. In addition, both named-pipes and TCP/IP communication can be encrypted using SSL.

If You Do Nothing Else…

If you are developing a Web application and have limited control over the architecture, there are four simple things you must do to stop the majority of Web attacks. In other words, if you do nothing else, do the following:

• Install a firewall, and limit traffic to only the ports your application needs.

• Install URLScan on the IIS machine.

• Apply every security patch from Microsoft as soon as they become available.

• Install a virus scanner, and keep the virus signatures up to date.