Planning a Monitoring and Reporting Strategy

Monitoring Real-Time Information
You can monitor real-time information by configuring alerts that are raised when specific events occur. You can also collect real-time information about client connections, server performance, and connectivity on ISA Server. Consider the following when you create a monitoring and reporting strategy:

1- Decide the events to which you must be alerted in real time ISA Server can raise alerts based on almost any event that occurs. In most cases, you do not need to be apprised in real time about every alert. For example, if ISA Server blocks a single spoofing attack, you probably do not need to receive an alert. However, if the connection between ISA Server and a business-critical published Web server fails, you might decide that you must receive an alert. If you are using SMTP Message
Screener, and suddenly the volume of e-mail passing through the message screener increases tenfold, you must be notified about this immediately to reduce the impact of a potential virus outbreak.

2- Determine the threshold for the alert As part of deciding which events will raise alerts, you must also determine the threshold for when ISA Server will raise the alerts. If ISA Server detects hundreds of spoofing attacks within minutes, then you probably want to receive an alert. If a single VPN client fails to authenticate once, you are probably not interested. However, if the same client tries to authenticate many times, you may want to be alerted.

3- Monitor ISA Server using the ISA Server Management Console and Performance Monitor You can also collect real-time information from ISA Server using the ISA Server Management Console and the Performance Monitor. In many cases, you might use these tools for real-time analysis only when a problem is reported.For example, if users report that the Internet connection is slower than usual, you can use these tools to determine why. If you use the Performance Monitor, use the preconfigured ISA Server Performance Monitor to monitor the most important counters on ISA Server.

Collecting Long-Term Information
In addition to the real-time information that you can collect on ISA Server, you should also develop a strategy to collect long-term information on ISA Server. Categories of information that you should collect include the following:

1- Performance-related information To prepare for future modifications to the ISA Server infrastructure, regularly collect information about ISA Server performance. As a best practice, collect information about the performance to establish a baseline and then regularly collect the same types of information to determine how the performance on ISA Server is changing.

2- Usage information Regularly collect usage reports. This is useful for future planning and to monitor the current activity on the server.

3- Security-related information Collect information about security-related events. This information allows you to develop a baseline of the normal security events, which makes it easier to detect an anomaly to that regular pattern. This information may also be useful to track the progress of a successful attack so that you can prevent such an attack in the future.

Implementing Monitoring and Reporting

Planning a Monitoring and Reporting Strategy

Why You Should Implement Monitoring
ISA Server is a critical component in an organization’s network infrastructure. If ISA Server is deployed as an Internet-edge firewall, it operates as a firewall that secures the internal network. ISA Server may also be providing secure access to Internet resources for internal clients and access to specified internal resources for Internet clients. If ISA Server is not available, this functionality is disrupted. If ISA Server is being attacked from the Internet, the internal network may be at risk.

There are many reasons for monitoring ISA Server. Some of these include the following:
1- Monitoring traffic flow between networks You must monitor traffic between networks to ensure that your access rules are correctly configured and that only the expected traffic passes through ISA Server. You also need to monitor ISA Server regularly to identify normal and legitimate traffic passing through the server. After you identify a typical traffic pattern, you can detect any variation that
might indicate a potential problem.

2- Troubleshooting network connectivity Monitoring ISA Server is a critical component of troubleshooting network connectivity. For example, if users report that they cannot access resources on the Internet, you can connect to ISA Server to help locate the problem. In this scenario, the problem might be with the client configuration, the ISA Server configuration, or the availability of the Internet resource. By monitoring ISA Server, you can begin troubleshooting by identifying the option most likely to be the source of the problem.

3- Investigating attacks If ISA Server is operating as a firewall, it will inevitably be exposed to attacks from the Internet. If ISA Server is configured correctly, it can detect and block most attacks. However, even if ISA Server successfully blocks the attacks, you should still be aware that the attacks are occurring and be aware of any variations in the normal attack patterns. If a new attack is launched against ISA Server, you must be alerted as quickly as possible that the attack is occurring so that you can determine how to respond to the attack. After the attack is finished, you should also have enough information logged on the ISA Server computer to investigate the attack. Even if the attack fails, investigate the attack pattern to detect possible patterns that may lead to additional attack attempts.

4- Planning By monitoring the computer running ISA Server, you can also gather information you can use for planning modifications to the current ISA Server infrastructure. By collecting performance data over a period of time, you can identify trends and use this information for planning future deployments of ISA Server.

Guidelines for Troubleshooting VPN Client Connections

Enabling VPN connectivity requires a complex interplay between several server components such as the ISA Server configuration and the RRAS configuration. In addition, you have several configuration options such as authentication methods and tunneling protocols. All these components and options must be configured correctly to allow users to connect to the ISA Server computer using a VPN.

Use the following guidelines when troubleshooting VPN client connections:
1- The most common problems with VPN connections are user authentication problems.Start by checking the user configuration. Does the user have permission to dial in? Is the user part of a group that has permission to use VPN on the ISA Server computer? Is the user account locked out? Is the user using the correct password?

2- If the user account is not the problem, then check the authentication method configuration.If the user is connecting to a PPTP connection, ensure that the client and server share an authentication method. By default, ISA Server only enables MS-CHAP v2 authentication, so if users are using an older Windows client such as Windows 98 or Windows NT, they may not be able to support the authentication method. The best solution in this case is to install the appropriate security patches
on the clients so they support MS-CHAP v2 authentication.

3- If the users are connecting to an L2TP/IPSec connection, ensure that the client has the correct certificate installed or is configured to use the appropriate pre-shared key.

4- L2TP/IPSec clients may also not be able to authenticate if ISA Server is configured to block IP fragments. In this scenario, users will get an error message that indicates that the security negotiation timed out. IPSec uses the Internet Key Exchange (IKE) protocol for mutual computer authentication and for the exchange of session keys in an L2TP VPN connection. The IKE negotiation information cannot fit inside an MTU. Because of this, the IKE negotiation packet is fragmented into
smaller packets. When you filter fragmented packets in ISA Server, the IKE negotiation packets are dropped by ISA Server. Therefore, the VPN connection cannot be completed successfully. To enable client connections, you must configure ISA Server not to block IP fragments.

5- If the users can connect to the VPN remote-access server and authenticate, but cannot get access to any network resources, check the name resolution for the VPN clients. The VPN clients must be configured with a DNS server (and possibly a WINS server) address to resolve server names on the internal network.

6- If the DNS configuration is accurate, check the configuration of the access rules defined on the ISA Server computer. Remember that the VPN Clients network is used by ISA Server like any other network, so you must configure access rules in order to enable network traffic to flow between networks.

Configuring Virtual Private Networks for Remote Clients and Networks

How to Configure VPN Address Assignment
When VPN clients connect to the VPN server, they must be assigned an IP address configuration
that enables them to access the resources on the internal network or other networks. ISA Server can be configured to assign the IP address configuration directly, or to use a Dynamic Host Configuration Protocol (DHCP) server to assign the addresses.

When you use DHCP, VPN clients are assigned IP addresses that are part of the internal network subnet. The advantage of this addressing scheme is that you do not need to create special routing table entries to support the VPN clients and all VPN clients will automatically be able to access the internal network and the Internet (using the protocols specified in the access rules). In this configuration, ISA Server acts as an Address Resolution Protocol (ARP) proxy for VPN clients. For example, when addresses assigned to the VPN Clients network are part of the internal network segment, computers from the internal network will send ARP queries to VPN clients. ISA Server will
intercept the queries and reply on behalf of the connected VPN client. The network traffic will then be transparently routed to the VPN client.

Assigning IP Addresses to VPN Clients
When VPN clients connect to ISA Server, the client must be assigned an IP address.
There are two ways that ISA Server can assign the addresses:
1- Dynamic address assignment To enable dynamic address assignment, a DHCP server must be accessible from the computer running ISA Server. Any computer running Windows Server 2003 or Windows 2000 Server on the internal network can serve as the DHCP server. If you use a DHCP server for address assignment, ISA Server retrieves a group of available IP addresses from the DHCP server. When a VPN client connects, ISA Server assigns one of these addresses to the VPN client. As
part of the IP address assignment, ISA Server also assigns other TCP/IP properties such as the Domain Name System (DNS) servers and Windows Internet Naming Service (WINS) servers. The IP address assigned to the client is automatically moved from the internal network to the VPN Clients network (or Quarantined VPN Clients network if quarantine is enabled and the client is quarantined).

2- Static address assignment You can also configure ISA Server with a static pool of addresses to assign to VPN clients. In this configuration, you do not need a DHCP server; rather, you configure the IP addresses on the computer running ISA Server. When a client connects, ISA Server assigns one of the IP addresses to the VPN client. If you use a static address pool for address assignment, the addresses that you want to assign to the pool must first be removed from other defined networks,
because overlapping of IP addresses between networks is not allowed. You must also provide one more IP address in the static address pool than the expected number of remote VPN connections because the VPN interface on ISA Server requires an IP address.

Configuring Dial-In Permissions in Active Directory
In addition to configuring ISA Server to enable VPN connections, you must also configure Active Directory user accounts to enable dial-in permissions for those accounts. Until this is configured, users will be unable to connect to ISA Server using a VPN. The default user account configuration in Active Directory varies depending on the domain being used to authenticate users.

1- In Windows 2000 mixed-mode domains, or in Windows Server 2003 domains at the Windows 2000 mixed-functional level, all user accounts have dial-in access disabled by default. You must enable dial-in access on a per-account basis for these Active Directory domains.

2- In Windows 2000 native-mode domains, or in Windows Server 2003 domains at the Windows 2000 native or Windows Server 2003 functional levels, all user accounts, by default, have dial-in access controlled by Remote Access Policy. You can control dial-in access by just modifying the remote-access policy.

3- Windows NT 4.0 domains always have dial-in access controlled on a per-user account basis.

Configuring Virtual Private Networking for Remote Clients

How to Configure VPN Client Access
Before any users can access ISA Server using a VPN, you must enable VPN client access. When you enable this option, ISA Server enables VPN access using a default configuration that you can modify to meet your organization’s requirements.
The VPN client access configuration is managed using the Configure VPN Client Access dialog box in ISA Server Management. To access this dialog box, open ISA Server Management and click Virtual Private Networks (VPN).

Default VPN Client Access Configuration
When you enable VPN client access, the following default settings are applied:
1- System policy rules When VPN client access is enabled, a system policy rule named Allow VPN Client Traffic To ISA Server is enabled. Depending on which protocols are configured for remote-client access, the system policy rule allows the use of PPTP, L2TP, or both, from the external network to the computer running ISA Server (Local Host network).

2- VPN access network By default, ISA Server will listen for VPN client connections only on the external network. This property can be modified. When this property is modified, the system policy rule is changed automatically to apply to the additional or changed networks.

3- VPN protocol By default, only PPTP is enabled for VPN client access. This can be modified to include L2TP/IPSec only or both protocols. When this setting is modified, the system policy rule is updated to allow the appropriate protocol.

4- Network rules Enabling VPN client access does not modify the network rules configured on ISA Server. When you install ISA Server, two network rules are created that include the VPN Clients network, one specifying a route relationship between the VPN Clients network and the internal network, and one specifying a NAT relationship between the VPN Clients network and the external network. The second rule is part of the Internet access rule that also defines the relationship between the internal network and external network.

5- Firewall-access rules By default, clients on the VPN Clients network cannot access any resources on any other network. You can manually configure a firewallaccess rule that enables this access, or you can use a network template to configure the rule. If you use a network template, a firewall-access rule named VPN Clients to Internal Network is created. This rule allows access from the VPN Clients network to the internal network using all protocols. The VPN Clients network is also included in any rule that you create using a network template to grant Internet access. For example, if you use a network template to enable Internet access using all protocols, clients on the VPN Clients network will be able to access the Internet using that rule.

6- Remote-access policy When you enable ISA Server for VPN client access, a remote-access policy named ISA Server Default Policy is created in Routing and Remote Access. This default policy denies access to all VPN connections except those explicitly allowed by the remote-access profile. The remote-access profile for the default policy enables MS-CHAP v2 authentication and requires authentication for all VPN connections.

Guidelines for Planning a VPN Infrastructure

Implementing a VPN infrastructure must be planned carefully because you are deliberately exposing your internal network to the Internet. In many cases, VPN clients have complete access to the internal network, just as if the client computer were connected to the internal network behind the ISA Server computer. This means that your VPN implementation must be as secure as possible.

Use the following guidelines when planning your ISA Server VPN implementation:
1- For the highest level of security, implement a VPN solution that uses L2TP/IPSec,MS-CHAP v2, or EAP/TLS for user authentication and certificate-based authentication for computer authentication. With this configuration, you must deploy certificates to all remote-access clients. However, the certificate authentication means that only computers that have the appropriate certificate will be able to connect.

2- You can also deploy PPTP using certificate-based authentication. In this scenario,you can use two-factor authentication, with devices such as smart cards, to ensure the identity of the remote client. Although this option provides a more secure means to authenticate the remote-access user, it does not provide an option for authenticating the remote-access client computer.

3- If you do not have the option of deploying client certificates to all VPN clients or using smart cards, the most secure option is to use PPTP with password authentication. When you use PPTP, the data is encrypted; however, the authentication mechanism is not as secure. If you use password-based authentication, ensure that you enforce strong passwords by using Group Policy.

4- Always use the most secure protocols that both your VPN access servers and clients can support and configure the remote-access server and the authenticating server to accept only secure authentication protocols. If you have older VPN clients that do not support secure authentication protocols, consider not enabling VPN access for these clients. Only enable VPN access for these clients if there is a strong business need to do so, and if you do not have the option of upgrading the clients.

5- ISA Server 2004 allows you to use pre-shared keys in place of certificates when creating remote-access and gateway-to-gateway VPN connections. Pre-shared keysupport for IPSec-based VPN connections should be used only for testing purposes. A single remote-access server can use only one pre-shared key for all L2TP/IPSec connections requiring a pre-shared key for authentication. This means that you must issue the same pre-shared key to all L2TP/IPSec VPN clients. Unless you distribute the pre-shared key within a Connection Manager profile, each user must manually enter the pre-shared key into the VPN client software settings. This reduces the security of the L2TP/IPSec VPN deployment.

6- Using RADIUS for authentication does not increase the level of security for VPN connections. The only advantage of using RADIUS is that you can centralize policy management for multiple ISA Server computers acting as VPN remote-access servers.

7- Using SecurID can significantly increase the level of security for the VPN connections because SecurID requires access to the token that provides a one use password. However, deploying SecurID significantly increases the complexity of the VPN server deployment.

Planning a Virtual Private Networking Infrastructure

How VPN Quarantine Control Is Used to Enforce Remote-Access Security Policies
In most cases, a VPN remote-access server can only validate the credentials of remoteaccess users and computers. If the remote-access users successfully authenticate, they can access all resources on the internal network. However, the remote-access client computer may not comply with corporate security policies. In this situation, you can use VPN quarantine control to prevent remote access to a private network until a client-side script validates the remote-access client configuration.

VPN quarantine control allows you to scan the VPN client computer configuration before allowing them access to the organization’s network. To enable VPN quarantine, you create a Connection Manager Administration Kit (CMAK) package that includes a VPN client profile and a VPN-quarantine client-side script. This script runs on the remote-access client when the client connects to the VPN server. The script checks the security configuration of the client and reports the results to the VPN server. If the client passes the security configuration check, the client is granted access to the organization’s
network.

If you use ISA Server as the VPN server, and the script reports that the client meets the software requirements for connecting to the network, the VPN client is moved from the Quarantined VPN Clients network to the VPN Clients network. You can set different access policies for hosts on the Quarantined VPN Clients network compared to the VPN Clients network. In this way, you can limit network access until the clients have cleared quarantine, and then provide full access.

Although quarantine control does not protect against attackers, computer configurations for authorized users can be verified and, if necessary, corrected before they can access the network. A timer setting is also available, which you can use to specify an interval at which the connection is dropped if the client fails to meet configuration requirements.

The following clients can use VPN quarantine:
1- Windows Server 2003
2- Windows XP Home Edition and Windows XP Professional
3- Windows 2000
4- Windows Me
5- Windows 98 Second Edition

How Virtual Private Networking Is Implemented Using ISA Server 2004
When you configure ISA Server 2004 as a VPN server, it relies on and enhances the basic VPN functionality provided by Routing and Remote Access, available with Microsoft Windows Server 2003 and Windows 2000. ISA Server supports two types of VPN connections:

1- Remote-client access VPN connection A remote-access client makes a remoteaccess VPN connection that connects to a private network. ISA Server provides access to the internal network to which the VPN server is attached. To configure remote-client VPN access on ISA Server, configure the computer running ISA Server to accept VPN connections and define the parameters for what types of connections will be accepted.

2- Site-to-site VPN connection A VPN gateway server makes a site-to-site VPN connection that connects two private networks. To configure site-to-site VPN connections, you configure a remote-site network on the computer running ISA Server and then define how the VPN connection to the remote network will be created.
You also define access rules that determine what types of traffic will be allowed to flow from the remote network to the other networks protected by ISA Server. ISA Server assigns computers to networks and then uses network rules, network access rules, and publishing rules to restrict the movement of network traffic between networks. These concepts are also used by ISA Server to manage VPN connections.
ISA Server uses the following networks for VPN connections:
1- VPN Clients network This network contains the IP addresses of all the VPN clients that have connected using VPN client access.
2- Quarantined VPN Clients network This network contains the IP addresses of all the VPN clients that have connected using VPN client access but have not yet cleared quarantine.
3- Remote-site networks These networks contain the IP addresses of all the computers in remote sites when a site-to-site VPN connection is configured. Additional remote-site networks are created for each remote-site connection.

Configuring Virtual Private Networks for Remote Clients and Networks

VPN Authentication Method Options
The authentication protocol is used to verify the identity of the remote-access client.
ISA Server 2004 supports the following VPN authentication protocols:
1- PAP Password Authentication Protocol (PAP) uses plaintext passwords and is the least secure authentication protocol. PAP is typically used if the remote-access client and remote-access server cannot negotiate a more secure form of authentication.

2- SPAP The Shiva Password Authentication Protocol (SPAP) is a reversible encryption mechanism employed by Shiva. When a computer running Windows XP Professional connects to a Shiva LAN Rover, it uses SPAP, as does a Shiva client that connects to a server running Routing and Remote Access. This form of authentication is more secure than plaintext but less secure than CHAP or MS-CHAP.

3- CHAP The Challenge Handshake Authentication Protocol (CHAP) is a challenge response authentication protocol that uses the Message Digest 5 (MD5) algorithm to hash the response to a challenge that the remote-access server issues. CHAP is used by various vendors of dial-in servers and client computers, including Macintosh and UNIX. Data cannot be encrypted when you use the CHAP protocol. Therefore, CHAP is not considered a secure option.

4- MS-CHAP Microsoft CHAP (MS-CHAP) is similar to CHAP, except that MS-CHAP can be used with MPPE to encrypt data. MS-CHAP is more secure than CHAP, but use MS-CHAP only if you run earlier Microsoft operating systems that require it. Both CHAP and MS-CHAP are only as secure as the strength of the user’s password.

5- MS-CHAP version 2 MS-CHAP version 2 (MS-CHAP v2) was designed to fix many of the security issues with MS-CHAP, including the lack of mutual authentication. MS-CHAP v2 uses mutual authentication, so both the client and the server are authenticated. In addition, data is encrypted by using separate session keys for transmitted and received data, which makes it more difficult for an attacker to sniff the traffic and use a brute-force attack on the key. The session-key generation is
not entirely based on the user’s password, so a weak password will not necessarily leave the session vulnerable. MS-CHAP v2 is supported by VPN clients running Windows XP, Windows Server 2003, Windows 2000, Windows NT Workstation 4.0 with Service Pack 4 (SP4) and later, Windows Me or Windows 98.

6- EAP Extensible Authentication Protocol (EAP) is the most secure remote authentication protocol. It uses certificates on both the client and the server to provide mutual authentication, data integrity, and data confidentiality. It negotiates encryption algorithms and secures the exchange of session keys. Use EAP if you are implementing multifactor authentication technologies such as smart cards or universal serial bus (USB) token devices.

Choosing an Authentication Server
In addition to choosing the authentication method and protocol, you also need to decide whether you will use RADIUS or RSA SecurID for authentication. Just like ISA Server can be configured to use these services to enable authentication for Web publishing rules, it can also use them to authenticate VPN users. ISA Server can use IAS servers or any other RADIUS-compliant server.
Windows 2000 Server and Windows Server 2003 both include Internet Authentication Service, which is a RADIUS-compliant server. When ISA Server is configured to use the IAS server for authentication, the VPN server component forwards the credentials presented to it by the VPN client to the IAS server on the internal network. The IAS server forwards these credentials to a domain controller that authenticates the user.

The most important advantage for using RADIUS to authenticate VPN clients is so that you can use domain credentials for authentication when the server running ISA Server is not a member of the network domain. This adds a layer of security to the ISA Server firewall/VPN server solution because, if the firewall is compromised in any way, the machine’s domain membership cannot be leveraged to attack the internal network.

A second advantage for using RADIUS for authentication is that this configuration allows you to centralize Remote Access Policy administration. For example, you could have five servers running ISA Server configured as VPN remote-access servers configured in a network load-balancing (NLB) array. You could configure the settings manually on each server, or you could configure each of the servers to use an IAS server for authentication and then configure the Remote Access Policies once on the IAS server. By doing this, the same remote-access policies are automatically applied to each computer running ISA Server.

Configuring Virtual Private Networks for Remote Clients and Networks

Benefits of Using VPNs
The primary benefits of using VPNs are as follows:
1- Reduced costs Using the Internet as a connection medium saves long-distance phone expenses and requires less hardware than a dial-up networking solution. In the case of a site-to-site VPN, using the Internet as a WAN is also less expensive than using a dedicated WAN connection.

2- Security Authentication prevents unauthorized users from connecting to the VPN servers. Strong encryption methods make it extremely difficult for an attacker to interpret the data sent across a VPN connection.

3- Flexibility By using VPNs, the organization does not need to manage Internet connections or dial-up servers for remote users. The users need only be able to connect to the Internet using whatever technology is available.

4- Transparency to applications One of the significant advantages of using a VPN connection, rather than an alternative solution such as a client/server Web application, is that VPN users at remote locations can potentially access all protocols and servers on the corporate network. The remote-access VPN user does not need special software to connect to each of these services, and the network and firewall administrator does not need to create special proxy applications to connect
to these resources.

VPN Protocol Options
VPN security is based on the tunneling and authentication protocols that you use and the level of encryption that you apply to VPN connections. ISA Server 2004 supports two VPN tunneling protocols for remote-access connections: PPTP and L2TP/IPSec.

PPTP
PPTP uses Point-to-Point Protocol (PPP) user authentication methods and Microsoft Point-to-Point Encryption (MPPE) to encrypt IP traffic. PPTP supports the use of Microsoft Challenge Handshake Authentication Protocol Version 2 (MS-CHAP v2) for password-based authentication. For stronger authentication for PPTP connections, you can use smart cards or certificates to implement Extensible Authentication Protocol/Transport Level Security (EAP/TLS) authentication.
PPTP is widely supported and easily deployed, and it works with most network address translators (NATs). Although it is not considered as secure as IPSec, a PPTP-based VPN solution can reduce costs associated with implementing a certificate infrastructure and is less complex to administer than IPSec because it does not require digital certificates.

L2TP/IPSec
L2TP/IPSec is the more secure of the two VPN protocols, using PPP user authentication methods and IPSec encryption to encrypt IP traffic. You can also use certificate-based computer authentication to create IPSec security associations in addition to PPP-based user authentication. L2TP/IPSec provides data integrity, data origin authentication, data confidentiality, and replay protection for each packet.

VPN Authentication Options
In addition to selecting a VPN tunneling protocol, you must also choose an authentication protocol and choose whether to use a RADIUS or RSA SecurID for authentication. Choosing the appropriate authentication mechanism is essential when designing a VPN implementation because not all VPN clients support the most secure authentication options. The authentication mechanism should be as secure as possible while still enabling VPN client access.

Configuring Virtual Private Networks for Remote Clients and Networks

Planning a Virtual Private Networking Infrastructure
Before you deploy a virtual private network solution using ISA Server 2004, you must plan the deployment so that you can take full advantage of the ISA Server VPN features. This lesson discusses the protocols and authentication methods available when using ISA Server 2004 to implement virtual private networking. Moreover, the chapter describes how VPN quarantine control works. The chapter then describes how you can use ISA Server 2004 to implement a VPN solution and provides guidelines for planning the deployment.

What Is Virtual Private Networking?
Virtual private networking allows secure remote access to resources on an organization’s internal network for users outside the network. These resources would otherwise be available only if the user were directly connected to the corporate network. A VPN is a virtual network that enables communication between a remote access client and computers on the internal network or between two remote sites separated by a public network such as the Internet.

How VPNs Work
When you configure a VPN, you create a secured, point-to-point connection across a public network such as the Internet. A VPN client uses special tunneling protocols, which are based on Transmission Control Protocol/Internet Protocol (TCP/IP), to connect to a virtual connection port on a VPN server. The tunneling protocols use encryption protocols to provide data security as the data is sent across the public network. The two VPN protocols supported by ISA Server are Microsoft Point-to-Point Tunneling Protocol (PPTP) or the Layer Two Tunneling Protocol with Internet Protocol Security(L2TP/IPSec).

PPTP and L2TP create "virtual" direct connections between a VPN client and VPN remote-access server, or between two VPN gateways. This connection allows a computer connected over the virtual network to send and receive TCP/IP messages in the same way as it does on other directly connected networks, such as computers located on the same Ethernet local area network (LAN). The actual network connection is transparent to the applications running on the client computer.

PPTP and L2TP use encryption protocols to ensure that the connection is private or secure by encrypting all traffic sent across a public network. PPTP uses the Microsoft Point-to-Point Encryption (MPPE) protocol to protect data moving through the PPTP virtual networking connection. The L2TP/IPSec VPN protocol uses Internet Protocol Security (IPSec) to encrypt data moving through the L2TP virtual network.

VPN scenarios
VPNS are used in two primary scenarios, as shown in Figure 10-1:
1- Network access for remote clients In this scenario, a remote user establishes a connection to the Internet and then creates a tunneling protocol connection to the VPN remote-access server. The remote user can use any available technology to connect to the Internet, including dial-up connection to an Internet service provider (ISP) or a direct connection such as a cable or digital subscriber line (DSL) connection. Once connected to the Internet, the VPN client makes a virtual private network connection to the VPN remote-access server that is also connected to the Internet. The remote-access server authenticates the user and possibly the remote computer, establishes a secure connection and transfers encrypted data between the virtual private networking client and the organization’s network.

2- Site-to-site VPNs A site-to-site VPN connection connects two or more networks in different locations using a VPN connection over the Internet. In this scenario, each site requires a VPN gateway and an Internet connection. When the gateways establish a VPN connection with one another, the site-to-site VPN link is established. Users can then communicate with other networks over the VPN site-to-site link. The VPN gateways act as VPN routers that route the packets to the appropriate network. In most cases, a site-to-site VPN connection is made between branchoffice
and main-office networks.

Configuring ISA Server to Secure Web Client Connections

Exchange Server 2003 Wireless Device Support
Exchange Server 2003 allows users of wireless and small devices, such as mobile phones, personal digital assistants (PDAs), or smart phones (hybrid devices that combine the functionality of mobile phones and PDAs), access to Exchange data. Exchange ActiveSync and Outlook Mobile Access (OMA) are two of the mobile service components that are built into Exchange Server 2003.

Exchange ActiveSync is a service provided in Exchange Server 2003 that allows users to synchronize their Exchange information (inbox, subfolders, calendar, contacts, and tasks) with their ActiveSync-enabled mobile device (such as Pocket PC 2002, Smartphone 2002, and Windows Mobile 2003 devices).

OMA is a service provided in Exchange Server 2003 that allows users to access their Exchange mailbox by using a browser-enabled mobile device. Devices such as mobile phones and PDAs that use extensible Hypertext Markup Language (XHTML), compact HTML (cHTML), or standard HTML browsers allow your users to connect to their inbox, calendar, contacts, and tasks, and perform global address list (GAL) searches. In addition to mobile phones, Windows Mobile devices using Microsoft Pocket Internet Explorer and desktop personal computers using Microsoft Internet Explorer 6.0 or later
also support OMA.

Like OWA, OMA and ActiveSync require that the computer running Exchange Server 2003 be accessible from the Internet using HTTP. When accessing a mailbox using OMA, the wireless device connects to a wireless access point that provides access to the Internet. Then the Web browser on the wireless device is used to access the computer running Exchange Server.

The use of wireless clients raises similar security issues to OWA including the following:
1- Securing the user logon By default, OMA is configured to use HTTP. This means that all user logon information is passed in clear text to the computer running Exchange Server. In addition, authentication to the SMTP server is passed in clear text. This issue can be easily addressed using SSL to encrypt all user sessions.

2- Securing e-mail contents Because all messages are sent in clear text using HTTP or SMTP, the e-mail contents may not be secure while crossing the Internet. SSL can secure the e-mail in this case.

Configuring ISA Server to Secure Web Client Connections

Providing user access to e-mail from anywhere has become an important service for many organizations. Many of these organizations have chosen to use Web-based clients to give remote users access to their Exchange Server mailboxes. One of the most popular ways to provide access to e-mail on Exchange Server computers for users outside the internal network is to deploy an Outlook Web Access (OWA) server that is accessible from the Internet. With OWA, users can access their mailboxes on an Exchange server from any computer with an Internet connection and a Web browser. In addition, Exchange Server 2003 also enables access to mailboxes for wireless mobile clients, including Outlook Mobile Access (OMA) and Microsoft ActiveSync clients. This lesson describes how to use ISA Server to secure Web client connections.

Known Web Client Security Issues
The most popular options for providing Web-based client access to Exchange Server mailboxes are using Outlook Web Access (OWA) and Outlook Mobile Access (OMA) and Microsoft Exchange ActiveSync.

Outlook Web Access Features and Security Issues
OWA provides access to the mailboxes on an Exchange Server computer through a Web browser. Although OWA does not provide all the functionality provided by a full Outlook client, the fact that it is easy to deploy and requires no special client makes OWA an attractive option for providing remote access.

By default, all servers running Exchange 2000 Server and Exchange Server 2003 are OWA servers. To install Exchange Server, Microsoft Internet Information Services (IIS) must be installed on the computer. When the user connects to a computer running Exchange Server from the Web browser, the request is passed from IIS to the Exchange Server services on the computer. The requested content is returned to the IIS service, where it is forwarded to the Web browser.

OWA is frequently deployed using front-end and back-end servers. To do this, the front-end server must be running Exchange 2000 Server, Enterprise Edition, or Exchange Server 2003, Enterprise Edition. In this configuration, clients connect to the front-end server. This server authenticates the user, and then queries Active Directory directory service to determine which back-end computer running Exchange Server hosts the user mailbox. The front-end server then forwards the request to the back-end server. The back-end server replies to the front-end server, which replies to the client.

The use of OWA raises several issues with e-mail security, including the following:
1- Securing the user logon By default, OWA is configured to use Hypertext Transfer Protocol (HTTP). This means that all user logon information is passed in clear text to the computer running Exchange Server. This issue can be easily addressed using Secure Sockets Layer (SSL) to encrypt all user sessions. However,some clients may cache the user logon credentials so that if the user does not close all Web browser sessions, another user may be able to access the user’s e-mail without logging on.

2- Securing e-mail contents Because all messages are sent in clear text using HTTP, the e-mail contents may not be secure while crossing the Internet. You can use Hypertext Transfer Protocol Secure (HTTPS) to secure the e-mail. However, some Web browsers may cache the e-mail contents on the local computer. For example, when you open an attachment using OWA, it is stored in the temporary Internet files on the computer. Another user may be able to gain access to the files.

Configuring ISA Server to Secure SMTP Traffic

How to Configure the SMTP Application Filter
To make an Exchange Server computer accessible to other SMTP servers on the Internet,you must configure a publishing rule that publishes the Exchange Server computer using the SMTP port. When you configure a rule that uses SMTP, the SMTP application filter is enabled for that rule automatically. The SMTP application filter accepts the traffic, inspects it, and forwards it to internal SMTP servers only if the SMTP filter allows it.

What Is SMTP Command Filtering?
SMTP servers use a set of commands (also called verbs) to initiate an SMTP connection between servers and then to transmit SMTP messages. The SMTP application filter filters SMTP traffic by examining these SMTP commands.

The SMTP filter can be configured to disable specific SMTP commands. When an SMTP server or client uses a command that is defined but disabled, the filter stops the command and closes that connection. For example, if you disable the VRFY command, ISA Server will block all SMTP connections that use this command. When a client uses a command that is not recognized by the SMTP filter, the connection is also denied. For example, the SMTP filter does not define the TURN command, so TURN commands will be blocked by the SMTP filter.

Each SMTP command also has a maximum length that specifies the number of bytes allowed for each command. If an attacker sends a command that exceeds the number of bytes allowed for the command, ISA Server drops the connection and prevents the attacker from communicating with the SMTP server. For example, the default maximum length for the RCPT TO command is 266 bytes. If an SMTP connection uses a longer RCPT TO command than this limit, the connection is dropped.

How Message Screener Filters Messages
The Message Screener must be installed on a server running the Microsoft Internet Information Services (IIS) 5.0 or IIS 6.0 SMTP service. The Message Screener component can be installed on the computer running ISA Server, on a computer running Exchange Server, or on any other IIS 5.0 or IIS 6.0 SMTP server in the internal network or in a perimeter network (also known as a demilitarized zone, or DMZ).

SMTP Message Screener can be configured to filter incoming mail based on the following:
1- The information in the MAIL FROM SMTP command The MAIL FROM command specifies the source SMTP address for the e-mail message. This is used for sender and domain name filtering.

2- The information in the Content-Disposition header field for each attachment This field commonly contains the attachment file name and extension. SMTP Message Screener can filter attachments by extension, by name, or by size.

3- Keywords in the message subject or body This is used for filtering the message subject and the body, either text/plain or text/html content type.

SMTP Message Screener can be configured to delete e-mail messages, hold e-mail messages for later inspection, or forward e-mail messages to a specific e-mail account for further examination and analysis.

Configuring ISA Server to Secure SMTP Traffic

How to Configure ISA Server to Secure SMTP Traffic
ISA Server provides three components for securing SMTP traffic. The first is the Mail Server Wizard, which can be used to publish the SMTP server to the Internet. The second component is the SMTP Message Screener, which can help reduce the amount of unwanted e-mail entering the organization. The third component is the SMTP application filter, which can be used to block buffer-overflow attacks or SMTP command based attacks on Exchange Server.

Mail Server Wizard
You can use the Mail Server Wizard to make Exchange Server computers available to Internet clients. The Mail Server Wizard includes several options, one of which is publishing an SMTP server. When publishing an Exchange Server computer as an SMTP server, you create a server publishing rule that accepts SMTP traffic on the ISA Server computer’s external interface and forwards the packets to the Exchange Server computer.

SMTP Application Filter
ISA Server 2004 provides application-layer filtering to help prevent Internet attackers from using buffer-overflow commands to disable or take control of your computer running Exchange Server. The SMTP application-layer filter inspects the commands included in all incoming SMTP communications. You can configure the SMTP filter to limit the size of the SMTP command sequences as well to block specific commands.

SMTP Message Screener
The ISA Server 2004 SMTP Message Screener can be used to control incoming SMTP mail by performing application-layer inspection of all SMTP messages. The Message Screener can scan the messages and examine the attachments and then block or hold messages for later inspection.

You can configure the SMTP Message Screener to block or hold incoming or outgoing e-mail using the following parameters:
1- Source or destination e-mail domain
2- Source or destination e-mail address
3- Attachment size, file extension, or file name
4- Keywords in the mail subject or body
The SMTP Message Screener can block or hold messages sent from the internal network in the same way that it does for messages entering the network.

Integrating ISA Server 2004 and Exchange Server

Configuring ISA Server to Secure SMTP Traffic :
One way that ISA Server can secure Exchange Server is by providing enhanced options for filtering all SMTP messages sent from the Internet to the computers running Exchange Server. This lesson explains how to publish SMTP servers and how to configure SMTP filtering.

Known SMTP Security Issues
Virtually all e-mail sent on the Internet is sent using SMTP. To receive e-mail from the Internet, your organization must have an SMTP server that is accessible to other SMTP servers. However, SMTP has some security weaknesses, both at a protocol level and in terms of the content sent using SMTP messages.

SMTP Protocol-Level Exploits
SMTP servers are vulnerable to several protocol level exploits including buffer-overflow attacks and SMTP command attacks.
Buffer-overflow attacks A buffer-overflow attack is triggered when a program or process tries to store more data in a memory buffer than the buffer’s designed capacity.The extra information can spill into adjacent buffers, corrupting or overwriting the valid data that they hold. In buffer-overflow attacks, the extra data may contain code designed to trigger specific actions, in effect sending new instructions to the attacked computer. Buffer-overflow attacks can be mounted against an organization’s SMTP server by sending large SMTP commands. The best deterrent to a buffer-overflow attack against the SMTP server is to stop the attacker at the network perimeter, before
the exploit ever finds its way into the corporate network.

Attackers use buffer-overflow exploits to disable specific server services with the intent of mounting a denial-of-service (DoS) attack, either by disabling a specific service on the target computer or by taking the entire machine offline. More elaborate buffer overflow exploits can be used to disable key security features and allow the attacker to run commands of his choice on the targeted machine.

SMTP command attacks SMTP servers must support a standard set of commands that are used to send and receive SMTP messages. Attackers can use the commands to mount buffer-overflow attacks or to send malformed commands that the system programmers did not anticipate. Command-manipulation attacks can lead to system compromise by giving an attacker access to key files, the ability to overwrite files, or to inject Trojan horse programs onto a mail server.

Some SMTP commands are optional. Some commands, such as EXPN and VRFY, if configured incorrectly, can be used to find a list of recipients on the server. If these commands are not required, they can be disabled at the firewall so that the SMTP server does not receive them.

Unwanted or Malicious E-Mail Attacks
The most prominent security challenge related to e-mail is the number of unwanted and malicious e-mails that are sent across the Internet. These e-mails can be grouped in two categories: unwanted junk e-mail that consumes computer resources and user time but does not harm the computer, and malicious e-mails that contain viruses, worms, or Trojan horse programs.

Unwanted E-Mail It has been estimated that unwanted e-mail messages consume more than 50 percent of total bandwidth usage on the Internet today. Unwanted e-mail leads to the following problems:

1- Wasted bandwidth on both internal and Internet networks, which may lead to increased Internet bandwidth cost, and increased nonproductive traffic on the corporate network.
2- Increased resource usage, including disk space, processor, and memory use on e-mail servers
3- Decreased employee productivity due to reading and deleting unwanted e-mail
4- Increased administrative costs as network administrators attempt to reduce the negative effects of unwanted e-mail
5- Increased exposure to legal liability to users who may view offensive unwanted e-mail messages.

Malicious E-Mail Viruses and worms sent by e-mail can cause a tremendous amount of damage to corporate networks. Viruses and worm attacks are responsible for the following:

1- Destruction of data on servers and workstations
2- DoS attacks on servers and workstations
3- Lost employee productivity because a workstation or network server is unavailable
4- Distribution of corporate secrets by means of mass-mailing worms
5- Increased administrative costs due to repairing damaged workstations and servers
6- Increased bandwidth use on the corporate network and Internet connection secondary to mass-mailing worms and DoS attacks.

Viruses and worms most commonly access an organization’s network through e-mail. Virus writers realize that e-mail is a critical service in most organizations and they exploit this fact by crafting viruses and worms that spread by e-mail. When a user opens an e-mail attachment that contains dangerous code, the code is released to the user’s computer and then spreads to the rest of the network. A single infected host can damage virtually every networked device in a short period.

Configuring Intrusion Detection and IP Preferences

Intrusion-Detection Configuration Options
To protect your network, you will also need to know how to configure your ISA Server for intrusion detection. Intrusion detection identifies when an attack is attempted against your network and performs a set of configured actions, or alerts, in case of an attack. To detect potential attacks, ISA Server compares network traffic and log entries to well-known attacks. When ISA Server detects suspicious activities, it triggers an alert. You can configure the actions that ISA Server will perform in the event of an alert. These actions include connection termination, service termination, e-mail alerts, logging, and others.

Intrusion Detection at the Application Layer
ISA Server also provides built-in application filters that detect DNS networking protocol and Post Office Protocol (POP) intrusions. The DNS intrusion-detection filter detects the following known DNS exploits:

- DNS host name overflow A DNS host name overflow occurs when a DNS response for a host name exceeds a certain fixed length (255 bytes). Applications that do not check the length of the host names may overflow internal buffers on the server when copying this host name, allowing a remote attacker to execute arbitrary commands on a targeted computer. This filter inspects the response that an internal client receives from an external DNS server.

- DNS length overflow DNS responses for IP addresses contain a length field,which should be 4 bytes. By formatting a DNS response with a larger value, some applications executing DNS lookups will overflow internal buffers, potentially allowing a remote attacker to execute arbitrary commands on a targeted computer. This filter inspects the response that an internal client receives from an external
DNS server.

- DNS zone transfer A malicious user executes a zone transfer to gather a list of all the host names in a domain. This filter detects when an Internet user attempts to execute a zone transfer from an internal DNS server through ISA Server.

The POP filter intercepts and analyzes POP traffic destined for the published servers. The application filter checks for POP buffer overflow attacks. A POP buffer overflow attack occurs when a remote attacker attempts to gain root access to a POP server by overflowing an internal buffer on the server.

IP Preferences Configuration Options
Another option on ISA Server 2004 that you can use to improve security is to configure the IP preferences. IP preferences are used to configure how ISA Server will handle specific types of IP packets. Configuring IP preferences is more complicated than configuring intrusion detection because, in most cases, IP preferences can be used to block normal packets that may or may not be used by attackers. You can configure the following IP preferences on ISA Server:

- IP option You can configure ISA Server to refuse all packets that have the IP options flag set in the header, or you can configure ISA Server to drop packets with only specific IP options enabled. The IP options flags that are most commonly used by attackers are the source routing options. The source route option in the IP header allows the sender to override routing decisions that are normally
made by the routers between the source and destination machines. An attacker can use source routing to reach addresses on the internal network that normally are not reachable from other networks, by routing the traffic through another computer that is reachable from both the other network and the internal network. Because source routing can be used in this way, you should disable source routing on your ISA Server computer.

- IP fragments You can also configure ISA Server to drop all IP fragments. A single IP datagram can be separated into multiple datagrams of smaller sizes known as IP fragments. If you enable this option, then all fragmented packets are dropped when ISA Server filters packet fragments. A common attack that uses IP fragments is the teardrop. In the teardrop attack, multiple IP fragments are sent to a server. However, the IP fragments are modified so that the offset fields within the packet overlap. When the destination computer tries to reassemble these packets, it is unable to do so. It may fail, stop responding, or restart. Enabling IP fragment filtering can interfere with streaming audio and video. In addition, Layer Two Tunneling Protocol (L2TP) over IPSec connections may not be established successfully because packet fragmentation may take place during certificate exchange.

- IP routing When IP routing is enabled, ISA Server sends the original network packet from one network to another. ISA Server can filter the network packet. When IP routing is disabled, ISA Server sends only the data (and not the original network packet) to the destination. Also, when IP routing is disabled, ISA Server sends each packet through the firewall in user mode. Disabling IP routing is more secure, but can also decrease router performance.

Implementing Perimeter Networks and Network Templates

What Are Network Templates?
ISA Server 2004 can be deployed in any of the perimeter network configurations. To simplify the deployment, ISA Server 2004 includes several network templates that you can use to configure ISA Server based on one of the perimeter network scenarios. A network template is stored in an Extensible Markup Language (XML) file that includes the following:

1- Networks and network sets
2- Network rules that describe the relationships between networks and network sets
3- Access rule elements
4- Access rules

To apply a network template, run the Network Template Wizard. When you run the wizard, you can choose the level of access that will be enabled between networks. For example, you may want internal users to be able to access resources on the Internet using all protocols, but only use HTTP or HTTPS to access the perimeter network. The access rules created by the wizard are based on the level of access you grant.

ISA Server Template Types
ISA Server 2004 provides the following templates:
- Edge Firewall This template assumes a network topology with ISA Server configured as a bastion host. One network interface is connected to the internal network, the other is connected to an external network (Internet). When you select this template, you can allow all outgoing traffic, or limit outgoing traffic to allow only Web access.

- 3-Leg Perimeter This template assumes a network topology with ISA Server configured as the firewall for a three-leg perimeter configuration. In this configuration, ISA Server has three network interfaces, one connected to the internal network, one connected to the external network, and one connected to a perimeter network.

- Front End This template assumes a network topology with ISA Server at the edge of a network, with another firewall configured at the back end, protecting the internal network.

- Back End This template assumes a network topology with ISA Server deployed between a perimeter network and the internal network, with another firewall located between the perimeter network and the Internet.

- Single Network Adapter This template assumes a single network adapter configuration within a perimeter or corporate network. In this configuration, ISA Server is used as a Web proxy and caching server.

Implementing Perimeter Networks and Network Templates

What Are Perimeter Networks?
A perimeter network is a network that is separated from an internal network and the Internet. Perimeter networks allow external users to gain access to specific servers that are located on the perimeter network while preventing direct access to the internal network.

Perimeter networks have the following characteristics:
1- Protected by one or more firewalls Perimeter networks are separated from the Internet by one or more firewalls or routers. The perimeter network is usually also separated from the internal network by a firewall. The firewall protects the servers in the perimeter network from the Internet and filters traffic between the perimeter network and the internal network.

2- Contain publicly accessible servers and services The servers in the perimeter network are usually accessible to users from the Internet. The types of servers or services that are often located in the perimeter network include VPN servers and clients, remote access servers (RASs) and clients, Web servers, application front-end servers, SMTP gateway servers, and proxy servers.

3- Must be accessible from the Internet Because the servers on the perimeter network must be accessible from the Internet, the firewall protecting the perimeter network must allow network traffic from the Internet. This traffic must be filtered to ensure that only legitimate traffic enters the perimeter network. Because almost all network traffic will flow from the Internet to the perimeter network, most firewall rules can be configured to allow only inbound traffic.

4 -Require network connectivity to the internal network Frequently, the computers on the perimeter network must be able to connect to resources on the internal network. For example, VPN or RAS Clients connect to the VPN or RAS server, but then must gain access from that server to the internal network. An SMTP gateway server must be able to forward messages to internal e-mail servers. An application front-end server may need to connect to a database server on the internal
network. Often, users on the internal network must also be able to connect to servers in the perimeter network. This means that you must configure firewall access rules on the firewall between the perimeter network and the internal network to enable the required network traffic.

5- Require some level of network protection The servers on the perimeter network must be partially isolated both from the Internet and the internal network. The firewalls on both sides of a perimeter network should not forward all traffic, but should filter traffic flowing in both directions. Only required network traffic should be allowed to pass between networks.

Benefits of Using a Perimeter Network
The main reason for using a perimeter network is to provide an additional layer of security. A perimeter network is commonly used for deploying publicly accessible servers while servers that should never be accessed from the Internet are located on the internal network. In this way, even if an attacker penetrates the perimeter network security, only the perimeter network servers are compromised.

The servers in the perimeter network usually do not contain confidential or private organization data. This data and critical applications are located on the internal network. By implementing a perimeter network, you ensure that there is an additional layer of security between the Internet and the internal servers.

The perimeter network can also be used to secure other connections to the internal network. For example, many organizations are using mobile clients such as wireless devices or cell phones to access information such as e-mail on the internal network. These devices greatly increase the security risks; one way to reduce that risk is to install the wireless access servers for these devices in the perimeter network and then use the internal firewall to filter traffic from these servers to the internal network. VPN servers and clients can be secured using the same method.

Lesson 2: Configuring Multiple Networking on ISA Server

How to Configure Network Rules
When you enable networks or network objects on ISA Server, you can configure network rules that define how network packets will be passed between networks or between computers. Network rules determine whether there is a relationship between two network entities and what type of relationship is defined. Network relationships can be configured as follows:
1- Route When you specify this type of connection, client requests from the source network are directly routed to the destination network. The source client address is included in the request. A route relationship is bidirectional. That is, if a routed relationship is defined from network A to network B, a routed relationship also exists from network B to network A.
2- Network Address Translation (NAT) When you specify this type of connection, ISA Server replaces the IP address of the client on the source network with its own IP address. A NAT relationship is directional. It indicates that the addresses from the source network are always translated when passing through ISA Server. For example, by default a NAT network relationship is defined between the Internet and the internal network. When a client makes a request on the Internet, the IP addresses of the internal client computer are replaced by the address on the ISA Server computer before the request is passed to the server on the Internet. On the other hand, when a packet from the Internet is returned to the client computer, the address of the server is not translated. Client computers on the internal network can access the actual addresses of computers on the Internet, but computers on the Internet cannot access the internal IP addresses.

How Network Rules and Access Rules Are Applied
ISA Server uses both network rules and access rules to determine whether a client request is passed from one network to another. Together, the network rules and access rules comprise the firewall policy.
The firewall policy is applied in the following way:
1. A user using a client computer sends a request for a resource located on another network. For example, a client on the Internal network sends a request to a server located on the Internet.
2. ISA Server checks the network rules to verify that the two networks are connected.If no network relationship is defined between the two networks, the request is refused.
3. If a network rule defines a connection between the source and destination networks,ISA Server next processes the access rules. The rules are applied in order of priority as listed in the ISA Server Management Console interface. If an allow rule allows the request, then the request is forwarded without checking any additional access rules. If no access rule allows the request, the final default access rule is applied, which denies all access.
4. If the request is allowed by an access rule, ISA Server checks the network rules again to determine how the networks are connected. ISA Server checks the Web chaining rules (if a Web Proxy client requested the object) or the firewall chaining configuration (if a SecureNAT client or a Firewall client requested the object) to determine how the request will be serviced.
5. The request is forwarded to the Internet Web server.

Creating a New Network Rule
To create a new network rule, use the following procedure:
1. In the Microsoft ISA Server Management Console tree, expand the Configuration node and click Networks.
2. In the Details pane, click the Network Rules tab.
3. On the Tasks tab, click Create a New Network Rule.
4. On the Welcome to the New Network Rule Wizard page, in the Network Rule Name: box, type the name for the network rule. Click Next.
5. On the Network Traffic Sources page, click Add.
6. On the Add Network Entities page, select the Network Entity to which this rule will apply. Click Add, and then click Close.
7. On the Network Traffic Sources page, click Next.
8. On the Network Traffic Destinations page, click Add.
9. On the Add Network Entities page, select the Network Entity to which this rule will apply. Click Add, and then click Close.
10. On the Network Traffic Destinations page, click Next.
11. On the Network Relationship page, click Network Address Translation or Route. Click Next.
12. On the Completing The New Network Rule Wizard page, review the settings and then click Finish.

Lesson 2: Configuring Multiple Networking on ISA Server

ISA Server Support for Multiple Networks
ISA Server 2004 uses networks to define blocks of IP addresses that may be directly attached to the ISA Server computer or IP addresses that may be remote networks. ISA Server uses these networks as components when you create access rules. ISA Server supports an unlimited number of networks.

What Is Multinetworking?
Multinetworking means that you can configure multiple networks on ISA Server, and then configure network and access rules that inspect and filter all network traffic between all networks. Multinetworking enables flexible options for network configuration. One common network configuration is a three-legged firewall.
In this configuration, you create three networks:
1- The servers that are accessible from the Internet are usually isolated on their own network, such as a perimeter network.
2- The internal client computers and servers that are not accessible from the Internet are located on an internal network.
3- The third network is the Internet.
ISA Server multinetworking functionality supports this configuration. You can configure how clients on the corporate network access the perimeter network, and how external clients access the perimeter network. You can also define access rules for all
network traffic flowing from the Internal network to the Internet. You can also configure the relationships between the various networks, defining different network rules between each network.

You might also need to configure a more complicated network environment. In this scenario, you could have the following:
1- Two perimeter networks Perhaps you are deploying some servers that are domain members and other servers that are stand-alone servers. The domain members need to be able to communicate with domain controllers that are located on your internal network. In this scenario, you could configure a second perimeter network for the servers that need to be members of the domain.
2- Two internal networks You might have a group of client computers that needs to access the Internet using a different application or with security rules different from the other client computers. You can create an additional internal network and configure specific Internet access rules for each network.
3- VPN client and VPN remote-site networks ISA Server defines a network for VPN clients, and you can define a network for each remote site connected with a site-to-site VPN connection.

How to Create and Modify Network Objects
For a small organization with a fairly simple network, the default network objects may provide all the configuration options required. However, in a larger organization with a more complex network environment and more complicated requirements, you may need to create and modify the network objects.
To create a new network object, use the following procedure:
1. In the Microsoft ISA Server Management Console tree, expand the Configuration node and click Networks.
2. In the Details pane, click the Network tab.
3. On the Tasks tab, click Create a New Network.
4. On the Welcome to the New Network Wizard page, in the Network Name: box,type the name for the network. Click Next.
5. On the Network Type page, select the type of network
you are creating. Select one of the following options:
. External Network
. Internal Network
. Perimeter Network
. VPN Site-To-Site Network
6. After selecting the network type, click Next.
7. If you selected an internal, perimeter, or external network type, on the Network Addresses page, click Add.
8. In the IP Address Range Properties page, type the starting and ending addresses,and then click OK.
9. On the Completing The New Network Wizard page, review the settings and then click Finish.
To modify a network, click the network in ISA Server Management Console and then click Edit Selected Network.

Introduction to ISA Server as a Firewall

What Is Application-Layer Filtering?
Application-layer filtering enables the firewall to inspect the application data in a TCP/IP packet for unacceptable commands and data. For example, a Simple Mail Transport Protocol (SMTP) filter intercepts network traffic on Port 25 and inspects it to make sure the SMTP commands are authorized before passing the communication to the destination server. An HTTP filter performs the same function on all HTTP packets. Firewalls that are capable of application-layer filtering can stop dangerous code at the edge of the network before it can do any damage.

Advantages and Disadvantages of Application-Layer Filtering
Application-layer filtering can be used to stop attacks from sources such as viruses and worms. To the packet-filtering firewall, most worms look like legitimate network traffic. The headers of the packets are identical in format to those of legitimate traffic. It is the payload that is malicious; only when all the packets are put together can the worm be identified as malicious code, so these exploits often travel straight through to the private network because the firewall allowed what appeared to be legitimate application data.

But the advantages of application-layer filtering transcend the prevention of attacks. It can also be used to protect your network and systems from the harmful actions often taken by unaware employees. For example, you can configure filters that prevent potentially harmful programs from being downloaded through the Internet, or ensure that critical customer data does not leave the network in an e-mail.

Application-layer filtering can also be used to more broadly limit employee actions on the network. You can use an application filter to restrict common types of inappropriate communication on your network. For example, you can block peer-to-peer fileexchange services. These types of services can consume substantial network resources and raise legal liability concerns for your organization.

What Is Intrusion Detection?
Intrusion detection is a means of detecting when an attack against a network is attempted or in progress. If you detect an intrusion attempt early enough, you may be able to prevent a successful intrusion. If an intrusion does occur, you must be alerted as soon as possible to reduce the potential impact of the intrusion and to eliminate the vulnerability in your network security.

An intrusion-detection system (IDS) that is located at the edge of a network inspects all traffic in and out of the network and identifies patterns that may indicate a network or system attack. An IDS is usually configured with information about a wide variety of known attacks, then monitors the network traffic for signatures indicating that a known attack is occurring. An IDS can also be configured with information about normal network traffic and then be configured to detect variations from the normal traffic.

A complete IDS includes several layers. One device may be located at the network perimeter and monitor all traffic entering and leaving the network. Additional devices may be deployed on the internal networks, or on routers connecting networks. A final layer of protection is provided by host-based systems in which an IDS is configured on individual computers. The most sophisticated IDS can collect information from all the layers and correlate data to make the most accurate intrusion-detection decisions.

Intrusion-detection systems also provide options for configuring alerts or responses to intrusion attempts. At the very least, an IDS should alert an administrator when an attack is detected. More sophisticated IDSs provide additional responses to attacks, including shutting down or limiting the functionality of the systems under attack.

ISA Server and Intrusion Detection
ISA Server includes intrusion-detection functionality that monitors for several wellknown vulnerabilities. ISA Server detects intrusions at two different network layers. First, ISA Server detects intrusions at the network layer. This enables ISA Server to detect vulnerabilities that are inherent to the IP layer. Second, ISA Server uses application filters to detect intrusions at the application layer. You can use third-party application filters to add more intrusion detection or create your own application filters using the filter application programming interfaces (APIs) defined in the ISA Server software development kit (SDK).

Configuring ISA Server as a Firewall

ISA Server 2004 and Packet Filtering
ISA Server 2004 does not have an option for directly configuring packet filtering. However,ISA Server does operate as a packet filter firewall, inspecting traffic at the network and transport layers. For example, if you define a firewall access rule that enables all protocol traffic from an IP address on one network to an IP address on another network, ISA Server uses a packet filter to allow that traffic. Or, if you configure a firewall access rule that denies the use of the default Telnet port (TCP Port 23), ISA Server will use a packet filter to block that port. ISA Server also enables ingress and egress filtering by default. ISA Server 2000 supports direct configuration of packet filters. If you upgrade to ISA Server 2004 from ISA Server 2000, the packet filter definitions are replaced by access rules.

What Is Stateful Filtering?
When a firewall uses stateful filtering, the firewall examines not only the packet header information, but the status of the packet as well. For example, the firewall can inspect a packet at its external interface and determine whether the packet is a response to a request from the internal network. This check can be performed at both the transport and the application layers.

Stateful filtering uses information about the TCP session to determine whether a packet should be blocked or allowed through the firewall. TCP sessions are established using the TCP three-way handshake, the purpose of which is to synchronize the sequence number and acknowledgment numbers and to exchange other information defining how the two hosts will exchange packets. The following steps outline the process:
1. The initiator of the TCP session, typically a client, sends a TCP segment to the server. The client sends its sequence number and requested that the server provide its sequence numbers (by setting the SYN bit to 1).
2. The responder of the TCP session, typically a server, sends back a TCP segment containing its initial sequence number and an acknowledgment (ACK) of the client’s sequence number. The server sets both the SYN bit and ACK bit to 1. The ACK bit indicates that the server has received the client’s sequence number.
3. The initiator sends the server a TCP segment containing an acknowledgment of the server’s sequence number. Once the client and server have agreed on the sequence numbers, they will use the sequence numbers to track all packets. TCP uses the information to recover from errors, such as packets arriving out of order or packets not arriving.

TCP uses a similar handshake process to end a connection. This guarantees that both hosts have finished transmitting and that all data was received.

A firewall uses this TCP information to perform stateful filtering. When a client on the internal network sends the first packet in the three-way handshake, the server forwards the packet and records that the packet has been sent. When the response comes back from the server, the firewall accepts the packet because it is in response to an internal request. If a packet arrives with only the SYN bit set, or with the SYN and ACK bits set, and the firewall does not have a record of a client request, the firewall blocks the packet.

Advantages and Disadvantages of Stateful Filtering
Using stateful filtering has several advantages. For example, stateful filtering ensures that all network traffic forwarded by the firewall is part of an existing session, or matches the rules for creating a new session. In addition, stateful filtering implements dynamic packet filtering, which ensures that specific ports are available only when a valid session exists. For example, if the Web Proxy filter requests that a Web server respond on Port 1159, ISA Server will listen on Port 1159 for only as long as the connection exists.

However, stateful filtering still does not provide enough protection against the threats to network security. Many of the newest attacks occur at the application level. For example, a client computer may download malicious code in an HTTP packet that is part of a legitimate session. Only application-layer stateful inspection can block these types of attacks.

ISA Server Connection Rules
ISA Server uses connection rules to keep track of sessions. Whenever a packet arrives at the server, ISA Server attempts to associate the packet with a connection rule, based on the protocol, source, and destination. A connection rule has the following attributes:
- Protocol number
- Source (IP address and port/endpoint)
- Destination (IP address and port/endpoint)
- Source address translation (used for NAT connections)
- Destination address translation (used for NAT connections)
- Statistics (number of bytes transferred, last access time)
- Misc. (checksum delta, used when doing address translation)

Configuring ISA Server as a Firewall

Lesson 1: Introduction to ISA Server as a Firewall

Firewalls are deployed to limit network traffic from one network to another. To distinguish between network traffic that should be allowed and network traffic that should be blocked, firewalls use packet filters, stateful filters, application filters, and intrusion detection. This lesson describes this core functionality provided by firewalls and how this functionality is implemented in ISA Server 2004.

What Is Packet Filtering?
A firewall’s primary role is to prevent network traffic from entering an internal network unless the traffic is explicitly permitted. One way that a firewall ensures this is through packet filtering. Packet filters control access to the network at the network layer by inspecting and allowing or denying the Internet Protocol (IP) packets. When the firewall inspects an IP packet, it examines only information in the network and transport layer headers.

A packet-filtering firewall can evaluate IP packets using the following criteria:
1- Destination address The destination address may be the actual IP address of the destination computer in the case of a routed relationship between the two networks being connected by ISA Server. The destination may also be the external interface of ISA Server in the case of a network address translation (NAT) network relationship.
2- Source address This is the IP address of the computer that originally transmitted the packet.
3- IP protocol and protocol number You can configure packet filters for Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), and any other protocol. Each protocol is assigned a number. For example, TCP is protocol 6, and the Generic Routing Encapsulation (GRE) protocol for Point-to-Point Tunneling Protocol (PPTP) connections is protocol 47.
4- Direction This is the direction of the packet through the firewall. In most cases, the direction can be defined by inbound, outbound, or both. For some protocols, such as File Transfer Protocol (FTP) or UDP, the directional choices may be Receive Only, Send Only, or Both.
5- Port numbers A TCP or UDP packet filter defines a local and remote port. The local and remote ports can be defined by a fixed port number or a dynamic port number.

Advantages and Disadvantages of Packet Filtering
Packet filtering has advantages and disadvantages. Among its advantages are the following:
1- Packet filtering must inspect only the network and transport layer headers, so packet filtering is very fast.
2- Packet filtering can be used to block a particular IP address or to allow a particular IP address. If you detect an application-level attack from an IP address, you can block that IP address at the packet-filter level. Or, if you need to enable access to your network and you know that all access attempts will be coming from a particular address, you can enable access only for that source address.
3- Packet filtering can be used for ingress and egress filtering. Ingress filtering blocks all access on the external interface of the firewall to packets that have a source IP address that is logically on the internal network. For example, if your internal network includes the 192.168.20.0 network, an ingress filter will block a packet arriving at the external interface that claims to be coming from 192.168.20.1. An egress filter prevents packets from leaving your network that have a source IP address that is not on the internal network.

Disadvantages of packet filtering are the following:
1- Packet filters cannot prevent IP address spoofing or source-routing attacks. An attacker can substitute the IP address of a trusted host as the source IP address and the packet filter will not block the packet. Or the attacker can include routing information in the packet that includes incorrect routing information for return packets so that the packets are not returned to the actual host, but to the attacker’s computer.
2- Packet filters cannot prevent IP-fragment attacks. An IP-fragment attack splits a single IP packet into multiple fragments. Most packet-filtering firewalls check only the first fragment and assume that the other fragments of the same packet are acceptable. The additional fragments may contain malicious content.
3- Packet filters are not application-aware. You may be blocking the default Telnet port (Port 23) on your firewall, but allowing access to the Hypertext Transfer Protocol (HTTP) port (Port 80). If an attacker can configure a Telnet server to run on Port 80 on your network, the packets would be passed to the server.

Guidelines for Troubleshooting Caching

Caching is an important feature of ISA Server 2004 and, if configured correctly, caching can provide benefits in speed of response and in reduction of bandwidth usage. At the same time, ISA Server caching there are also situations in which you may need to troubleshoot caching on ISA Server. Use the following guidelines when troubleshooting ISA Server caching:

1- If users are accessing the Internet to retrieve objects rather than retrieving the objects from the ISA Server cache, check to see if caching is enabled. To do this, check the cache configuration to ensure that a cache drive has been created. And confirm that the client computers are configured to use the ISA Server computer as a Web proxy server.

2- If only some objects are cached and the cache contents are deleted frequently, ensure that the cache drive is large enough. Cached content may be being discarded due to lack of space. You can use Performance Monitor to check the Total URLs Cached and Total Memory URLs Retrieved. A low number could indicate a cache drive that is too small.

3- If some Web sites are not being cached at all and you have caching rules configured,ensure that the caching rule order is correct. Check to see that one rule is not blocking another rule from being evaluated. Rules are evaluated in the order that they are listed in the ISA Server Management interface.

4- If users cannot retrieve content from specific Web sites, check to see if negative caching is enabled. Intermittent network problems may have caused one negative response to be cached, thereby affecting all subsequent users.

5- If users are receiving outdated content from a particular Web site that is included in a cache rule, decrease the TTL for the caching rule.

6- If objects are being cached but not returned to clients from the cache, check to see if the cache has become corrupted. Use Performance Monitor to check caching statistics. If Performance Monitor indicates that Web content is being cached, but no content is being retrieved from the cache, you may need to clear the ISA Server cache. You can clear the cache by disabling caching and enabling it again.

Configuring Caching

What Are Cache Rules?
In some cases, you may have different caching requirements for specific Web content.You can use cache rules to define the types of Web content that is stored in the cache and how Web content is stored and returned to users from the cache.

Why Use Cache Rules?
The default caching configuration, including the cache settings and the default cache rule, is sufficient for many organizations. If these settings are not modified, the default settings apply to all Web content cached in the ISA Server cache for both forward and reverse caching scenarios.

However, in some cases, you may need to configure a more specific caching configuration.For example, users in your organization may frequently access a Web site, so you may want to configure the cache so that all content from that Web site is cached on the computer running ISA Server. If the Web site contains critical information that changes frequently, you may need to implement the opposite solution, that is, configure the Web site to never be cached.

Cache Rule Settings
When you enable caching on ISA Server, a default cache rule is enabled. You can also configure a wide variety of settings that enable you to fine-tune caching performance on ISA Server. Table 6-3 describes how you can change options to fine-tune caching performance and how the default cache rule is configured.

Managing Cache Rules
After you configure caching rules, you may need to modify the cache rule settings or manage the cache rules. There are several actions that you may need to perform to manage cache rules. These include the following:
1- Modifying settings You may need to modify a cache rule after creating it. To modify the cache rule settings, open ISA Server Management, expand the Cache container, and click the cache rule on the Cache Rules tab. Then click Edit Selected Rule, as shown in Figure 6-12. The configuration options when modifying the rule are the same as the options when creating the rule, with one additional option. When you modify the cache rule properties, you can use destination sets to configure exceptions to the network entities that the rule applies to. For example, if you need to configure a rule that applies to all Web sites except one, you can configure a destination set for the Web site’s URL and add it to the Exceptions list.

2- Managing rule order Just like firewall access rules, you may need to modify the cache rule order to achieve a desired result. When ISA Server receives a Web request, it evaluates the cache rules in order. The first cache rule that matches the client request is applied. For example, you may have a cache rule that specifies the caching criteria for all Internet Web sites and another rule that specifies different caching requirements for a specific Web site. If the caching rule controlling caching for all Web sites is listed before the more specific rule, the more specific rule will never be applied. In general, you should configure the more specific rules so that they are evaluated first. The default caching rule will always be the last rule to be applied. To modify the rule order, click the rule you want to reorder and click either Move Selected Rules Up or Move Selected Rules Down.

3- Disabling or deleting cache rules If a cache rule is no longer required, you can disable or delete the rule. To do this, click the rule you want to modify and then click Disable Selected Rules or Delete Selected Rules.

4- Export and import cache rules Just as with any other ISA Server configuration setting, you can export the cache rule configuration to an .xml file and import cache rule settings. Use this option to create a backup copy of your cache rules before modifying the configuration.