The last statement is especially important. The reason you create a DMZ segment is to segregate Internet traffic away from your internal network. No inbound traffic should ever move from the DMZ segment to the internal network.
This concept of a separate and distinct security zone defines the DMZ. People run into problems with this because they want to do things like:
- Use an MMC console to manage servers on the DMZ (allow RPC)
- Make DMZ servers members of the internal network domain (ouch!)
Allow Web servers on the DMZ access to database servers on the internal network
- Terminate a VPN connection on a device upstream from the ISA Server and then access the internal network from that host
- Place an Outlook Web Access Front End server in the DMZ and a Back End server on the internal network
All of these designs violate the integrity of the DMZ. DMZ hosts are “sacrificial lambs” and you should expect them to be compromised. It makes no sense to allow communications between DMZ hosts and the internal network if you expect these hosts to be compromised (in general, there may be exceptions).
Multiple Internal Interfaces – The Poor Man’s DMZ
What is a Poor Man’s DMZ? This is a DMZ segment directly connected to the ISA Server that uses private IP addresses that are contained in the LAT. This DMZ segment is able to communicate with the internal network segment, and the internal network segment can directly communicate with the DMZ segment. The key to making this work is to use techniques outside of the ISA Server configuration to control packet flow between hosts on each segment.
There are several approaches you can use to control packet flow on network hosts:
- TCP/IP Security
- IPSec Policies
- RRAS Packet Filters
The simplest approach, and the one we’ll cover in this article, its to use TCP/IP Security. TCP/IP Security is available in Windows NT 4.0 and Windows 2000. TCP/IP Security filtering allows you to control what inbound packets are accepted on a host interface. Key features of the TCP/IP Security include:
- Only inbound packets are blocked
- Outbound traffic, and responses to inbound traffic, are not affected
- Different filters can be configured on each interface of a multihomed machine
- You cannot control ICMP packet flow using TCP/IP Security filters
TCP/IP Security is helpful in controlling inbound access to the server on the Poor Man’s DMZ segment but does nothing to prevent outbound communications from the server on the DMZ segment to machines on the internal network. TCP/IP Security filtering is just one tool in your security bag. You’ll need to use IPSec Policies and/or RRAS packet filtering to control outbound traffic from your Poor Man’s DMZ segment.
Configuring TCP/IP Security
Perform the following steps to configure TCP/IP Security:
- Open the Control Panel and then open the Network and Dial-up Connections applet.
- Right click on the interface you need inbound access control and click Properties.
- Select the Internet Protocol (TCP/IP) in the Components checked are used by this connection list box and click Properties.
- Click the Advanced button in the Internet Protocol (TCP/IP) Properties dialog box.
- Click the Options tab in the Advanced TCP/IP Settings dialog box.
- Click the TCP/IP filtering entry and click Properties.
- Place a checkmark in the Enable TCP/IP Filtering (All adapters) checkbox. Note that when you put a checkmark in this checkbox it enables filtering for all adapters, but the filters are configured on a per-adapter basis. The same filters do not apply to all adapters.
- There are three columns: TCP Ports, UDP Ports and IP Protocols. For each of these you have two choices: Permit All and Permit Only. If you wish to permit all packets for TCP or UDP traffic then leave the Permit All option selected. If you wish to allow selected TCP or UDP traffic, select the Permit Only option and click the Add button and enter the appropriate port in the Add Filter dialog box. In the example below we allow only TCP ports 25 and 80 (SMTP and HTTP) and GRE (Generic Routing Encapsulation for PPTP) inbound. All other inbound packets will be dropped except for GRE.
- If you wish to block all UDP or TCP traffic, select the Permit Only option and then do not enter any port numbers in the UDP Ports or TCP Port column. You cannot block UDP or TCP traffic by selecting the IP Protocols Permit Only option and exclude IP Protocol 6 and IP Protocol 17. In the figure below, we allow only inbound GRE. Allow other inbound packets will be dropped except for ICMP.
- You cannot block ICMP messages. This is true even if you select the IP Protocols column and select Permit Only and fail to include IP Protocol 1.
Internet Protocol Number assignment are listed in Q289892. You can find TCP and UDP port number assignments at http://www.iana.org/assignments/port-numbers.
Conclusion
The trihomed DMZ should be considered a kludge. An actual DMZ is bordered by two security devices. A trihomed DMZ provides a single point of failure in your security scheme. When you implement a proper DMZ, using two security devices, the edge security device can fail and your internal network is remains secure. The machines on the DMZ may be compromised, but that is the nature of the DMZ bastion host.
We all have to use kludges from time to time, and that’s why there’s the trihomed DMZ. If you can’t meet the requirements of a true trihomed DMZ, you can use private addresses and make a Poor Man’s DMZ. In this article we went over one method you can use to control access to servers on the DMZ segment. In the second part of this series I’ll go over how to configure IPSec Policies to control inbound and outbound packet filter to and from DMZ servers. | 
