DMZs Morph Into Security Perimeters

8/9/2019 DMZs Morph Into Security Perimeters

1/28

DMZs Morph into Security Perimeters

The problem these security wonks have is that all DMZs are not created equal. Not all hostsbelong to the same security zone. Hosts belonging to different security zones need to be separated

by network access control devices to mitigate (notice I didnt prevent) compromises in one

security zone from quickly extending to other security zones. Ignoring this reality take more thana grain of salt it takes a willing suspension of disbelief.

For example, theres a reason why you cant take your friends and family into the Pentagon WarRoom you and your family belong to a different security zone than the War Room attendees,

and there are multiple security devices that make sure there are access controls.

One thing many of these anti-firewall guys have right is that host-based security is the holy grailof computer security. The more secure and selective the host is about sending and receiving

traffic, the easier it is for access control devices in front of the host to protect that host, and themore secure that host is against hosts in different andsame security zones.

However, I am confident that host-based security Nirvana will not be seen in the next two tothree decades (if ever), so perimeter devices interposed between security zone will continue to be

required and popular. My confidence is borne from my experience in Medicine and knowledge oflaw enforcement. In medicine, viruses and bacteria mutate to defeat our efforts to come up with

consistently effective antimicrobials, and law enforcement has been working on eliminatingcrime since the murder took place. Hackers and other network criminals are no different than

harmful microbes or bag-men, they will continue to exist, and the better ones will evolve theirmethods and techniques to subvert even the most effective host-based security systems.

Thats why well always need firewalls as perimeter security devices to provide defense in depth.

Firewall will continue to evolve, and the future will certainly see the features of current dayfirewalls meld the features of stateful packet inspection, stateful application layer inspection, IPS

and IDS integrated in a single device. The major hurdle is processing power, and we know fromlong experience that this problem will be solved in time. Marketing guys will certainly morph the

term firewall into something else (since firewalls will be seen an superannuated devices bythen), but they will be firewalls, regardless of the name marketeers and security wankers may

give them.

Keep in mind that theperimeteris not the place where the corporate network meets the Internet.There is no perimeter, there are multiple perimeters. This is often hard to communicate to 1990s

firewall admin who consider packet filtering-only devices as comprehensive security solutions

and who think in terms of opening a port or closing a port. All but the most simple networkshave multiple perimeters and an access control device (such as an ISA firewall) must be placedinline to separate these perimeters. This is one of the major reasons why I have such distain forunihomed ISA firewalls unihomed ISA firewalls provide an illusion of security, but since they

are not inline devices, its a very simple task to bypass the unihomed ISA firewall.

Define Your Security Zones


2/28

A key concept in DMZ construction is to place machines in different security zones on different

segments, where the segments are separated by a network security device, such as ISA firewall.Now, the trick is in defining your security zones. There are a number of methods you can use to

define security zones. Some examples include:

yA zone could include all services providing a similar function

y A zone could include all machines belonging to the same Active Directory domainy A zone could include all services that are interdependent on one anothery A zone could include all machines run by untrusted usersy A zone could include all devices managed by trusted partnersy A zone could include all Internet facing devices

Its beyond the scope of this article to go into an in-depth discussion of security zone

classification and segmentation, but I wanted to bring up the subject so that we could focus onone important method of defining security zone: placing Internet facing devices in a security zone

separate and distinct from all devices that arent Internet facing.

The term Internet facing means that inboundconnections can be made to these machines. Any

device accepting connections from Internet hosts is consideredInternet facing. Placing allInternet facing devices on network segments segregated from non-Internet facing devices is well

known and universally accepted method of reducing your attack surface and mitigating some ofthe risks inherent in placing Internet facing devices on security zones that are not designed to

accept incoming connections from Internet hosts.

There are several types of DMZ segments where you can place these Internet facing devices:

y Anonymous access DMZs These DMZs allow anonymous users to connect to Internetfacing devices in the DMZ and the servers in the DMZ allow anonymous connections tothem. Inbound SMTP relays and public DNS servers are often found on anonymous

access DMZs.y Authenticated access DMZs An authenticated access DMZ is significantly more secure

than an anonymous access DMZ, because users are authenticated at the firewalland thenauthorizedby the firewall before the connection is forwarded to the DMZ server. No

anonymous connections are allowed to authenticated access DMZ, which eliminates theoverwhelming majority of attacks that the DMZ server would otherwise be exposed to

y Mixed anonymous/authenticated access DMZs These DMZs allow anonymousconnections through the firewall, but servers on the DMZ require authentication. These

servers could authenticate using a local user database, an Active Directory domain locatedonly in the DMZ, or an Active Directory domain located on the corporate network, behind

a back-end firewall

The figure below depicts multiple DMZ security zones. The red zone represents the anonymousaccess DMZ, where the back-end ISA firewall allows anonymous connections to services located

on that segment. The Authenticated access DMZ (or perimeter network) represents a securityzone where only authenticated users are allowed access to the zone itself; this requires that at

least ISA firewall pre-authenticate the user prior to allowing access to resources in the zone itself.The servers within the zone may require authentication as well, but the key here is that


3/28

connections must bepre-authenticatedandpre-authorizedprior to even getting to the point of

being authenticated by the server. The honeypot DMZ represents a more traditional DMZsegment, where anonymous access to virtually any protocol from internal hosts, and most

common protocols from external hosts, is allowed. You might put IDS/IPS and honeypot systemson that DMZ.

Figure 1

Have Questions about the article?

Ask at http://tinyurl.com/mflgw

Front-end Exchange Servers Should be Placed in a DMZ

Segment

Notice that the front-end Exchange Server is placed in the authenticated access DMZ. This

provides an extra layer of protection by removing the front-end Exchange Servers from the back-


4/28

end Exchange Servers security zone. This is an excellent configuration because the back-end

Exchange Servers are never Internet facing, while the front-end Exchange Servers often are.

A common thread that runs through each of these DMZ implementations is that Internet facingdevices are segregated from devices that do not accept incoming connections from Internet hosts.

It should be obvious that the attacker [sic] surfacepresented by the Internet is much larger thanany potential attacker surface presented by hosts on only non-Internet facing networks. If for no

other reason (and there are plenty of more reasons), you should always exercise due diligence andmove Internet facing devices offof networks that are not strictly designed for Internet facing

hosts.

One of the best examples of how to handle this problem is seen with the front-end/back-endExchange Server solution. Because the front-end Exchange Server is typically an Internet facing

host, the Internet facing front-end Exchange Server should always be in a DMZ segment, andshould neverbe on the same network security zone or perimeter where the back-end Exchange

Servers are located.

Placing the Internet facing front-end Exchange Server in a separate DMZ segment is a critical

distinction and something you need to consider in your front-end/back-end Exchange Serverdeployments, especially in the light of some of the things Ive read in the tech media recently

which seem to imply that you can place your front-end and back-end Exchange Servers on thesame security zone and have the same level of security you would have had you placed the front-

end in an authenticated access DMZ. Think about it and decide which solution offers a superiorsecurity solution and I think youll agree with me about placing front-end Exchange Servers in a

separate security zone.


5/28

Configure the Back-end ISA firewall with a DMZ ISA

Firewall Network

One of the most prevalent misconceptions regarding ISA firewall Networks and how the ISA

firewall sees the network world is how the ISA firewall deals with the default External Network.Lets set the record straight: the default External Network on the ISA firewall is defined by any

IP address that isnt part of any other ISA firewall Network configured on the ISA firewall.

What this means is you can configure any set of IP addresses that arent part of another ISAfirewall Network to be part of a custom ISA firewall Network. This includes the IP addressbound to the external interface of the ISA firewall (although the IP address on the external

interface of the ISA firewall will always belong to the Local Host Network).

This allows you to create a custom ISA firewall Network that includes the IP addresses in theDMZ Network between the front-end and back-end ISA firewalls. These addresses donotneed to

be part of the default External Network, even though the DMZ is on the same network ID as theexternal interface of the ISA firewall. The term external interface only means that its the

interface with the default gateway configured on it, which typically is the closest to the Internet.

The value of making the DMZ between the front-end and back-end ISA firewalls on its own ISAfirewall Network is that you can control the routing relationship between that Network and any


6/28

other Network defined on the ISA firewall. In the example network used in this article,

configuring a custom DMZ ISA firewall Network will enable us to create a route relationshipbetween the default Internal Network behind the back-end ISA firewall and the DMZ Network

between the front-end and back-end ISA firewalls. We can also create Access Rules controllingtraffic moving to and from any ISA firewall Network.

Perform the following steps on the back-end ISA firewall to create the DMZ ISA firewall

Network:

1. In the ISA firewall console, expand the server name and then expand the Configurationnode. Click the Networks node.

2. On the Networks node, click the Networks tab in the details pane. Click the Tasks tab inthe Task Pane and then click the Create a New Networklink.

3. On the Welcome to the New NetworkWizard page, enter a name for the Network in theNetwork name text box. In this example well name the NetworkDMZ. ClickNext.

4. On the Network Type page, select the Perimeter Networkoption and clickNext.5. On the Network Address page, click the Add button.6. In the IP Address Range Properties dialog box, enter the Starting address and Ending

Address for the DMZ Network. In this example well enter10.0.1.0 for the StartingAddress and 10.01.255 for the Ending Address. Note that you dont have to include the

entire network ID; you can include only the addresses that are actually in use on thatnetwork, or you can get even more specific and include only those addresses that you

want to have a route relationship with the default Internet Network behind the back-endISA firewall, so that you can later create another ISA firewall Network representing other

addresses in the DMZ segment that you want to create a NAT relationship with. ClickOK.


7/28

Figure 1

7. ClickNext on the Network Addresses page.

Figure 2


8/28

8. ClickFinish on the Completing the New NetworkWizard page.Configure the Back-end ISA Firewall with a Network Rule

Setting a Route relationship between the back-end ISA

Firewalls Default Internal Network and the DMZ ISAFirewall Network

In the scenario discussed in this article, the Web server on the DMZ Network is a member of theActive Directory domain whos domain controllers are located behind the back-end ISA firewall.

This allows the Web server on the DMZ Network to leverage the Active Directory database toauthenticate users connecting to the Web site. This scenario is very similar to that seen in a front-

end/back-end Exchange Server configuration, since the front-end/back-end Exchange Serversmust be members of the same Active Directory domain.

This means we need to enable intradomain communications between the Web server on the DMZNetwork and the domain controllers on the default Internal Network located behind the back-end

ISA firewall. Intradomain communications require that you have a Route relationship betweenthe source and destination networks. For this reason, we will create a Network Rule that sets a

Route relationship between the DMZ Network and the default Internal Network located behindthe back-end ISA firewall.

It's important to note that although there will be a route relationship between the back-end ISA

firewalls default Internal Network and the DMZ Network, there will still be a NAT relationshipbetween the back-end ISA firewalls default Internal Network and the Internet. This is fully

supported (and required), since private addresses are used on the corporate network.

It doesnt matter if you use public or private addresses on the DMZ Network. Even if you use

public addresses on the DMZ Network, you can still have a route relationship between the DMZNetwork and the default Internal Network using private addresses behind the back-end ISA

firewall because the ISA firewall is directly connected to both Networks and thus has fullknowledge of how to reach both Networks.

Perform the following steps to create the Network Rule creating a route relationship between the

DMZ Network and the default Internal Network behind the back-end ISA firewall:

1. In the ISA firewall console, expand the server name and then expand the Configurationnode in the left pane of the console. Click the Networks node.

2. On the Networks node, click the Network Rules tab in the details pane of the console,then click the Create a New Network Rule link in the Tasks tab of the Task Pane.

3. On the Welcome to the New Network Rule Wizard page, enter a name for the rule inthe Network rule name text box. In this example well name the rule DMZ Internal.

ClickNext.4. On the Network Traffic Sources page, click the Add button.5. In the Add Network Entities dialog box, click the Networks folder and then double click

the DMZ Network. ClickClose.


9/28

Figure 3

6. ClickNext on the Network Traffic Sources page.7. ClickAdd on the Network Traffic Destinations page.8. Click the Networks folder and then double click the Internal entry. ClickClose.9. On the Network Relationship page, select the Route option and clickNext.


10/28

Figure 4

10.ClickFinish on the Completing the New Network Rule Wizard page.Have Questions about the article?

Ask at: http://tinyurl.com/jb6k2

C

reate Access Rules Enabling Intra-domainCommunications between the DMZ Server and the Domain

Controller on the Back-end ISA Firewalls Default Internal

Network

Multiple protocols are required to allow intradomain communications between the DMZ host and

the domain controllers on the corporate network. Table 1 provides the details of this Access Rule.


11/28

Name Intradomain Communications

Action Allow

Protocols Microsoft CIFS (TCP)

Microsoft CIFS (UDP)

DNS

Kerberos-Adm(UDP)

Kerberos-Sec(TCP)

Kerberos-Sec(UDP)

LDAP

LDAP (UDP)

LDAP GC (Global Catalog)

RPC (all interfaces)

NTP (UDP)

Ping

From DMZ Web Server

Domain ControllerTo Domain Controller

DMZ Web Server

Users All

Schedule Always

Content Types All content types

Table 1: Access Rule allowing intradomain communications between the DMZ host and the DC

on the default Internal Network behind the back-end ISA firewall

Perform the following steps to create this Access Rule:

1. In the ISA firewall console, expand the server name and then click the Firewall Policynode in the left pane of the console.

2. On the Firewall Policy node, click the Tasks tab in the Task Pane and click the CreateNew Access Rule link.


12/28

3. On the Welcome to the New Access Rule Wizard page, enter the name of the rule in theAccess Rule name text box. In this example, well name the rule Intradomain DMZInternal and clickNext.

4. Select the Allow option on the Rule Action page.5. On the Protocols page, select the Selected protocols option from the This rule applies to

list. ClickAdd.6. Click the Add Protocols folder and then double click the following protocols:Microsoft CIFS (TCP)

Microsoft CIFS (UDP)

DNS

Kerberos-Adm(UDP)

Kerberos-Sec(TCP)

Kerberos-Sec(UDP)

LDAP

LDAP (UDP)

LDAP GC (Global Catalog)

RPC (all interfaces)

NTP (UDP)

PingClickClose in the Add Protocols dialog box.

7. ClickNext on the Protocols page.

Figure 5


13/28

8. On the Access Rule Sources page, click the Addbutton.9. In the Add Network Entities dialog box, click the New menu and then clickComputer.10.In the New Computer Rule Element dialog box, enter a name for the Web server on the

DMZ Network. In this example well name the Computer Object DMZWeb Server.Enter the IP address of the DMZ Web server in the Computer IP Address text box. Enter

an optional Description if you like. ClickOK.

Figure 6

11.In the Add Network Entities dialog box, click the New menu and then clickComputer.12.In the New Computer Rule Element dialog box, enter a name for the domain controller

on the Internal Network. In this example well name the Computer Object DomainController. Enter the IP address of the domain controller in the Computer IP Addresstext box. Enter an optional Description if you like. ClickOK.


14/28

Figure 7

13.Click the Computers folder and double click the DMZWeb Server and DomainController entries.

Figure 8


15/28

14.ClickNext on the Access Rule Sources page.15.ClickAdd on the Access Rule Destinations page.16.In the Add Network Entities dialog box, click the Computers folder and then double

click on the DMZWeb Server and Domain Controller entries. ClickClose.17.ClickNext on the Access Rule Destinations page.18

.Accept the default setting, All Users, on the User Sets page and clickNext.19.ClickFinish on the Completing the New Access RuleWizard page.

Create Access Rules Controlling Outbound Access from the

Back-end ISA Firewalls Default Internal Network to the

DMZ and the Internet

Clients on the corporate network behind the back-end ISA firewall require access to both the

Internet and perhaps the DMZ Network. Your access policy on a live network will be highlycustomized based on the principle of least privilege; so that users are allowed access to protocols

and locations they require access in order to complete their work.

In the example network used in this article series, Im going to create a simple outbound accesspolicy that allows all hosts on the corporate network outbound access to all resources on the

DMZ and the Internet. While you would never create such a rule on a production network, wecan do this to simplify things a bit to demonstrate the principles we want to demonstrate in this

article.

Perform the following steps to create the Access Rule:

1. At the back-end ISA firewall, in the ISA firewall console expand the name of the serverand then click the Firewall Policy node in the left pane of the console.

2. Click the Create New Access Rule link on the Tasks tab in the Task Pane.3. In the Welcome to the New Access Rule dialog box, enter a name for the rule in the

Access Rule name text box. In this example well name the rule All Open Internal to

DMZ/External. ClickNext.4. On the Rule Action page, select the Allow option and clickNext.5. On the Protocols page, select the All outbound traffic option from the This rule applies

to list and clickNext.

6. On the Access Rule Sources page, click the Add button.7. In the Add Network Entities dialog box, click the Networks folder and double click the

Internal entry. ClickClose.

8. ClickNext on the Access Rule Sources page.9. On the Access Rule Destinations page, click the Add button.10.In the Add Network Entities dialog box, click the Networks folder. Double click both

the DMZ and External Networks. ClickClose.11.ClickNext on the Access Rule Destinations page.12.On the User Sets page, accept the default entry, All Users, and clickNext.13.ClickFinish on the Completing the New Access Rule Wizard page.14.ClickApply to save the changes and update the firewall policy.


16/28

15.ClickOKin the Apply New Configuration dialog box.

Configure a Routing Table Entry on the DMZ Server

The default gateway on the DMZ Web server must be set for the internal interface of the front-end ISA firewall because the Web server needs to respond to connections from Internet hosts. In

addition, the Web server may need to initiate connections to Internet hosts, such as the MicrosoftUpdate Site. Note that this isnt a hard and fast requirement, because if the Web server in the

DMZ doesnt need to initiate connections to Internet hosts, and you configure publishing rules onthe front-end ISA firewall to replace the source IP address with the IP address of the ISA

firewall, then you could get away with not making the default gateway on the DMZ Web serverthe front-end ISA firewalls internal interface.

At the DMZ server, open a command prompt and enter the following:

route add p 10.0.0.0 MASK 255.255.255.0 10.0.1.2

Where 10.0.0.0 is the network ID for the corporate network behind the ISA firewall,255.255.255.0 is the subnet mask for that network ID, and 10.0.1.2 is the IP address on the

external interface of the back-end ISA firewall.

The figure below shows an example of configuring the routing table entry.

Figure 1


17/28

Join the DMZ Server to the Domain Located on the Default

Internal Network behind the Back-end ISA Firewall

The next step is to join the DMZ Web server to the corporate network domain. A key factor here

is correct DNS configuration on the DMZ servers network interface. The DMZ Web server mustbe able to find the domain controller on the corporate network. For this reason, we will use the IP

address of the domain controller itself, which hosts an Active Directory integrated DNS server.

Perform the following steps to join the server to the domain (the procedure will vary with the OSthe server is running; in this example the DMZ Web server is running Windows 2000).

1. On the DMZ Web server, right click the My Computer icon on the desktop and clickProperties.

2. In the System Properties dialog box, click the Network Identification tab.3. On the Network Identification tab, click the Propertiesbutton.4.

In the Identification

C

hanges dialog box, select the Domain option and enter the FQDNfor your domain. In this example, the corporate domain name is msfirewall.orgso I will

enter that name into the text box. Enter domain admin credentials in the authenticationdialog box. ClickOKin the dialog box welcoming you to the domain. ClickOKin the

dialog box informing you that you must reboot your computer.5. ClickOKin the System Properties dialog box.6. ClickYes to restart your computer.

Configure the Front-end ISA Firewalls Default Internal

Network

When the front-end ISA firewall was installed, it took its definition from the routing table on the

front-end ISA firewall device. The routing table entries indicated to the ISA firewall installer thatthe addresses 10.0.1.0-10.0.1.255 should be included in the definition of the default Internal

Network. This is a correct configuration if the only network behind the front-end ISA firewallwas on network ID 10.0.1.0/24. However, in our scenario this is an incorrect configuration and

will cause problems with access control through the front-end ISA firewall.

The reason for the problem with the initial settings for the default Internal Network on the front-end ISA firewall is that there is a Route relationship between the DMZ network (which is the

front-end ISA firewalls default Internal Network) and the default Internal Network behind theback-end ISA firewall. Because there is a route relationship, connections from SecureNAT

clients located behind the back-end ISA firewall will reach the front-end ISA firewall with theiroriginal client IP address included as the source address (this is not the case with proxied

connections by Winsock [Firewall] and Web proxy clients). If we leave the front-end ISAfirewalls default Internal Network definition as it is now, then connections from SecureNAT

client located behind the back-end ISA firewall will be detected as spoofed packets.

The reason for this is that ISA firewall Networks are used to determine the validity ofconnections reaching the interface that is the root of a particular ISA firewall Network. For the


18/28

front-end ISA firewall, the root of the default Internal Network is the internal interface which is

on network ID 10.0.1.0/24. Any connections with a source IP address on that network ID are seenas valid. However, if a connection with a source IP address that is not part of the default Internal

Networks definition is made through the interface that is the root of the front-end ISA firewallsdefault Internal Network (which is the internal interface of the front-end ISA firewall), then the

connection is dropped as a spoof attempt, since the ISA firewall assumes that it's not possible foran interface to accept a connection from a host on a Network that isnt the same as that for which

the interface is root.

We can easily solve this problem by adding the IP addresses included in the back-end ISAfirewalls default Internal Network to the definition of the front-end ISA firewalls default

Internal Network definition.

Perform the following steps to add the IP addresses of the back-end ISA firewalls defaultInternal Network to the definition of the front-end ISA firewalls default Internal Network:

1.

In the ISA firewall console, expand the server name and then expand theC

onfigurationnode. Click on the Networks node.

2. On the Networks node, click the Networks tab in the details pane, then double click theInternal Network.

3. In the Internal Properties dialog box, click the Addresses tab.4. On the Addresses tab, click the Add button.5. In the IP Address Range Properties dialog box, enter the Starting address and the

Ending address in the text boxes. In this example well enter10.0.0.0 and 10.0.0.255,

respectively. ClickOK.


19/28

Figure 2

6. ClickOKin the Internal Properties dialog box.


20/28

Figure 3

Configure a Routing Table Entry on the Front-end ISAFirewall

Like the situation with the DMZ Web server, you need to configure a routing table entry on the

front-end ISA firewall that will enable it to know the route to the default Internal Networklocated behind the back-end ISA firewall. Perform the same procedure you did on the DMZ Web

server to create the routing table entry providing the route to the default Internal Network behindthe back-end ISA firewall.

Create an All Open Access Rule on the Front-end ISA

Firewall

In the example discussed in this article, we will create an All Open access rule on the front-endISA firewall allowing all traffic outbound from the default Internal Network to External. Im

using this only to keep the scenario simple so that we can focus on main thrust of this article,which is DMZ configuration. This is notwhat I would recommend you do in a production

environment.


21/28

What would I do in a production environment? Some things I would consider include:

y Allow outbound access through the front-end ISA firewall only for DMZ hosts that needto initiate new connections.

y Not allow outbound access through the front-end ISA firewall for published servers on theDMZ and on the corporate network behind the back-end ISA firewall who do not need tomake new outbound connections to the Internet

y Allow outbound connections for all protocols from the primary IP address on the externalinterface of the back-end ISA firewall. This is the IP address that will be presented to the

front-end ISA firewall for Web proxy and Firewall client located behind the back-end ISAfirewall

These are just some very high level considerations, and outbound access requirements though the

front-end ISA firewall will vary with the nature of communications allowed to and from theDMZ segment, as well as the internal networks located behind the back-end ISA firewall

Perform the following steps to create the All Open outbound access rule on the front-end ISAfirewall:

1. At the front-end ISA firewall, in the ISA firewall console expand the name of the serverand then click the Firewall Policy node in the left pane of the console.

2. Click the Create New Access Rule link on the Tasks tab in the Task Pane.3. In the Welcome to the New Access Rule dialog box, enter a name for the rule in the

Access Rule name text box. In this example well name the rule All Open Outbound.

ClickNext.4. On the Rule Action page, select the Allow option and clickNext.5. On the Protocols page, select the All outbound traffic option from the This rule applies

to list and clickNext.

6. On the Access Rule Sources page, click the Add button.7. In the Add Network Entities dialog box, click the Networks folder and double click the

Internal entry. ClickClose.8. ClickNext on the Access Rule Sources page.9. On the Access Rule Destinations page, click the Add button.10.In the Add Network Entities dialog box, click the Networks folder. Double click the

External Network. ClickClose.11.ClickNext on the Access Rule Destinations page.12.On the User Sets page, accept the default entry, All Users, and clickNext.13.ClickFinish on the Completing the New Access RuleWizard page.14.ClickApply to save the changes and update the firewall policy.15.ClickOKin the Apply New Configuration dialog box.

Have Questions about the article?

Ask at: http://tinyurl.com/qxpsn


22/28

Create a Web Publishing Rule on the Front-end ISA

Firewall

Now well create a Web Publishing Rule to test the solution. The Web Publishing Rule will be a

simple one and will not require authentication at the ISA firewall. The only authentication thatwill be required will be at the Web site itself. Again, in a production environment, I recommend

that if you require authentication at the Web server in the DMZ, you should enhance security byemploying pre-authentication at the ISA firewall. However, if the front-end ISA firewall is not a

member of the same domain as the published Web server, or if the user accounts are not mirroredon the front-end ISA firewall, then the user will be challenged for authentication twice: once by

the front-end ISA firewall and once at the Web site itself.

We will create a Web Publishing Rule that allows users who enter the URL

http://dmzweb.msfirewall.org access to the Web server in the DMZ. If you want to replicate

this configuration, you should make a HOSTS file entry on the front-end ISA firewall that mapsthe public name of the DMZ Web server to the IP address of the Web server in the DMZ. In

addition, the public DNS must contain a Host (A) record for the server that maps to the IPaddress on the external interface of the front-end ISA firewall.

Perform the following steps to create the Web Publishing Rule:

1. In the ISA firewall console, expand the server name and then click the Firewall Policynode.

2. On the Firewall Policy node, click the Tasks tab on the Task Pane and then click thePublish a Web Server link.

3. On the Welcome to the New Web Publishing Rule Wizard page, enter a name for theWeb Publishing Rule in the Web Publishing Rule name text box. In this example, well

name the rule Publish DMZ Server. ClickNext.4. On the Select Rule Action page, select the Allow option and clickNext.5. On the Define Website to Publish page, enter the name of the DMZ Web server in the

Computer name or IP address text box. Remember, the ISA firewall must be able toresolve this name to the actual IP address of the DMZ Web server on the DMZ Network.We will allow access to all folders on this site, so enter a /* in the Path text box. It's

usually a good idea to forward the original host header, since this enables manyapplications that perform server side scripting to work correctly. ClickNext.


23/28

Figure 4

6. On the Public Name Details page, select the This domain name (type below) optionfrom the Accept requests for drop down list. In the Public name text box, enter thename that external users will use to access the site. In this example, external users will use

the name dmzweb.msfirewall.org to access the site so we will enter that value. We wantto allow access to all folders on the site, so we will leave the Path (optional) setting at the

default (which is based on the path setting we specified on the previous page in theWizard). ClickNext.


24/28

Figure 5

7. On the Select Web Listener page, click the New button.8. On the Welcome to the New Web ListenerWizard page, enter a name for the Web

Listener. In this example well name the listenerHTTP Listener. ClickNext.

9. On the IP Addresses page, put a checkmark in the External checkbox and clickNext.


25/28

Figure 6

10.Accept the default settings on the Port Specification page and clickNext.11.ClickFinish on the Completing the New Web ListenerWizard page.12.ClickNext on the Select Web Listener page.13.Accept the default setting on the User Sets page and clickNext.14.ClickFinish on the Completing the New Web Publishing Rule Wizard page.15.ClickApply to save the changes and update the firewall policy.16.ClickOKin the Apply New Configuration dialog box.

Test the Solution

Lets test the configuration. On a host on the External Network, make a connection to thepublished Web server. In this example, well connect to http://dmzweb.msfirewall.org. You

should see a single log on dialog box. Enter your credentials and youll see the home page for thesite. Table 1 below shows a sample of log file entries on the front-end ISA firewall related to the

connection attempt.


26/28

Table 1: Log file entries related to the external client connection to the published Web server inthe DMZ (Click Table to Enlarge)

Table 2 shows a sample of log file entries related to the intradomain communications between theDMZ Web server and the domain controller on the corporate network.


27/28


28/28

Table 2: Intradomain communications between the DMZ Web server and the domain controlleron the corporate network behind the back-end ISA firewall (Click Table to Enlarge)

Documents

DMZs Morph Into Security Perimeters