Microsoft Internet Security and Acceleration Server 2000 in Education Deployment Kit
Stopping Unwanted E-mail and E-mail Attachments from Entering the Institution with ISA Server 2000
Dr. Thomas W Shinder
Debra L. Shinder
Table of Contents
ISA Server 2000 is an advanced application aware firewall. As a sophisticated application aware firewall, ISA Server 2000 examines application layer content of communications moving through it. This means administrators of educational institution networks can use ISA Server 2000’s advanced application layer filtering to help prevent unwanted e-mail, worms and viruses from endangering the campus network.
Educational institutions are more vulnerable than are corporate networks because of the generally open nature of their networks, necessitated by access policies that encourage free flow of information. Yet a worm or virus can crash computers or even shut down the entire network, thus interfering with the access that students, faculty and administrators need to do their work.
In this ISA Server 2000 Application in Education Deployment Kit document, you will learn about how unwanted e-mail, viruses and worms enter the campus network and how they can harm computer networks and the institutions running them. You will also learn how ISA Server 2000 application layer aware firewalls can protect your network from these threats.
ISA Server 2000 application layer filtering firewalls can be placed virtually anywhere on the campus network. This allows a high level of flexibility for institutions that already have an existing firewall infrastructure that they do not wish to replace, making it easy to add another layer of protection by incorporating ISA Server into the existing security strategy.
We will show you where you can place the ISA Server 2000 SMTP filtering firewall on your network and provide step by step details on how to configure the ISA Server 2000 SMTP filtering firewall as a secure filtering gateway to keep out unwanted e-mail and virus/attachments.
Campus networks are under constant attack from external intruders. With many educational institutions engaged in important research, this poses a threat not only to the users of the network, but in some cases to national security. As early as March 2002, Department of Health and Human Services auditors were concerned about security at several university research facilities, due to the possibility of terrorists getting information about hazardous biological and chemical materials.
Lax security on campus networks also results in higher costs (for example, in the form of increased insurance premiums), taking away money that could be spent on academic programs. Productivity is reduced and, in the case of public-funded institutions, taxpayer dollars are wasted.
There are almost as many different types of attacks as there are attackers. However, the three most common attacks that are attempted against networks and network services revolve around three main areas:
A large proportion of the problems encountered on networks today can be traced to one of these issues. Unwanted e-mail, viruses, worms and buffer overflows clog mail servers, disable network services, destroy data, consume available network bandwidth, and cost educational institutions thousands and potentially millions of dollars each year.
Unsolicited and unwanted commercial e-mail (commonly known as “spam”) is one of the greatest problems facing campus networks and the Internet today. Unwanted e-mail leads to the following problems:
It has been estimated that unwanted e-mail messages consume up to 50% of total bandwidth usage on the Internet today. Recent trends suggest there will be an acceleration in the unwanted e-mail volume curve and an increase in the resources required to review, store, report and delete unwanted e-mail messages from mail servers and user workstations. Many educational institutions have already reached a breaking point regarding unwanted e-mail on their mail servers. Unwanted e-mail control and elimination is no longer an optional network activity; it’s a requirement.
The challenge is to determine which e-mail messages constitute unwanted e-mail. You want to block unwanted e-mail, but you also must allow valid e-mail messages into your mail systems. An overly aggressive approach to unwanted e-mail control will result in a high number of “false positives” (legitimate e-mail messages being blocked) and this can have an adverse effect on overall productivity and satisfaction. The only thing worse than having “spam” get through to a user’s mailbox is having an important legitimate message blocked by the e-mail filters so that the user never gets it.
Why block unwanted e-mail at the firewall? You may already have an anti-spam program installed on your mail server and/or spam blockers implemented on client machines. Like any security strategy, however, effective spam control is a multi-layered job. Filtering is a processor intensive activity that can easily eat up the resources of a server. By stopping some of the unwanted e-mail before it reaches the server, you spread the processing load and increase the performance of the server. A three-tiered approach (with filtering at the firewall, server and client levels) is the best way to ensure that as little unwanted mail as possible reaches the user’s mailbox.
There are a number of different methods that can be used to control unwanted e-mail and each of these methods inspect application layer information. In order to be most effective, devices designed to control the influx of unwanted e-mail must be application layer aware. Application layer aware devices can inspect the SMTP messages transporting the unwanted e-mail and evaluate characteristics of the messages, including the following:
Unwanted e-mail can also be blocked by restricting access to your mail servers from specific e-mail addresses of known spammers or from domains known for hosting spammers. You may want to restrict a specific e-mail address rather than an entire domain if legitimate mail also originates with that domain. However, blocking unwanted e-mail based on source mail domain or e-mail address is only a first step in controlling unwanted e-mail, because spammers often change addresses and domains frequently to circumvent this type of filtering. Nonetheless, address and domain blocking are useful components of a good multi-faceted approach to spam control.
Another powerful method used to block unwanted e-mail is keyword matching. Unwanted e-mail can be blocked based on content in the subject line and message body. Unwanted e-mail messages typically contain words never or seldom used in legitimate e-mail. You can leverage this fact by blocking e-mail messages containing targeted keywords in the subject or message body. ISA Server allows you to define character strings (keywords or phrases) that it will search for within the text of the message. If those character strings are found, the message will be marked as unwanted e-mail and blocked.
E-mail attachments can be included with both unwanted e-mail and legitimate e-mail. Attachments can be undesirable for several reasons:
· Downloading large attachments can clog network bandwidth and delay other e-mail from getting through.
· Pornographic pictures and other offensive content are often sent as attachments.
· Some attachments consist of executable files that run when the user clicks to open them.
Executable attachments (including attached documents that contain macros or other embedded executable programs) present a special problem for campus networks and are discussed in the next section on viruses and worms.
You may want to block some attachments and allow others. ISA Server allows you to block attachments based on file size and/or file extension.
Viruses and worms cause a tremendous amount of damage to campus networks today. When the Nimda Internet worm hit college networks a few years ago, some of the smaller institutions (for example, Central Wyoming College) had to completely shut down in order to allow IT personnel to recover from the attack.
The prevalence of high speed Internet connections (cable and DSL broadband) has greatly increased the usability of the Internet for many students and instructors, but it has also resulted in faster spread of viruses, worms and other malicious code. The popularity of wireless networking on campus and availability of low-cost portable computers has made it easier than ever for network users to disseminate viruses either deliberately or accidentally.
Viruses and worm attacks are responsible for:
Colleges and universities are subject to civil litigation and liability if attackers use their computers to launch virus attacks or if confidential information is distributed. If you can’t show that you practice due diligence in your efforts to protect the network, you could find the institution involved in a costly lawsuit. It is not necessary for a plaintiff to prove any intent on the part of the institution; mere negligence can result in an expensive judgment. Educational institutions are also bound by federal and state laws safeguarding the privacy of certain records, and breach of that privacy can result in administrative penalties, fines and even criminal charges.
Historically, worms and viruses were introduced into campus networks by students and employees (internal users). Floppy disks and CDs containing infected files were the original avenue by which exploits got into the campus network. Floppy disks and CDs now represent a minor source of infection. Internet downloads using a variety of protocols are now responsible for the vast majority of virus and worm infestations.
How does virus and worm control at the firewall fit into the campus security plan? It does not take the place of anti-virus software, but “fills in the gaps” that AV programs installed on servers and client systems may not be able to cover. ISA Server 2000 can serve as a front line of defense against malicious code, supplementing whatever AV software you have in place.
Traditionally, campus networks have been less likely than corporate networks to have strong perimeter security. This was due less to ignorance or laziness than to philosophy: collaboration with other outside institutions is vital to research and free access to information is a cornerstone of the educational process. College and university officials today are becoming more aware of the importance of good risk management. However, administrators are often wary about limiting access that students, faculty and staff have come to expect, including remote access.
Tight budgets force many educational institutions to operate with minimal IT staffs, and with few or no full time security experts. In addition, many institutions are running older computers with operating systems that are more vulnerable and harder to secure. The internal network is often a hybrid one, with a variety of client, server and mainframe computers interoperating in the campus environment. Some of these machines, especially high-dollar research computers, may be so obsolete that they are no longer supported by their vendors and cannot easily be updated.
The most common Internet protocol used to download viruses and worms into the network is SMTP, which is used to send e-mail. Virus writers realize that e-mail is a vital function to all business and educational activities and they take advantage of this fact by crafting viruses and worms that spread via e-mail. Both sophisticated and unsophisticated users open e-mail attachments containing 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 of time.
An effective way to prevent e-mail borne attacks is to block all attachments at the perimeter. An application aware device can then examine e-mail attachments and perform one of the following actions:
Attachment blocking should be performed in conjunction with blocking of HTML mail for most effectiveness, since HTML messages allow attackers to embed viruses in the body of the message itself without relying on users to open attachments.
ISA Server can also use application layer inspection for outbound mail. An organization may wish to block outgoing viruses and worms in an effort to protect other Internet connected networks – and to avoid liability. In addition, outbound mail inspection can prevent users from sending attachment documents and other files that contain proprietary or confidential data that should not be disseminated outside the institution’s network.
Attackers use buffer overflow attacks to disable network servers. Unlike the typical virus or worm attack, a buffer overflow cannot be protected against by blocking attachments. Hackers use buffer overflow exploits to disable specific server services with the intent of creating a denial of service – 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.
Traditional firewalls will allow most buffer overflow attacks to go through to the network. Application layer filtering is required to catch most of these attacks. Even then, the application gateway must be properly designed. ISA Server’s intrusion detection system is specifically designed to intercept buffer overflow attacks.
SearchSecurity.com defines a buffer overflow in this way:
“A buffer overflow occurs when a
program or process tries to store more data in a buffer
(temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra
information - which has to go somewhere - can overflow into adjacent buffers,
corrupting or overwriting the valid data held in them. Although it may occur
accidentally through programming error, buffer overflow is an increasingly common
type of security attack on data
integrity. In buffer overflow attacks, the extra data may contain codes
designed to trigger specific actions, in effect sending new instructions
to the attacked computer that could, for example, damage the user's files,
change data, or disclose confidential information. Buffer overflow attacks are
said to have arisen because the C
A buffer, then, represents a contiguous chunk of memory allocated for some purpose. The C programming language doesn’t contain any automatic checks on the boundaries of buffers. Many of its functions don’t perform such checking. Thus, users with some knowledge of C can write programs that try to write data to memory beyond the memory that’s been allocated for the buffer. For example, if a buffer (location in memory) has 16 bytes allocated and a program command is written to copy 20 bytes to that location, an overflow will occur. This makes it possible for hackers to write code to perform whatever actions they want (for example, seizing administrative permissions) and place that code in the overflow area of the buffer.
To an extent, developers can prevent buffer overflows by writing program code in such a way that minimizes the use of C functions (such as strcpy) that don’t check buffer boundaries. Unfortunately, the possibility of buffer overflow can’t be entirely prevented. Buffer overflow attacks can be mounted against many different types of systems using different protocols. A common type of buffer overflow attack targets the educational institution’s Simple Mail Transfer Protocol (SMTP) servers and can stop the inflow of mail. The best way to prevent 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 campus network. An application aware device such as ISA Server 2000 can evaluate the SMTP commands sent through the firewall and stop the attack.
ISA Server 2000 is a sophisticated application layer aware firewall that can help solve the problems of unwanted email and dangerous e-mail attachments. The ISA Server 2000 firewall performs deep inspection of SMTP messages moving through it and blocks dangerous code and unwanted e-mail from entering the campus network.
ISA Server 2000 firewalls use two technologies to protect the e-mail servers on your campus network:
When used in combination, the SMTP filter and SMTP Message Screener become powerful allies in the war against SMTP attacks and unwanted e-mail.
The ISA Server 2000 SMTP filter examines SMTP commands sent by Internet SMTP servers and clients. This application layer filter intercepts SMTP commands and checks to see if they are larger than they should be. SMTP commands that are larger than RFC limits are assumed to be attacks against the SMTP server and are stopped at the perimeter by the ISA Server 2000 firewall’s SMTP application layer filter. You can configure the properties of the SMTP filter to specify a maximum command length for incoming SMTP commands, on a per-command basis. If this length is exceeded, the command will not be allowed through. You can also configure ISA Server to send an alert notifying you when an attempted buffer overflow is detected.
The figure below shows the flow of information and where the SMTP filter blocks the buffer overflow attack.
the figure below shows a partial list of the default commands included with the SMTP filer.
Each SMTP command has a Maximum Length associated with it. This length represents the number of bytes allowed for each command and the default values are based on RFC recommendations for the SMTP protocol. If an attacker sends a command exceeding the number of bytes allowed for the command, then the ISA Server 2000 firewall drops the connection and prevents the attacker from communicating with the corporate mail server. You can use the Edit button to modify the maximum command lengths.
The attack is also reported to the ISA Server 2000 Event Log and an e-mail can be sent to administrators. Many pagers and mobile phones are connected to e-mail systems, so administrators can also be informed via pagers and mobile phone immediately.
NOTE: Feature Pack 1 includes enhancements to improve performance and allow you to set up an SMTP relay that can be authenticated to by external users without allowing spammers to misuse the relay.
The SMTP Message Screener works together with the ISA Server 2000 SMTP filter. The latter is an application filter used to intercept all SMTP traffic arriving on TCP port 25 of the ISA Server 2000 firewall. The filter accepts the traffic, performs deep application layer inspection, and passes it on to the educational institution’s SMTP servers only if it passes inspection based on rules you configure.
The SMTP Message Screener component can filter incoming mail based on the following characteristics:
You can configure ISA Server to generate an alert if mail is received from specific users. In addition, the SMTP Message Screener can be configured to hold the e-mail for later inspection or forward the message to a security administrator’s e-mail box for further examination and analysis.
Figure C shows an example of how the SMTP filter can be configured to block keywords. One of the most common unwanted e-mail messages received on campus networks contains the keyword Viagra. This example shows how to block e-mail containing the word Viagra in the message header (subject line) or body. One of three actions can be taken when the e-mail message matches this rule:
The ISA Server 2000 firewall can function as the only firewall on your network, or you can integrate ISA Server 2000’s powerful application layer filtering protection with your existing firewall infrastructure. Some common ISA Server 2000 network topologies are:
Smaller educational institutions that do not already have a large investment in a current firewall infrastructure may prefer to make the ISA Server 2000 firewall a front-end firewall. The front-end firewall has two network interfaces: a network interface on the campus network and a network interface directly connected to the Internet. All communications that come into and out of the campus network must go through the ISA Server and are exposed to ISA Server 2000’s deep application layer inspection.
The advantages of this configuration include:
The figure below shows the network topology for the ISA Server 2000 front-end firewall placement.
Educational institutions that already have an existing firewall infrastructure may prefer to leave the current firewalls in place and put the ISA Server 2000 firewall behind the current firewalls. This topology allows third party firewalls to provide high speed packet filtering (stateful filtering) before forwarding the remaining packets to the application aware ISA Server 2000 firewall. The network between the third party front-end firewalls and the ISA Server firewall is a perimeter network where publicly accessible servers and services can be placed.
Each third-party packet filtering firewall has two network interfaces: an interface directly connected to the Internet and an interface connected to a perimeter network between the third-party packet filtering firewalls and the ISA Server 2000 application layer aware firewall. The ISA Server 2000 firewall also has two interfaces: an interface on the perimeter network and an interface on the protected internal campus LAN.
Advantages of this configuration include:
The figure below shows the topology of the ISA Server 2000 back-end firewall topology.
The ISA Server 2000 front-end and back-end firewall configuration uses two ISA Server 2000 computers, one as the Internet edge firewall and the other as the corporate LAN edge firewall. The front-end ISA Server 2000 firewall has an interface directly connected to the Internet and an interface on the perimeter network between the firewalls. The back-end ISA Server 2000 firewall has an interface on the perimeter network and an interface on the protected campus LAN.
The advantages of this configuration include:
Please see kit doc Protecting Departmental/Student LAN segments with ISA Server 2000 for more information about Web proxy and Firewall chaining.
The figure below shows the topology for the ISA Server 2000 front-end back-end firewall configuration.
Some educational institutions already have an existing firewall infrastructure that includes front-end and back-end firewalls. These campuses have a large investment in their current firewall infrastructure and prefer to leave them intact. You can still leverage ISA Server 2000’s application layer filtering features by making the ISA Server an application layer filtering proxy. This ISA Server 2000 proxy can be placed on the perimeter network between the front-end and back-end third party packet filtering firewalls or you can place the ISA Server 2000 application layer proxy on the internal campus network.
Advantages of the application layer filtering proxy configuration include:
The figure below shows the topology of the application layer filtering proxy configuration.
The SMTP filter always runs on the ISA Server 2000 firewall computer. However, you can place the SMTP Message Screener on another computer located on a protected network behind the ISA Server 2000 firewall. The SMTP Message Screener can be installed in any of the following locations:
Message filtering requires a significant amount of processing power. For this reason, most organizations prefer to put the SMTP Message Screener on the ISA Server 2000 firewall computer or on an SMTP relay located somewhere on the campus network. This reduces the load on the Exchange server.
The SMTP Message Screener can be installed on an SMTP relay computer on the campus network running the IIS 5.0 or IIS 6.0 SMTP service. The ISA Server 2000 firewall publishes the SMTP relay on the internal network and the Message Screener blocks dangerous e-mail at the SMTP relay computer. The SMTP Message Screener communicates with the SMTP filter to obtain information used to determine which e-mail messages should be considered unwanted or dangerous.
The figure below shows the topology of the SMTP Message Screener on a dedicated SMTP relay configuration.
Many educational institutions prefer to use a “one box” solution in which the SMTP Message Screener is located on the ISA Server 2000 firewall itself. This simplifies setup and management of the SMTP Message Screener and reduces the hardware and software configuration overhead.
In this scenario, the ISA Server 2000 firewall acts as an SMTP relay. The IIS SMTP service is installed on the ISA Server 2000 firewall and processes the incoming SMTP Messages. The SMTP Message Screener filters unwanted e-mail, viruses and attachments and relays the safe e-mail messages to the Exchange Server or third-party mail server on the campus network.
In both this scenario and the one in which the SMTP Message Screener is installed on a dedicated SMTP relay, the ISA Server 2000 firewall can be integrated into an existing firewall infrastructure. The ISA Server 2000 firewall can act as a back-end firewall or an application layer filtering SMTP “proxy” located on the perimeter network. The only requirement is that the front-end packet filtering firewall must forward inbound SMTP messages to the ISA Server 2000 firewall machine.
This is the most popular configuration because of the lower hardware and configuration overhead. The remainder of this document provides detailed step by step procedures for configuring the ISA Server 2000 firewall as a secure unwanted e-mail and virus filtering SMTP relay.
The ISA Server 2000 firewall can be used as an unwanted e-mail and virus filtering gateway. The following steps are required:
· Install the IIS 6.0 SMTP Service on the Windows Server 2003 ISA Server Firewall Computer
· Disable SMTP Service Socket Pooling
· Configure the IIS 6.0 SMTP Service Relay Properties
· Create Remote Domains to Support Your E-mail Domains and Enable Relay for Those Domains
· Install ISA Server 2000 onto the Windows Server 2003 Firewall Computer
· Configure Server Publishing Rules on the ISA Server Firewall
· Configure the SMTP Filter and SMTP Message Screener Properties
The remainder of this document provides detailed step by step procedures on how to configure the ISA Server 2000 firewall as an unwanted e-mail and virus/attachment filtering gateway.
The detailed step by step configuration guidance provided in this document uses Windows Server 2003 as the base operating system. You can install ISA Server 2000 on Windows 2000 and achieve the same level of firewall and SMTP filtering features.
The SMTP Message Screener requires the IIS SMTP service. You need to install the SMTP service because Windows Server 2003 does not install the SMTP service by default. Perform the following steps to install the IIS 6.0 SMTP service:
Socket pooling is a feature designed to increase IIS performance, but when it is enabled, the SMTP service listens on all IP addresses on all adapters installed on the ISA Server 2000 firewall. Socket pooling is enabled by default. You must disable socket pooling to prevent the SMTP service from listening on all IP addresses on all adapters, because socket pooling prevents Server Publishing Rules from working correctly.
It is good practice to disable socket pooling for any IIS service installed on the ISA Server firewall. Perform the following steps to disable socket pooling for the IIS 6.0 SMTP service:
1. Click Start and then click the Command Prompt shortcut. In the Command Prompt window, switch to the Inetpub\AdminScripts folder. Type the following command and press ENTER:
Adsutil.vbs set /smtpsvc/1/DisableSocketPooling 1
2. If the SMTP service is installed and you entered the command correctly, you should see what appears in the figure below.
3. Close the command prompt window.
At this point, the SMTP service continues to listen on all IP addresses on all interfaces. You must configure the service to listen on specific IP addresses to limit the server to listening on a subset of addresses. In the next section, you will configure the SMTP service to listen on the internal IP address of the ISA Server 2000 firewall computer.
The Default Virtual SMTP Server listens for incoming messages to e-mail domains you host. Perform the following steps to configure the Default Virtual SMTP Server:
1. Click Start, point to Administrative Tools and click on Internet Information Services (IIS) Manager. In the Internet Information Services (IIS) Manager window, expand your server name and click on the Default SMTP Virtual Server entry in the left pane. Right click on Default SMTP Virtual Server and click on the Properties command.
2. In the Default SMTP Virtual Server Properties dialog box, click on the General tab. Click the down arrow in the IP address drop down list box. Note the list of IP addresses. You should see entries for your external addresses, internal addresses, and (All Unassigned).
Select an internal IP address. The Server Publishing Rule will forward the incoming SMTP packets to this address.
Click Apply after selecting an IP address.
3. Click the Access tab. There are a number of options available on this tab. Click the Relay button located in the Relay Restrictions frame.
4. The default setting in the Relay Restrictions allows no relay through this virtual SMTP server except for authenticated users. This is a global setting for the SMTP virtual server. We will override this global setting by configuring a Remote Domain on this SMTP virtual server later.
We do not want anyone to have “open relay” access to this machine, regardless of their ability to authenticate. Remove the checkmark from the Allow all computers which successfully authenticate to relay, regardless of the list above. Removing this option prevents this virtual server from being able to relay to any mail domains except for mail domains for which you create Remote Domain entries.
5. Click on the Messages tab. You have the option to limit the size of messages moving through the server, the number of messages per connection, and the number of recipients per message. You can also set a location for the badmail directory, which is the directory where messages not destined for any of your remote domains are deposited. Place this directory on a volume with a generous amount of free space so that your disk does not fill up in the event of an unwanted e-mail flood.
6. Click on the Delivery tab. On this tab, you can configure how long the SMTP relay waits before retrying to send messages to your Exchange SMTP service. This allows “queuing” of SMTP messages on this SMTP virtual server when the Exchange Server is not available. If the SMTP relay cannot immediately deliver messages to your Exchange SMTP server, it will place them in a queue and attempt to redeliver the messages based on intervals set on this tab.
Note that the SMTP relay will continue to resend the mail indefinitely. After the third retry, subsequent delivery attempts are done at an interval based on the Subsequent retry interval (minutes) entry. Even if your Exchange Server is unavailable for a day or longer, the SMTP relay will queue mail for you. When your Exchange Server becomes available, you can restart the SMTP service on the SMTP relay computer and the mail will be delivered to your Exchange Server’s SMTP service immediately.
7. Click on the Outbound Security button. In the Outbound Security dialog box (figure 17), you have the option to configure credentials the SMTP relay can use to authenticate with the SMTP service on the Exchange Server. This feature confers an additional level of security because then you can configure the SMTP service on the Exchange Server to block unauthenticated connection requests.
Click Cancel in the Outbound Security dialog box. We want to allow the SMTP relay to anonymously access the Exchange Server. You do not need to worry about spammers using your Exchange Server’s SMTP service as an “open relay”. The SMTP relay on the ISA Server 2000 firewall only relays messages that are destined for domains you host on your Exchange Server.
8. Click Apply and then click OK in the Default SMTP Virtual Server Properties dialog box.
The SMTP relay server is now configured to block all incoming SMTP messages. All incoming messages to the SMTP relay server are dropped. You do want to relay SMTP messages destined for domains hosted on the mail Server. This is accomplished by creating remote domains.
A Remote Domain is an e-mail domain hosted on the Exchange Server. For example, if you host the e-mail domain internal.net, then you want all e-mail messages destined for users in the internal.net e-mail domain to be relayed by the SMTP relay server to the Exchange Server’s SMTP service on the internal network.
Note that your e-mail domains do not need to be the same as your internal network’s Active Directory domain or domains. The e-mail domains hosted by the Exchange Server’s SMTP service can be configured in the Recipient Policy of the Exchange Server. For example, the Exchange Server might be a member of the msfirewall.org domain, but it can be configured to receive e-mail destined for users in the domain.com and domain.net domains.
You need to create a Remote Domain for each e-mail domain for which you want your Exchange Server to receive e-mail. In the current example, we want to host mail for a single e-mail domain, internal.net.
Perform the following steps to create a Remote Domain for the internal.net domain:
1. Click Start, point to Administrative Tools, and click on Internet Information Services (IIS) Manager. In the Internet Information Services (IIS) Manager console, expand your server name and then expand the Default SMTP Virtual Server node. Click on the Domain node and then right click on it. Select New and click on Domain.
2. On the Welcome to the New SMTP Domain Wizard page of the New SMTP Domain Wizard, select the Remote option. Click Next.
3. On the Domain Name page, type the name of your e-mail domain in the Name text box. Click Next.
4. The new Remote Domain appears in the right pane of the console. Right click the Remote Domain and click on the Properties command.
5. In the Remote Domain’s Properties dialog box, click on the General tab. On the General tab, put a checkmark in the Allow incoming mail to be relayed to this domain checkbox. This option allows mail addressed to users in this domain to be relayed to the Exchange Server’s SMTP service.
You have two options in the Route domain frame:
Use DNS to route to this domain This option allows your DNS infrastructure to route requests to your mail domains based on the MX record entries for these domains. In order for this to work correctly, you must have a split DNS infrastructure that allows the ISA firewall 2000 machine to resolve the names of your e-mail domains to the internal IP address of the Exchange Server computer. If the ISA Server 2000 firewall resolves e-mail domains to the external address of the ISA Server 2000 firewall, the relay will fail.
Forward all mail to smart host This option allows you to enter the IP address of your Exchange Server and have mail for your domains relayed to this IP address. You must put brackets around the IP address. If you do not put brackets around the IP address, the SMTP relay server attempts to resolve the IP address to an IP address.
The Outbound Security button allows you to configure authentication methods the SMTP relay server can use to authenticate with the SMTP service on the Exchange Server. In this example, we will not configure the Remote Domain to authenticate with the Exchange Server because only mail destined for domains under your administrative control are relayed to the server.
Click Apply and then click OK.
6. In the Internet Information Services (IIS) Manager, right click on the Default SMTP Virtual Server node and click the Stop command.
7. In the Internet Information Services (IIS) Manager console, right click on the Default SMTP Virtual Server node and click the Start command.
The SMTP relay is now ready to relay mail to your mail domain. You will need to create a remote domain for each of your e-mail domains if you have multiple e-mail domains.
The next step after installing and configuring the SMTP service on the ISA Server firewall is to install ISA Server 2000 with the SMTP Filter and Message Screener onto the Windows Server 2003 computer. Please refer to the ISA Server 2000 installation instructions included on the CD and http://support.microsoft.com/default.aspx?scid=kb;en-us;331062 for information on running ISA Server 2000 on Windows Server 2003.
You can use a Server Publishing Rule to make your SMTP relay available to external users. One of the main advantages of using a Server Publishing Rule is that it exposes the incoming connections to buffer overflow protection features included with the SMTP filter.
Perform the following steps to create the SMTP Server Publishing Rule:
1. Open the ISA Management console, expand the Servers and Arrays node and then expand the server node. Expand the Publishing node and click on the Server Publishing Rules node. Right click on the Server Publishing Rules node, select New and click on Rule.
2. Enter a name for the Server Publishing Rule in the Server publishing rule name text box on the Welcome to the New Server Publishing Rule Wizard page. Click Next.
3. On the Address Mapping page, enter the IP address of the Exchange Server on the internal network in the IP address of internal server text box. Click the Browse button to the right of the External IP address on ISA Server and select an address on the external interface of the ISA Server firewall that you want to accept the incoming SMTP messages. Select the IP address in the New Server Publishing Rule Wizard dialog box and then click OK.
4. Click Next on the Address Mapping page.
5. On the Protocol Settings page, click the down arrow on the Apply the rule to this protocol drop down list box and select the SMTP Server entry. Click Next.
6. On the Client Type page, select the Any request option. Click Next.
7. Review your selections on the New Server Publishing Rule Wizard page and click Finish.
8. The details of the new Server Publishing Rule appear in the right pane of the ISA Management console.
The ISA Server firewall and SMTP relay are now ready to accept incoming connections from external SMTP servers. All SMTP e-mail messages destined for the remote domains you’ve configured on the SMTP relay will forward these messages to the Exchange Server on the internal network and the messages will appear in the users’ mailboxes.
The SMTP filter and SMTP Message Screener configuration use the same interface, which can be found in the SMTP Filter Properties dialog box. However, the SMTP filter and SMTP Message Screener are two distinct entities. It is possible to use the SMTP filter and not use the SMTP Message Screener and it is possible to use the SMTP Message Screener and not use the SMTP filter.
For example, you can use the SMTP Filter without using the SMTP Message Screener by simply not installing the SMTP Message Screener. The SMTP filter then protects the published SMTP server against buffer overflow attacks, including the SMTP server co-located on the ISA Server 2000 firewall.
You can use the SMTP Message Screener and not the SMTP Filter by using an SMTP packet filter to allow inbound access to the SMTP relay. The SMTP Message Screener examines the incoming SMTP messages when they are accepted by the IIS SMTP service. The SMTP Filter will not be able to protect against buffer overflow attack because incoming SMTP messages accepted via a packet filter are not exposed to the SMTP filter.
For optimum security, you should use the SMTP filter and Message Screener together, to provide both protection against buffer overflow attacks and the ability to block according to message characteristics.
Perform the following steps to configure the SMTP filter and SMTP Message Screener components:
1. Open the ISA Management console, expand the Servers and Arrays node and expand your server name. Expand the Extensions node and click on the Application Filters node. Right click on the SMTP Filter entry in the right pane of the console and click on the Properties command.
2. The General tab is the first thing you see when the SMTP Filter Properties dialog box opens. You can enable or disable the filter by adding or removing the checkmark in the Enable this filter checkbox. Click on the Keywords tab.
3. You can enter a prioritized list of keywords to filter on the Keywords tab. The SMTP Message Screener mediates the keyword filtering function. The SMTP filter does not examine SMTP messages for keywords. Click the Add button to add a keyword.
4. Confirm that there is a checkmark in the Enable keyword rule checkbox. Type a keyword that you want the SMTP Message Screener to look for in the Keyword text box. Note the SMTP Message Screener does not search for whole words; it only looks at text strings.
Select one of the following options in the Apply action if keyword is found in frame:
Message header or body
If the keyword is found in either the message header or message body, then the Action you configure for the rule will be applied.
If the keyword is found in the header (subject line), then the Action you configure for the rule will be applied.
If the keyword is found in the body of the message, then the Action you configure for the rule will be applied
Click the down arrow for the Action drop down list box. You have the following options:
The e-mail message is deleted without being saved or informing anyone that it has been deleted.
The SMTP message is held in the BADMAIL directory in the SMTP service’s folder hierarchy. You can view components of the held message, but the message is not saved in a format that you can easily forward to the recipient.
Forward message to
The SMTP message is forwarded to an e-mail address you configure in this rule. Each rule can have a different e-mail address to which the messages are forwarded. This allows you to forward the messages to an administrative account, from which they can easily be forward to the recipient if found to be acceptable.
Click OK on the Mail Keyword Rule dialog box after entering a keyword and action.
5. The keyword rule appears in the keywords list on the Keywords tab. Click on the Users / Domains tab.
6. You can configure the SMTP Message Screener to block messages based on the sender’s user account or e-mail domain on the Users / Domains tab. Enter a user’s e-mail address in the Sender’s name text box and click Add. The sender’s e-mail address appears in the Rejected Sender’s list. Enter an e-mail domain in the Domain name text box and click Add. The e-mail domain appears in the Rejected Domains list.
E-mail messages processed by the SMTP Message Screener matching e-mail addresses or e-mail domains found in these lists are deleted. These messages are not stored anywhere on the server, nor are they forwarded to any user or administrator. If a message from a rejected sender or rejected domain also contains a keyword matching a keyword rule, and that keyword rule is configured to hold the message, the message will not be held because it is rejected before the keyword search begins.
Click Apply and then click OK. Click on the Attachments tab.
7. You can block messages with certain types of attachments on the Attachments tab. Click Add to add an attachment rule.
8. Confirm that there is a checkmark in the Enable attachment rule checkbox on the Mail Attachment Rule dialog box. You have three options in the Apply action to messages containing attachments with one of these properties frame:
Select this option and enter a name for the attachment, including file name and file extension. Use this option when you want to block a specific file name but you don’t want to block all attachments with that particular file extension. For example, you do not want to block all .zip files, but you do want to block a file named exploit.zip.
It is more common to block all files with a specific file extension. For example, if you want to block all attachments with the exe file extension, select this option and then type in either exe or .exe in the text box to the right of this option.
Attachment size limit (in bytes)
You can also block attachments based on their size. Select this option and type in the minimum size of the file extension you want to block. All files that meet or exceed this file size will be blocked.
Click the down arrow for the Action drop down list box. You have the following options:
The SMTP message is deleted without being saved or informing anyone that it has been deleted.
The SMTP message is held in the BADMAIL directory in the SMTP service’s folder hierarchy. You can view components of the held message, but the message is not saved in a format that you can easily forward to the recipient.
Forward message to
The SMTP message is forwarded to an e-mail address you configure in this rule. Each rule can have a different e-mail address to which the messages are forwarded.
In this example, we’ll select the Forward message to option so that you can see how to enter the forwarding address.
9. When you select the Forward message to option, a text box appears allowing you to enter an e-mail address to which you want to forward the message. However, the ISA Server must be able to resolve the address of the mail domain of this user.
For example, in figure 41 we have entered the e-mail address firstname.lastname@example.org. The ISA Server 2000 firewall must be able to access an MX record for the internal.net domain. The ISA Server firewall forwards the message to the SMTP server responsible for internal.net mail based on the information in the MX record.
In this example, the firewall is configured with an address of an internal network DNS server that can resolve both internal and external network names. The message is forwarded to the internal address of the Exchange server. You must configure a split DNS infrastructure if the internal.net domain is available to both internal and external users.
Please refer to the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Configuring DNS to Support Exchange Server Publishing for information on how to create a split DNS to support SMTP server publishing.
Click OK in the Mail Attachment Rule dialog box. Click on the SMTP Commands tab.
10. The settings on the SMTP Commands tab are mediated by the SMTP filter component. The SMTP Message Screener does not evaluate SMTP commands and it does not protect against buffer overflow conditions. The commands in the list are limited to a pre-defined length. The connection is dropped if an incoming SMTP connection sends a command exceeding the allowed length. In addition, if a command not on this list is sent over the SMTP channel, it is dropped. You can also edit the length of existing commands.
Click the Add button to add an SMTP command to the list.
11. You might want to enter the AUTH command into the list of allowed SMTP commands. This is required if you want to allow external users to authenticate with an SMTP server published via an SMTP Server Publishing Rule. Users will not be able to authenticate with an SMTP server published via an SMTP Server Publishing Rule if the AUTH command is not added to the list and the SMTP filter is enabled.
Confirm that the Enable an SMTP command checkbox is checked. Type AUTH in the Command Name text box. Type 1024 in the Maximum Length Bytes text box. Click OK in the SMTP Command Rule dialog box.
12. The new command appears in the list of SMTP commands on the SMTP Commands tab (figure 44). Click Apply and then click OK.
13. Close the ISA Server Management console.
14. Restart the ISA Server 2000 machine.
The ISA Server firewall/SMTP server is now ready to filter SMTP messages based on the parameters you set for the SMTP filter and SMTP Message Screener.
ISA Server 2000 is an advanced application aware firewall that examines the content of packets moving through it. Educational institutions can use ISA Server 2000’s advanced application layer filtering to block unwanted e-mail and viruses and prevent them from endangering the campus network. In this ISA Server 2000 Application Layer Filtering document, you learned about the problem of unwanted e-mail and viruses, how to place the ISA Server 2000 firewall on your campus network, and how to configure the ISA Server 2000 firewall as a secure unwanted e-mail and virus/attachment filtering gateway.