Version 1.5,
Revision 1
Chapter 3
Firewall Design
Reference Architecture Guide
Abstract
This chapter describes the Microsoft®
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This documentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESSED OR IMPLIED, IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2002 Microsoft Corporation. All rights reserved. Microsoft, Windows,
Windows NT, Active Directory, BizTalk, JScript, and Visual Basic are either
registered trademarks or trademarks of Microsoft Corporation in the
Other product and company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation
1001
Contents |
Introduction.............................................................................
1
Common Firewall
Functionality
1
Packet
Filtering Firewalls
1
Proxy
Servers
2
Circuit-level
Gateways
2
Stateful
Packet Inspection
3
Other
Considerations
3
Network
Address Translation
4
Port Address
Translation
4
NATed vs
Screened
4
Internet Data
Center Firewall Overview
4
Basic TCP/IP
Flow
7
ISA Server
Filtering Methods
8
Packet
Filtering
8
Stateful
Inspection Filtering
8
Application
Layer Filtering
10
Perimeter
Firewall and Caching Design..................... 11
ISA Server
Configuration
11
Hardware
Requirements
11
Service Packs
and Hot Fixes
12
Multihomed
12
Static
Routes
13
LAT
Configuration
13
Web
Publishing
13
Load
Balancing Design
14
There is no
added benefit for implementing DNS round robin for web publishing multiple IIS
cluster farms in which they all participate within the same web site since each
ISA server can manage balancing requests to each IIS cluster by using a host
file.
15
Controlling
Incoming Requests
15
SSL
Configuration
16
Reverse
Caching
17
Server
Publishing
17
IP
Configuration
18
Secure NAT
Clients for Server Publishing
19
Securing the
Perimeter ISA Server Firewalls
20
Internal
Firewall Design..................................................
21
Basic
Requirements
21
Traffic
Requirements
21
Windows 2000
RPC Port Configuration
22
ISA Server Design
Requirements
23
Network
Configuration
23
Publishing
Domain Traffic Through ISA
23
Disabling
NetBIOS
24
DNS
Design
24
VPN
Firewall Design.............................................................
26
IP Addresses
26
ISA Server
Configuration
27
ISA VPN
Wizard
27
Packet
Filters
27
RRAS
Configuration
28
VPN Protocols
28
Certificate
Services
29
RRAS Server
Configuration
30
Remote-Access
Policy
30
Remote-Access
Logging
30
High
Availability Firewall Design................................ 31
Using the Network
Load Balancing Service with ISA Server
31
Port
Rules
31
Third-Party
Solutions
32
Summary....................................................................................
33
More
Information
33
The Microsoft®
Before we dive into the firewall design details, lets first set the stage by defining various firewall features as these will impact firewall selection options. Subsequent sections will examine the implementation specific details for these firewall options.
The firewall functionality definition found at the beginning of this chapter a is a good high level description. However, the implementation details of how this control over traffic is defined and implemented varies from vendor to vendor and product to product. While vendor specific firewall implementation can combine some or all of the features described below, in general there are four types of firewall devices:
· Packet filtering firewalls
· Application-level gateways, a.k.a. proxy servers
· Circuit-level gateways
· Stateful packet inspection (SPI) firewalls
Packet filtering firewalls provide security by having to explicitly define the allowed traffic across the device. This means that each connection type needs to be defined on the packet filtering firewall in order for the communication to succeed. Packet filters can base their forwarding decisions on the protocol type (i.e. GRE, UDP, TCP ICMP to name a few), source/destination IP address or IP network (collection of IP addresses), source/destination ports or combination of any of these parameters. Some of the advantages of packet filtering are:
· Less overhead than SPI (see below)
· Low cost
· Granular traffic control
Some of the drawbacks of packet filtering firewalls are:
· No user authentication
· No visibility beyond protocol/ports
· Vulnerable to IP spoofing
For a more detailed discussion of the packet filtering, see the Basic TCP/IP Flow section below.
Application gateways provide security by requiring the clients to submit all requests for access to outside resources to the proxy server. This server then proxies the request to the intended Internet resource. Clearly, for client applications to take advantage of the proxy functionality they must be proxy aware so that they know where to send their requests. The most commonly encountered application gateway is the web proxy. Most of the popular web browsers are proxy aware and therefore able to take advantage of this architecture. Since all traffic is proxied via proxy server, this provides enhanced security. Note that each type of connection to Internet resources results in the establishment of two connections: one from the client to the proxy and a second from the proxy to the Internet resource. This means that clients are never directly in communication with Internet resources. Some of the advantages of proxy servers are:
· The architectures intrinsically enhanced security
· User or group-based authentication and access control
· Traffic logging
· Caching
Some of the disadvantages of a proxy server are:
· The need for applications to be proxy aware
· The need for proxy configuration on the client
· Not all Internet applications are proxy aware
Although proxy servers can provide enhanced security, a major drawback is their lack of transparency. This not an issue when dealing with a well-defined set of applications which support proxies. However, some obscure applications do not support proxies and therefore will not work. In such cases, circuit-level proxies can provide a solution. As the name implies, circuit-level proxy functionality is not based on a proxy server understanding different protocols and how to handle them. Instead, it establishes connections for internal clients to Internet hosts on the clients behalf. As with application proxy functionality, two connections are established. However, this happens at the connection level instead of at the application level. An example of a circuit-level proxy is the WINSOCK implementation on the WIN32 platform.
For applications to be circuit-level gateway compatible, they need to leverage platform-specific APIs to establish connections. For Windows applications to leverage this, they need to use WINSOCK Application Programming Interfaces (API) to establish external connections. Circuit-level gateway functionality also requires client-side software deployment. Some of the advantages of circuit-level gateways are:
· Compatibility with any application using the WINSOCK API this includes many WIN32 applications.
· The architectures intrinsically enhanced security
· User or group-based authentication and access control
· Traffic logging
· Support for more complex communication requirements (callbacks, etc.)
Some of the disadvantages are:
· The need for client deployment
· Lack of compatibility with applications which do not use platform APIs
· Permit access for more complex applications and hence more complex security
The more recent class of
firewall devices support
· An enhanced understanding of the connection state through use of established connection table to reduce the likelihood of packet spoofing
· The ability to examine packets based on a specific understanding of the common protocol utilized, such as SMTP or NNTP
SPI firewalls are more intelligent and provide enhanced security. However, the protocol-specific functionality may not be as extensive as that provided by a proxy server. This drawback is offset by the greater throughput of such devices in comparison to classical proxy servers.
In addition to the four classes of firewalls defined above, there are other important features that need to be understood for proper solution selection. These are:
· Network Address Translation - NAT (Static/Dynamic)
· Port Address Translation PAT (Static/Dynamic)
· Screened vs. NATed subnets and hosts
Next we examine each and their implications for IDC design.
NAT is a very common feature of nearly all firewall devices today. NAT allows the firewall devices to obscure the internal clients IP addresses. This is often required as many of the internal networks today utilize reserved private IP address ranges which are not routable on the Internet. NAT functionality can be either static or dynamic depending on the implementation. Static simply refers to the predetermined mapping between the internal non-routable IP addresses and the external public addresses. Dynamic mapping is determined at the time client is making a connection. Proxy servers by default perform NAT so that to the Internet resource, the requests are coming from the proxy servers IP address.
PAT provides very similar functionality to NAT, but as name suggests, the translation is port-based rather than IP address-based.
One other significant consideration for IDC Firewall design deals with how the firewall protects its clients. Certain protocols such as Kerberos and IPSec encapsulate the source and destination addresses of the interacting hosts in the packet payload. Since such a payload is encrypted, an intermediate device such as a firewall would need to understand these protocols in order to make the necessary IP addressing modifications to the payload. To accomplish this, the intermediate device would need to decrypt the packet, modify it, and encrypt it again. However, doing so would violate the very principle on which such enhanced security is based: only the source and destination hosts should be privy to the data sent between them. Even if this anomaly were allowed, the overhead incurred would cause an unacceptable degradation in performance in even the fastest firewall devices. For the situations where protocols such as Kerberos or IPSec are used, it is required to use routing firewalls. This routing is not indiscriminate, like the default router behavior, instead the security rules need to be clearly defined to allow such routing of traffic between interfaces to occur, thus creating screened network or protected network. It should be noted that the current Microsoft implementation of IPSec does work with either configuration.
The application and management
requirements for the
The perimeter firewall and
switch create the demilitarized zone, or DMZ VLAN, and provide greater
protection by controlling the traffic that comes in from the Internet and the
traffic between servers in the DMZ VLAN. The internal firewall inspects traffic
between the servers in the DMZ and the infrastructure and back-end systems. The
VPN firewall manages the remote communications requirements for both the remote
management of the IDC and for applications required for Web site development. A
fully redundant firewall solution is implemented for the architecture to ensure
high availability. The following figure shows the
Figure 1.
Firewall placement in the
Each of the three firewalls is described in detail in this chapter, with the final section describing options for achieving high availability.
Microsoft Internet Security Acceleration (ISA) Server or firewall
solutions from other vendors can be used for any of the firewalls in the
Feature\Firewall |
Perimeter |
Internal |
VPN |
Packet Filtering |
Must have |
Must have |
Must have |
Proxy |
Desired for enhanced security. Can provide reverse caching (ISA). |
May cause problems with protocols embedding source/destination into packet payload. IPSec/Kerberos. |
Not required, since no traffic should traverse except
VPN. |
Circuit-level |
Nice to have. May be required depending on application requirements. |
May cause problems with protocols embedding source/destination into packet payload. IPSec/Kerberos. |
Not Required. |
SPI |
Must have. |
Must have. |
Must have. |
NAT/PAT |
Desired for enhanced security. Required for server
publishing (ISA). |
May cause problems with protocols embedding
source/destination into packet payload. IPSec/Kerberos. |
Must have. IPSec/L2TP will not work. |
Table 1. Firewall feature requirements by firewall type
To demonstrate the flexibility
of the
This section describes
how TCP/IP packages its information, to show how firewalls handle traffic
securely. Packet filtering is based on information in the TCP/IP packets. The
following figure shows a simple breakdown of an IP packet with its three key sections:
the IP Header, the TCP or UDP header, and the actual contents of the packet.
(Whether T CP or UDP is used depends on the application-level protocol: HTTP,
for example, uses TCP.) The IP header contains the IP addresses of the source,
which is the sender, and the destination, which is the receiver. The TCP or UDP header
contains the source port of the sender and the destination port of the receiver,
in addition to other information, such as sequence numbers, acknowledgement
numbers, and the conversation state. The destination TCP or UDP ports define the
locations for delivery of the data on the server when the packet reaches its
destination. The source port is the port from which the sender sends the packet
and is also the port that the destination server responds to in a conversation.
The destination port is the port from which the destination server listens and
responds to sender requests.
Figure 2. IP Packet structure
It is important to
appreciate the communication flow of a TCP/IP conversation when configuring the
firewall. When a browser, for example, sends an HTTP request to a Web server,
the request contains the identity of the client computer, the source IP address,
and the source port that the request went out on. This is also the port from
which the client will receive a response from the Web server. The source port
for a client of this type is typically a value greater than 1024 (that is, not a
part of the well-known range of TCP ports). In addition, the client request
contains the destination IP address and destination port of the Web server, in
this case port 80, the standard HTTP port.
ISA Server supports
three layers of filtering for comprehensive security: packet filtering, stateful
inspection, and application-level filtering. By default, ISA Server blocks all
inbound traffic on its external interface and does not allow any traffic through
unless rules are created to allow it. The following sections describe the three
different layers of filtering that ISA Server supports.
Packet filtering is
the process of statically opening certain ICMP, TCP, or UDP ports on the
firewalls external interface and determining where to route them internally. In
the
· Source IP addresses
· Destination IP addresses
· IP protocol
· Source TCP and UDP ports
· Destination TCP and UDP ports
· The interface where the packet arrives
· The interface to which the packet must be delivered
Stateful inspection
is the process of inspecting packets as they reach the firewall and maintaining
the state of the connection by allowing or disallowing packets to pass based on
the access policy. To further understand how state is maintained, the following
figure shows how a conversation between a client and a server takes place
through the ISA Server computer. In this scenario, Web Publishing has been configured on the
ISA Server computer to support redirecting external Internet requests on port 80
to the internal IIS server.
Figure 3. Sample conversation through ISA Server
This is the flow of
the conversation:
1. The Internet client initiates an HTTP request to the Web server and sends an IP packet with the source and destination address and ports.
2. The ISA Server computer receives the request for the Web server.
3. ISA Server then modifies the packet, replacing the source address and port with its own internal address, and changes the destination IP address to the address of the real IIS server.
4. ISA Server adds the source and destination ports and addresses into its own table to keep track of the conversation.
5. ISA Server sends the modified packet to the internal IIS server.
6.
The IIS server
responds to the request by using ISA Server as the destination address and
7. ISA Server receives the packet from the IIS server and looks in its table for 5300, which maps to the Internet client.
8. ISA Server then modifies the packet and replaces the IIS servers source IP address and port with its own source IP and port.
9. ISA Server then changes the destination IP address and TCP port to that of the Internet client.
10. The Internet client listens for a response on TCP port 5100.
In addition to
maintaining the TCP or UDP conversation based on IP addresses and ports, ISA
Server also checks the TCP flags, the sequence and acknowledgement numbers
within the TCP header fields for TCP conversations. The flags represent the
state of the conversation, whether it is the beginning of a conversation (SYN),
the middle of a conversation (ACK), or the end of the conversation (FIN). If any
of the flags are out of sequence, ISA Server blocks the connection. The sequence
and acknowledgement fields provide the information to ensure that the next
packet received in the conversation is the correct one. Once again any request
that does not fit the state of the conversation is blocked.
ISA Server is also an application-level proxy that is able to read data within packets for a particular application and perform an action based on a rule set. In addition, ISA Server comes with pre-defined application filters that inspect each packet and block, redirect, or modify the data within the packet. For instance, Web-routing rules can be implemented that tell the ISA Server computer to redirect an HTTP request to a certain internal IIS server, based on the URL in the packet. Another example is the DNS intrusion-detection filter. This filter blocks packets that are not valid DNS requests, or that fit common types of DNS attack. Application filtering can be invoked on ISA Server when Web Publishing or Server Publishing is configured.
Microsoft ISA Server
2000 as used in the
For the perimeter ISA
Server computers, the Network Load Balancing Service is used to configure load
balancing on the external interfaces from the Internet Web Publishing IIS
servers benefit from this configuration, in which the virtual IP address can be
used. The perimeter ISA Server computers also use a configuration called Server
Publishing to support applications other than IIS, such as external DNS or SMTP
servers. The DNS servers are configured as round-robin DNS to provide redundancy
for these application services.
Two ISA Server
computers are deployed on the perimeter network in the
Both ISA Server
computers are configured in stand-alone mode. This configuration means that
additional servers are not required if your implementation of the
Each ISA Server computer is configured for integrated mode to support both firewall and caching architectures. Reverse caching provides better response times to Internet clients and reduces network traffic.
The following hardware requirements are recommended for the perimeter ISA Server computers in a high-end solution. Each ISA Server computer that is deployed in the perimeter manages the firewall rules, implements reverse caching for Internet clients, and offloads Secure Sockets Layer (SSL) from the IIS servers. Based on the ISA Server computers role, a high-end server should at least meet the following minimum requirements:
· 2 processors
· 2 gigabytes (GB) RAM
· 1 set of mirrored drives to support the operating system and caching or a second set of mirrored drives to support only caching for improved performance
· Multiple 100-MB Full Duplex Ethernet cards (based on network configuration)
Before the ISA Server computers are configured, the latest service pack, plus all important operating system postService Pack hot fixes, must be applied to each server and tested.
Note: ISA Server hot fixes must be applied after the ISA Server installation is completed on each server.
All ISA Server computers are multihomed. The external NIC connects directly to the Internet-facing routers, and the internal NICs connect to the internal VLAN allowing ISA Server to contact the servers in the DMZ with private addresses. (See Figure 4.) Multiple VLANs are created in the DMZ, with ISA Server internal NICs and any Server Publishing servers, such as external DNS servers, all grouped on the same VLAN 21. The IIS server farms are on VLAN 22 and VLAN 23.
Figure 4. ISA Server multihoming and VLAN configuration
Note: For clarity the redundant nature of all network
connections has been left out of the figures in this chapter.
In the
Before firewall rules
can be configured, the ISA Server computer must be able to detect which
interface is connected to the public Internet, and which is connected to the
private networks, including all private networks that the ISA Server computer
needs to communicate with internally. All of this information is maintained in
the ISA Server local address table (LAT). The LAT configuration tells the ISA
Server computer where all of the internal networks are located. In a dual NIC
implementation, when one NIC is designated as private based on
the LAT, the other is then assumed to be public. ISA
Server can construct the LAT table automatically based on information in the
Microsoft Windows® 2000 routing table, or networks can be added manually.
In the
Web Publishing allows the perimeter ISA Server computers to impersonate an internal Web server to the outside world. This provides a highly secure mechanism for controlling inbound Web requests. In addition, transparent caching mechanisms of ISA Server can actively cache frequently requested objects, which improves performance and reduces traffic on the DMZ network.
When Web Publishing is
implemented, external client requests for Web services are directed
via
external DNS entries to the external virtual IP address of the load-balanced ISA
Server farm. These requests are then processed by ISA Server, based on Web
Publishing rules, and are redirected to the appropriate internal Web server
farm. These rules consist of policy elements, including the following:
· Destination Sets. For Web Publishing, a destination set is typically the domain name contained in a URL whose IP address is the external address of the ISA Server computer. Advanced URL redirection can be implemented through the path functionality of destination sets. The perimeter ISA Server array can be configured to publish Web content split across several Web servers or load-balanced Web server farms.
· Actions. Actions determine how ISA Server processes external client requests for a particular destination. ISA Server can discard the request or redirect the request to an internal Web server. In addition, ISA Server can translate ports when connecting to internal HTTP, SSL, or FTP resources, and pass host header information. ISA Server can redirect these requests according to the IP address or Fully Qualified Domain Name (FQDN).
· Bridging. ISA Server can redirect HTTP and SSL requests as HTTP, SSL, or FTP requests and can require a secure channel for the published site. Because ISA Server acts as a proxy for published SSL requests, a valid certificate must be installed on the ISA Server computer.
· Secure Sockets Layer (SSL) Bridging. Because ISA Server offers a true application-proxy solution, special considerations must be made when implementing certificate-based traffic. ISA Server has built-in functionality to support SSL bridging. SSL allows the ISA Server to encrypt and decode a client request and pass on the request to a destination Web server. This requires that appropriate certificates be installed on the computer running ISA Server.
· Host Header Bridging. When multiple Web sites are published from a single IP address on an internal Web server, the Web Publishing rules on the perimeter ISA Server array can be configured to send original host header information.
·
Client Sets. Addresses of external Internet clients can
be configured to allow or deny access to the Web-server farm. When client sets
are not implemented for Web Publishing in the
Before any Web
Publishing rules are created, the ISA Server computers and the IIS Web servers
are configured for load balancing. Network Load Balancing is installed and
configured on the external interface of both ISA Server perimeter servers to
provide a redundant solution. In addition, the internal IIS servers are grouped
into two different Network Load Balancing clusters, each of which is assigned an
internal virtual IP address. For more information on the Network Load Balancing
implementation in the
High availability is maintained throughout the web publishing design using a combination of network load balancing on the ISA Servers and internal web servers in addition to the way that ISA Server redirects traffic to multiple load balanced IIS Server farms. A host entry is added to each ISA servers host file using a host name of iiscluster and assigning the two internal IIS cluster virtual IP addresses to the host name as follows:
192.168.22.20 iiscluster
192.168.23.21 iiscluster
A web publishing rule is created to look for the URL *.northwindtraders.com and is configured to redirect the request to the host name iiscluster. Since there are two IP addresses assigned to this host name, ISA Server will apply a random number algorithm to select one of the IP addresses assigned to iiscluster and redirect the external request to the internal IIS Cluster farm assigned to that address that was chosen. ISA Server will apply the random number algorithm on each external request that is processed with this specific web publishing rule. Additional web publishing rules were created to allow administrators to be able to specifically route a web request from the internet to each internal IIS web farm by using the public virtual IP address assigned the ISA Servers within the URL. The following figure shows this configuration:
Figure 5. ISA Server load-balancing configuration
Incoming Web requests are configured by setting up listeners on the external network interface of the ISA Server computers. The listener tells the ISA Server which external IP addresses to monitor and accept incoming HTTP and HTTPS traffic. Each load-balanced ISA Server computer is configured to use individual IP addresses, effectively listening on port 80 for each IP address defined in the incoming Web request dialog box. Both ISA Server computers are configured to detect incoming requests on 208.217.208.182 and 208.217.208.183. Any inbound requests on port 80 for any of these IP addresses are processed according to Web Publishing rules, routing rules and IP packet filter rules. If these listeners are not defined, ISA Server does not process any external Web requests.
SSL bridging provides
a secure, fully redundant, and load-balanced SSL connection between Internet
clients and the internal IIS server farms. Bridging means that a client
establishes an SSL connection to the ISA Server computer, and then the ISA
Server computer can either establish a new SSL connection to the internal Web
servers, redirect the client request using HTTP to the Web server, or redirect
using FTP. In the
This configuration allows the following:
· The overhead of SSL can be offloaded from the IIS servers to the ISA Server computers. Based on the performance requirements, the SSL processing can also be offloaded from the server CPU by installing hardware accelerator cards.
· The payload packets can be examined by the ISA Server computers to check for any vulnerable attacks before the packets are delivered to the IIS servers.
· SSL can work correctly with Network Load Balancing. The IIS servers are configured as Network Load Balancing clusters and are then set for single affinity. This allows incoming SSL requests to always go to the same internal IIS server. If this were not the case, every request could be load balanced to a different server. This would add additional overhead in re-establishing an SSL connection each time. Single affinity checks only the source IP address. Because the ISA Server computer is performing Network Address Translation (NAT), the source IP will always be the ISA Server computers internal IP address, and all requests on the ISA Server computer will always go to the same internal IIS server.
Figure 6. SSL configuration
To support SSL traffic on the ISA Server computers, the computers are configured to detect SSL requests and a certificate is installed on each server. Each Web Publishing rule is updated to bridge the incoming SSL packet by using HTTP to the internal IIS server farm. The certificate that is installed uses a Trusted Root Certificate Authority (CA) that all clients trust. The common name of the certificate should match both the incoming request sent by the Internet client and the name used in the destination set.
Note: Some sites may want to support SSL traffic through ISA Server directly to the internal SSL server. This can be supported by implementing Server Publishing.
Another benefit that the perimeter ISA Server computers provide for the Internet site is the ability to cache the static content of the internal IIS servers. This transparent caching mechanism is called reverse caching. By using ISA Server caching features along with incoming Web requests, ISA Server can impersonate an internal Web server to the outside world and fulfill client requests for Web content from its cache. This reverse-caching solution provides better response times to Internet clients and decreases the traffic on the DMZ network.
The Web Proxy service of ISA Server keeps a cache of objects and attempts to fulfill Web requests from the cache. Much of the content in the cache is stored in memory, using a lazy-write mechanism to write the cache contents to disk. This provides increased performance to the external client and has the added security benefit of reducing the amount of traffic that traverses the DMZ. For additional performance, the cache solution can be configured on a different disk than that used for the ISA Server executables.
For the
The
ISA Server listens for the protocol and port that has been configured in the Server Publishing rule. When a request comes in that matches the rule, ISA Server redirects the IP packet to the internal server. For instance, you can create a Server Publishing rule for an internal DNS server that will tell ISA Server to listen on its external interface for UDP port 53 (DNS query) and to redirect the request to the internal DNS server's private address, 192.168.21.50. Before ISA Server redirects the request, application filters, such as the DNS filter, can be invoked so that ISA Server can examine the contents of the data in the packet and determine if it is suspicious and, therefore, reject the packet before the internal server receives it.
Server Publishing is configured slightly differently from Web Publishing in the following ways:
· The TCP/IP packets are handled differently from ISA Server when Server Publishing rules are used. When a request comes in from an Internet client, the source IP and source port that are contained in the original IP packet are not replaced by the ISA Server computer and are included in the IP packet that is redirected to the internal server. Using Web Publishing rules, ISA Server replaces the Internet client source IP and port with the ISA Server computers internal IP address and a new port number.
· Network Load Balancing cannot be implemented for Server Publishing. (Currently, either a hardware load balance solution or a third-party software load-balance solution must be implemented in order to successfully load balance server publishing today). The Network Load Balancing configuration that is implemented for Web Publishing using the external virtual IP addresses cannot be used for Server Publishing. Instead, the dedicated external IP addresses on each ISA Server computer are used for Server Publishing.
For these reasons,
the published internal servers IP configuration will be different from the IIS
server's IP configuration. In the
Figure 7. IP configuration for server publishing
Each pair of application servers is split across each ISA Server for redundancy in support of round-robin DNS. Each application server has two registered IP addresses in DNS, which are the dedicated IP addresses assigned to the external interface of each ISA Server computer (208.217.184.180 and 208.217.184.181). Internet clients reference these addresses to access these services. The virtual IP addresses assigned for the load-balancing ISA Server computers are used for the Web Publishing rules. A session that flows through the ISA Server computers to the internal server must be returned through the same ISA Server computer; otherwise, a firewall rule would be broken. This is why the published servers point to ISA Server as their default gateway. For the IIS servers, ISA Server replaces the external source IP address with its own internal address, so that the internal IIS servers can easily respond back to the same ISA Server computer.
Secure NAT clients are simple to implement because they do not require that any additional software be loaded on the internal servers. One requirement for secure NAT is that the internal server must always respond to the ISA Server computer that redirected a request to it. For example, if a request comes from the Internet to ISA Server and ISA Server determines that the request needs to be redirected to an internal IIS server, the IIS server must respond through the same ISA Server computer that the request came from. This is not a problem for Web Publishing, because ISA Server performs NAT by changing the source IP address of the IP packet to its own internal address before it sends the redirected request to the internal IIS server. When the IIS server sees the request, it responds with the internal ISA Server address as the destination address in the IP packet. As long as the internal server IP settings are correctly configured and have the correct default gateway to allow the internal IIS server to respond to the ISA Server computer, the communication will be successful.
For reasons that were discussed earlier, it is important that the internal servers that are Server Published, such as DNS servers, have their default gateway configured to point to the ISA Sever that has publishing rules destined for that internal DNS server. Otherwise, the response from DNS will fail if traffic does not flow back through the same firewall that the request came through.
The ISA Server computers are the first in line to have direct contact with the Internet and should be appropriately secured. This process is often referred to as server hardening. A security template was created in order to automate applying security to both ISA Servers. This template performs the following:
· Remove the Admin directory shares
· Disable unnecessary services
· Restrict anonymous access
· Enforce complex passwords
· Configure the audit logs
Before security is implemented, the ISA Server computer should be completely backed up. Then the template can be applied to ISA by using the secedit command with the /config option from the command prompt. After the ISA Server computers are secure, each one should be rebooted multiple times and thoroughly tested.
This section
describes the general design requirements for the internal firewall in the
The internal firewall provides added protection for the servers that belong in the internal VLANs, such as the infrastructure and data/management VLANs. If one of the servers in the DMZ VLAN is compromised, the attacker would need to get through the internal firewall in order to do more damage. In addition, NetBIOS is required on the internal interface of the servers on VLAN 11 and the internal firewall protects the internal network servers by not allowing NetBIOS ports 137, 138, and 139 through its interface.
A redundant firewall solution that is highly available should be implemented for the internal firewall design.
Specific TCP and UDP
ports are required for communication between the servers in the DMZ network and
the servers in the internal network. All servers in the DMZ network are member
servers of the
Protocol Definition |
Port |
Protocol |
Notes |
Management (App Manager Agent) |
9979 9998 9999 +RPC |
TCP |
Required if servers in the front-end Web have the App Manager Agent installed and they forward to an internal management server. |
Management (Ops Manager Agent) |
1270 |
TCP |
Required if servers in the front-end Web have the Operations Manager Agent installed and are forwarding information to the internal management servers. |
Management ( |
4243 4244 |
TCP |
Required if an |
Management (Terminal Services) |
3389 |
TCP |
Allow administrators from management VPN network to access Terminal Services on all servers in the front-end Web. |
Application (SQL Server) |
1433 |
TCP |
All IIS servers have DNS entries that point to the virtual SQL Server clusters in VLAN 12. |
Application (Message Queuing) |
1801 |
TCP |
All IIS computers have Message Queuing installed and forward to internal the Message Queuing cluster server in VLAN 13. |
Infrastructure (Domain Kerberos) |
88 |
UDP |
DMZ servers that are members of the internal domain. |
Infrastructure (Domain NTP) |
123 |
UDP |
DMZ servers that are members of the internal domain. |
Infrastructure (Domain RPC Endpoint Mapper) |
135 |
TCP |
DMZ servers that are members of the internal domain. |
Infrastructure (Domain LDAP) |
389 |
TCP UDP |
DMZ servers that are members of the internal domain. |
Infrastructure (Domain SMB Direct Host) |
445 |
TCP |
DMZ servers that are members of the internal domain. |
Infrastructure (Domain NTDS) |
1026 |
TCP |
DMZ servers that are members of the internal domain. |
Table 2. Traffic requirements between DMZ and internal VLAN servers
Within the
These application ports can change each time the server is rebooted, which makes it more difficult to configure the firewall to support this type of traffic. To make RPC traffic firewall friendly, a specific range of ports should be used for this traffic. Doing so allows the firewall to open specific ranges of ports between VLANs. To configure this in Windows 2000, the following entries must be added to the registry:
Key: HKLM\SOFTWARE\Microsoft\RPC\Internet
Named Value: Ports
Type: REG_MULTI_SZ
Setting: Range of port. This can be multiple lines.
4001-4039
9001-9099
Named Value: PortsInternetAvailable
Type: REG_SZ
Setting: Y
Named Value: UseInternetPorts
Type: REG_SZ
Setting: Y
If ISA Server computers are used as the internal firewall solution, Server Publishing rules are configured in order to publish Active Directory directory service ports to the DMZ servers. Additional software or hardware load-balancing solutions must be implemented in front of and behind the internal ISA Server computers to provide a fully redundant and highly available solution. This configuration is sometimes referred to as a firewall sandwich.
The internal ISA firewall network design is a multihomed configuration just like the perimeter ISA firewall design, with the external interface connected to VLAN 11 and the internal interface connected to VLAN 15. Static routes were created on the internal interface to VLAN 12 and VLAN 13, using 192.168.15.253 as the default gateway. Traffic from the DMZ servers on VLAN 11 can only be proxy through the ISA server to the internal servers on VLAN 12 and VLAN 13.
ISA must be configured to listen for the TCP and UDP ports that are used for communication to the domain controllers and to publish them on its external interface on VLAN 11. In order to Server Publish the active directory ports on ISA Server, all of the TCP and UDP ports used for authentication, such as Kerberos and LDAP, must first be defined in the protocol-definition area of the ISA Server. A protocol definition defines the Port Number, IP Protocol used (TCP or UDP), and Direction (Inbound or Outbound for TCP Send Only, Receive Only, Send and Receive, Receive and Send for UDP). Once a protocol definition is created, it can be used in packet filters, protocol rules, and Server Publishing rules. These definitions are input to the server publishing rules.
Once all of the protocol definitions are created for the active directory, the ports can be Server Published on ISAs external interface. Server publishing rules map incoming requests to the appropriate internal servers behind the ISA firewall. ISA listens on its external interface for incoming requests on behalf of the internal server and then creates a new session between itself and the internal server that is managing the session between the client (DMZ Servers) and the internal server (the domain controllers).
In order to support domain traffic to and from the domain controllers in the Infrastructure VLAN, the Server Message Block port (TCP Port 445) must be one of the ports that is Server Published on ISA Server and redirected to the internal domain controllers. In order for ISA Server to listen for TCP 445 on its external interface, this port must be completely disabled on the computer that is running ISA Server. The only way to completely disable NetBIOS and SMB on these computers is to disable the NetBIOS device driver.
The
A Split/Split DNS design has to be used when ISA Server is used as the internal firewall. This is because it is not possible to use Server Publishing to manage the DNS traffic from the servers in the DMZ to the internal DNS services running on the domain controllers that are located on the Infrastructure VLAN. The reason for this is that the IP addresses that are returned from the internal DNS servers cannot be routed through the internal firewalls because ISA Server proxies the requests.
In order to provide name resolution to the servers in the DMZ, the DNS zone files that are located on the internal DNS servers are copied to the external DNS Resolver servers located in the DMZ (see Figure 8), and then the zone files are modified. Placing the internal zone file on the external DNS Resolver is secure from Internet threat, because the DNS Resolver servers are configured not to accept queries from the internet. The host records in the zone file are changed to point to the IP Addresses defined on the internal ISA Server firewall VLAN 11 interface. The DMZ servers' DNS settings are configured to point to the DNS Resolver servers (192.168.11.16, 192.168.11.17) on VLAN 11 in order to resolve names for the internal servers that are behind the ISA Server firewall.
Note: During the deployment phase, there is no internal firewall implemented yet so all servers created in the nwtraders.com domain will have their IP addresses registered to the internal DNS servers (AD01 and AD02). After the deployment phase and ISA server has been implemented as the internal firewall, any server in the DMZ that is joined to the nwtraders.com domain will need to have Host and PTR records added to both DNS01 and DNS02 as well as AD01 and AD02. Dynamic updates are not supported since the internal DNS servers (AD01 and AD02) are not published through ISA.
Figure 8. Split/Split DNS configuration
Note: For clarity in the diagram the VLANs are shown connecting
to separate multi-layer switches. In reality all VLANs are managed on a single
switch with a second switch configured as a redundant partner.
A virtual private
network (VPN) is a way of using a public infrastructure, such as the Internet,
to carry a private encrypted point-to-point connection or tunnel. Packets are
encapsulated with a wrapper or header that includes routing information.
Windows 2000 supports both the common Layer 2 tunneling protocols: PPTP
(Point-to-Point Tunneling Protocol) and L2TP (Layer 2 Tunneling Protocol). In
the
Two VPN servers are deployed for redundancy and high availability. ISA Server is installed on both VPN servers to provide robust packet filtering, stateful packet inspection, and intrusion detection to better secure the VPN traffic. The steps for configuring the VPN servers with ISA Server are as follows:
1. Configure the IP network settings.
2. Configure load balancing
3. Install ISA Server
4. Configure the VPN network
5. Implement certificates
Both VPN servers are multihomed. Their internal interface connects to VLAN 12, with each server assigned an internal static IP address, and their external interfaces connect to the Internet-facing router. A public dedicated IP address was assigned to each VPN server and a public virtual IP address was assigned to both VPN servers Internet facing interface when Network Load Balancing was configured.
Figure 9. Configuring ISA Server for VPN
In this configuration the default gateway is configured on both VPN servers to point to the Internet-facing router in order to allow the VPN servers to respond to any Internet client. Static routes are created on the internal interfaces of both VPN servers. Adding routes to VLAN 11 and VLAN 13 (192.168.11.0 and 192.168.13.0) allows remote administrators to connect to the servers that are not on VLAN 12.
Both ISA Server and VPN servers are configured for stand-alone mode and are placed in firewall mode only. The LAT is configured for the three private networks 192.168.13.0, 192.168.12.0, and 192.168.11.0. From the LAT, ISA Server can differentiate Internet traffic from internal traffic.
It is very simple to configure ISA Server to support client VPN traffic through PPTP and L2TP by using the built-in ISA VPN Wizard. The wizard offers the following three options for VPN configuration:
· Local ISA Server virtual private network
· Remote ISA Server virtual private network
· ISA Server virtual private network
The ISA Virtual Private Network option is selected to allow roaming users to connect to the VPN server. After it is selected, ISA Server immediately configures the VPN settings by configuring packet filtering to allow PPTP and L2TP traffic through. During the configuration, ISA Server starts Routing and Remote Access Service (RRAS), if it has not already been started, and changes the service dependency so that RRAS must depend on ISA Server before it can start. The reason for this dependency is that both ISA Server and RRAS implement packet filtering. However, only one of these services can own this functionality on a given server. This dependency designates ISA Server as the owner. After the configuration is completed, you must manually change a setting within the ISA Server configuration to allow PPTP traffic through the firewall.
Four packet filters that are created in the ISA Server configuration support both PPTP and L2TP traffic. These filters are applied to the ISA Server computer external interface. By default, the ISA wizard will configure these filters to permit PPTP and L2TP traffic through the dedicated IP address assigned to ISAs internet facing interface. These filters must be manually changed from the dedicated IP address to the clustered or virtual IP address created by Network Load Balancing. This is the address that all of the VPN users will have configured in their clients. Since the L2TP protocol is not supported in this release, the two L2TP packet filters that are automatically created by the ISA Server configuration wizard should be either removed or disabled.
The following table lists the filters that the ISA VPN Wizard creates:
Packet Filter |
IP Protocol |
Direction |
Port |
Allow L2TP protocol IKE packets |
UDP |
Both |
500 |
Allow L2TP protocol packets |
UDP |
Both |
1701 |
Allow PPTP protocol packets (client) |
TCP |
Inbound |
1723 |
Allow PPTP protocol packets (server) |
TCP |
Outbound |
1723 |
Table 3. Filters generated by the ISA VPN wizard
After the ISA Server
VPN server has been configured, two additional steps need to be performed on
each RRAS server. First, the IP address pool must be defined. These addresses
are assigned to each new VPN client that comes through the VPN server. This
setting can be configured by either using DHCP or statically assigning the
addresses. Since there is no DHCP server in the
The second change made to the RRAS server is the number of simultaneous connections that are supported for each protocol (PPTP and L2TP). By default, five connections are configured for both PPTP and L2TP on each server. Depending on the usage of the VPN connections in your implementation, these values may need to be modified. In the Internet Data Center Architecture, L2TP connections were removed from both servers and the number of PPTP connections were changed to support ten simultaneous users.
When designing the
VPN solution, you can choose between the two main VPN protocols, PPTP and L2TP.
The
Note: This is not a limitation of
the firewall devices or of L2TP, but of the fact that IPSec which is used to
encrypt L2TP traffic cannot be used through NAT. This is the case with any
vendor firewall or IPSec implementation.
PPTP can be as secure as L2TP when 128-bit encryption and EAP are used with certificates or smart cards for authentication. PPTP with 128-bit encryption can still be made secure without EAP by using long, complex passwords with MS-CHAPV2. This can allow remote management to be performed from clients that do not support EAP, such as Microsoft Windows NT® version 4.0 or Windows 98 operating systems using the latest Dial Up Networking client.
The
Note: An even more secure solution
is to use EAP authentication with smart cards, as opposed to the registry-based
certificates solution. This option was not chosen for the
A certificate server is required to support EAP authentication using certificates, so an internal certificate server was implemented. This solution was chosen to allow the internal administrators to control certificate revocation, certificate-expiration timeframes, and certificate backups. If these features are not important in your design you could chose to use a certificate obtained from a public third-party issuer.
The Internet Data Center certificate server design is being used only to support VPN authentication .The certificate-server deployment architecture for this scenario is not intended to be used as an architecture for a more wide-scale corporate public key infrastructure (PKI) deployment. If certificate services had been required to support more complex scenarios, such as corporate employee usage, or business-to-business (B2B) scenarios, the certificate services would be deployed differently. Since that is not required, though, a very simple architecture is implemented to minimize management overhead.
Because the certificate server will be backed up regularly and certificates will rarely be requested from it (due to the small number of administrators for the site), the low availability needs for this server do not warrant a redundant failover architecture for this service. An enterprise CA is implemented on one of the domain controllers. Additionally, the IIS runs on this domain controller to support Web-based certificate enrollment by users and workstations.
This servers data and system state get backed up nightly to tape in order to ensure certificate backup, and would take a few hours to restore in the event of a failure.
The Web-based certificate enrollment tool is running on the certificate server and is used to service certificate requests from client workstations and users. Both of the VPN servers have the CA root certificate and a machine certificate installed, which is accomplished by creating an organizational unit for the VPN servers in Active Directory. Group Policy is then applied to this organizational unit, which automatically enrolls the machines contained within it for machine certificates.
Because the Extensible Authentication Protocol (EAP) is used as the authentication mechanism for PPTP, it is configured as the only accepted authentication mechanism and all others are disabled. Therefore, users are not able to connect to the VPN servers by using user names and passwords. This increases the security of the VPN solution.
This does mean that the administrators of the system are required to request the CAs root certificate and a user certificate while physically in the office. If administrators request these certificates from a company-owned laptop, they will be able to use the laptop to connect to the site. If they wish to administer the system from home they will need to export certificates to a floppy disk, which they then take home and install on their home computer. If the certificate is to be exported to a floppy disk, the Mark keys as exportable option must be chosen when the certificate is requested, or the certificate with its accompanying private key will not be exportable from the computer on which it was requested.
After the certificates are imported on the administrators home workstation, the certificate or key on the floppy disk should be erased, and the floppy destroyed. Optimally, for the highest level of security, the certificate or key would be stored on a smart card; however, because smart card readers are not yet prevalent in the marketplace, their use has not been required in the architecture. The certificate required for EAP authentication is a user certificate, which must be placed in the user personal certificate store on the Windows 2000 workstation.
The Remote-Access Policy is configured to accept EAP for authentication only at the strongest encryption level allowed. The strongest option allows connections to use only IPSec Triple DES or MPPE 128-bit encryption. This setting requires the 128-bit encryption pack to be installed on both clients and servers.
The Remote Authentication Dial-In User Service (RADIUS) was not used in the architecture because centralized accounting and management for VPN connections were not required to support remote access for the administrators. Accounting requests (such as accounting start or stop) and authentication requests, such as Access-Accept or Access-Reject, are logged on to the RRAS server. The RRAS server has a feature to log status periodically, such as interim accounting requests. This logging feature is not enabled because it can result in high-volume logs. A custom location, away from the default location, is specified for the log file, so that security can be tightened on the directory.
As explained earlier in this document, the IDC architecture requires that firewall solutions be highly available and fault tolerant. This goal can be met using a combination of Microsoft ISA Server and the Network Load Balancing Service, or Microsoft ISA Server together with a third-party clustering solution. The following sections describe the design issues that relate to the ISA Server/ Network Load Balancing Service solution.
The Network Load
Balancing Service can provide both fault-tolerance and horizontal scaling for
the computers running ISA Server. The Network Load Balancing Service has port
rules that can be configured to perform two functions:
· They specify affinity and load handling behavior on a port-by-port basis.
· They provide a level of security in that these rules are processed prior to packets reaching TCP/IP stack on the server.
By default the
Network Load Balancing Service has one rule configured. This rule defines the
following settings for the corresponding parameters:
Parameter |
Setting |
|
1-65535 |
Affinity |
Single |
Filter Mode |
Multiple hosts |
Load |
Equal |
Protocols |
Both |
Table 4. Default Network Load Balancing Service rule configuration
The default port rule is removed because no affinity should be used on stateless protocols or applications to achieve the best load-balancing configuration. Instead, the following rules are set on the servers running ISA Server:
Rule |
Start |
End |
Protocol |
Mode |
Load |
Affinity |
1 |
0 |
442 |
Both |
Multiple |
Equal |
None |
2 |
443 |
443 |
TCP |
Multiple |
Equal |
Single |
3 |
444 |
65535 |
Both |
Multiple |
Equal |
None |
Table 5. ISA Server rules
This version of the architecture provides three services to the Internet:
· HTTP. This is a stateless protocol, unless a Web applications session state is maintained on the Web server. This is highly discouraged for Web farms; application-session state should be maintained centrally in a database or some other centrally accessible storage mechanism.
· HTTPS. This is a session-oriented protocol.
· DNS. This is published through the ISA Server computers and therefore uses the dedicated IP address of the ISA Server computers, bypassing any Network Load Balancing port configuration.
For HTTPS, a session is established every time a client from the Internet connects with a different firewall that is publishing out the Web farm. If no affinity is used for HTTPS, the client may have to re-create a session every time it tries to connect to the Web farm. This is unacceptable.
Therefore, port 443 is configured for single affinity. This ensures that once a client establishes an SSL session with one firewall, that session will remain intact until the client is finished or the session times out.
Class C affinity is another option for load balancing. This option is similar to single affinity except that this option guarantees that clients with IP addresses within the same Class C range of addresses will be load balanced to the same firewall.
It is also possible
to provide a high-availability solution using third-party solutions that
provides dynamic load balancing across multiple ISA Server firewalls. For more
details on these solutions, see the following :
http://www.microsoft.com/isaserver/partners/highavailability.asp
The
For more information
about Microsoft Internet Security and Acceleration Server, refer to the ISA
Server Web site at:
http://www.microsoft.com/isaserver