Another ISA Server limitation with implementing a three-homed DMZ is that ISA Server supports only IP packet filtering for computers in the DMZ. Consequently, you don't get the security benefits of Network Address Translation (NAT) or ISA Server's server-publishing, application-filtering, and client-access control features. This limitation also means you must assign valid public IP addresses to servers in the DMZ instead of using private addresses and NAT. So, if you're transforming a simple network to a three-homed DMZ, you might need to purchase additional IP addresses from your ISP.
The public IP addresses you assign to computers in the DMZ must be a subnet of your firewall's IP address. You can use an address for your DMZ segment that isn't a subnet of your firewall's address, but you need to notify your ISP so that it can route packets for your DMZ to your firewall. For example, suppose that your ISP provides you with two subnets: w.x.y.z/24, which is a public IP address that's part of the ISP's larger subnet, and a.b.c.d/29. You can assign w.x.y.z/24 to the external interface of your firewall. You can then have your ISP route all packets destined for a.b.c.d/29 to w.x.y.z/24, even though a.b.c.d/29 isn't a subnet of w.x.y.z/24.
To set up a three-homed DMZ that uses ISA Server as the firewall, you need to first install three NICs on the server. Then, you must install Win2K and its latest service pack (at the time of this writing, Service Pack 3—SP3) and ISA Server and it latest service pack (at the time of this writing, SP1). Next, run Windows Update to install any post-SP3 hotfixes, and visit http://www.microsoft.com/isaserver/downloads/default.asp to install any ISA Server hotfixes that came out since the release of ISA Server SP1.
With the installations complete, you can configure ISA Server's LAT with your internal network's addresses. Don't include any addresses in your DMZ or any other addresses on the Internet. Next, enable packet filtering and IP routing. To control the internal network users' access to the Internet and DMZ, configure the appropriate site and content rules and protocol rules. If you're unfamiliar with how to configure ISA Server, see "ISA Server: Your Network's Lifeguard," October 2001, http://www.winnetmag.com, InstantDoc ID 22251.
To let users on the Internet access servers in your DMZ, you must create IP packet filters that open the appropriate ports for each server in the DMZ. For example, if you have a Web server and SMTP gateway in the DMZ, you need to create a filter that opens up TCP port 80 to your Web server (or TCP port 443 if you use HTTP Secure—HTTPS). You then need to create two filters that allow connections to incoming-destination TCP port 25 and from outgoing-destination TCP port 25 on your SMTP gateway.
Next, you need to enable SMTP to flow between your internal Exchange server (or other email server) on your internal network and the email gateway in the DMZ. To do this, you need to create a server-publishing rule that lets the gateway open SMTP connections to the internal Exchange server for incoming email messages and create a protocol rule that lets the Exchange server open SMTP connections to the gateway for outgoing email messages. If your Web server needs to access resources on an internal server such as a SQL Server machine, you need to also create a server-publishing rule that lets the Web server in the DMZ access the SQL Server machine. By creating server-publishing rules, you limit the risk to which your internal servers are exposed in case an attacker gains control of the Web server in the DMZ.
Even with the server-publishing rules and protocol rules, you still have some security holes associated with the internal servers. Fortunately, you can apply another layer of protection. For example, to mitigate the risks associated with an internal Exchange server, ISA Server includes an excellent application filter for SMTP that lets you lock down the connection from your email gateway to your Exchange server. You can configure the SMTP filter to block certain SMTP commands, attachments, and domains and even scan email messages for specific keywords. The SMTP filter enforces size constraints on each allowed SMTP command to help prevent SMTP-specific buffer-overflow attacks. Mitigating SQL Serverbased risks is more difficult than mitigating Exchange risks because ISA Server doesn't have an application filter for SQL Server. However, you can make breaking into SQL Server as difficult as possible. For example, you can implement good password and lockout controls on your SQL Server machine, even though only the trusted Web server has access to it. Make sure your Web application protects the credentials it uses to connect to the SQL Server machine—in other words, don't hard-code the username and password into the application's source code. And make sure you limit the SQL Server account to the bare minimum authority it needs within SQL Server to accomplish its job. Don't let your Web application use a systems administrator (SA) account to connect to the SQL server. Instead, have the Web application use an account with limited permissions.
Finally, you need to consider whether and how you will implement HTTPS to protect private areas of your Web site. Implementing HTTPS in a three-homed DMZ is easy because ISA Server simply routes packets between the Internet and the DMZ. To implement HTTPS in a three-homed DMZ, you just request a server certificate from a public Certificate Authority (CA) and install that certificate on the Web server in the DMZ.
The Back-to-Back DMZ
With two firewalls, you can use private IP addresses and NAT to conceal both your DMZ and internal network. As Figure 2 shows, the outer firewall publishes the DMZ's Web server and SMTP gateway to the Internet. The inner firewall publishes the Exchange server to the SMTP gateway.
Prev. page
1
[2]
3
next page 
