The recent closure of the Open Relay Database as reported by points out how email and spam have changed over the years.  Once upon a time Open Relays abounded and was the main way that spam attacks were launched. Now spam comes and attacks us from various ways from spam bots to NDR attacks.  No longer is Open Relay our main SMTP security issue these days.  In fact Exchange 2003 is not a mail relayer by default.  Nevertheless, while our servers have gotten more secure, the spam impact is rising. As they’ve changed the playing field, we’re using different tools to fight back.  While the built in IMF spam filter in Exchange 2003 sp2 is an excellent spam filtering, there are new hosted solutions that place the burden of filtering on the backs of specialized vendors that can better see the Spam trends.  From vendors such as Postini, Microsoft’s Frontbridge, to the vendor that I personally use, it provides additional filtering in front of your Exchange server.

Hosted Exchange filtering provides several benefits.  The first being that these vendors specialize in seeing the trends of viruses and spam and thus can act on these trends much faster than I can.  Secondly they house the spam on their servers and not mine.  And last but certainly not least, one of the reasons that I chose this was to provide a more secure connectivity to my mail server.  I was able to do this by utilizing my ISA server 2004 to provide a bit more protection for my Small Business Server network. 

Before the change, I could literally see pings from various countries entering my network via the open port 25 that I used to accept inbound email connections.  Using an add on tool to ISA Server 2004, the Firewall Dashboard from Scorpion Software, you could see the various countries and IP addresses: 

Figure 1 – Scorpion Software’s Firewall Dashboard showing various SMTP connections

While attempts to guess a username and password on a mail connection on a network that has passphrases or a password policy that ensures that they are long, strong and not easily crackable at all, should not be a concern to the savvy network administrator, the reality is for many firms is that they would prefer to reduce an exposed attack surface if it’s reasonable to do so.  There have been cases where firms have been subjected to dictionary attacks and have had a password cracked merely to use the mail server and authenticate it to be used in more spam attacks.  These attacks called SMTP auth attacks have increased over the years.  In addition, the concern that I have with my firm located in California with data of California residents, is that should an attacker use a SMTP auth attack and through my own stupidity or misconfiguration, a password is cracked, that event would warrant a event under a law in California called SB1386 whereby I would need to notify clients of my firm’s that their sensitive data may have been breached.

In our case, it is extremely reasonable and extremely easy to limit the connections to our mail server ports with a bit of judicious editing to our ISA server policy that allows connections to our mail server.  The service that I use,
ExchangeDefender only connects to my server from a specific set of IP addresses.  Therefore, to ensure that we only accept inbound port 25 connections from those servers, we will set up rules in ISA Server 2004 to better protect the server and limit SMTP connections to only those 5 IP ranges.  This will then in turn, close down the potential for SMTP auth attacks and other misdirected connections to the port 25 in my server, thus reducing even more of an already limited attack surface via the server.

Our first step in the process is to determine the IP addresses that we need to restrict port 25 to.  The IP addresses are all Class C addresses.  We begin by launching the ISA management console as shown below:

Figure 2 – Default rules as provided by the SBS 2003 “Connect to Email and Internet Wizard”

In my case, my version of ISA server 2004 is installed on the SBS 2003 network server and has a rule wizard that has pre-built the access to the server for email.  I will edit that rule to provide the additional restrictions I need, but I need to remember that should I need to rerun the Connect to Internet and Email Wizard, or CEICW as it’s commonly called, that is inside the Small Business Server network, it will reset these email rules to default.  So at the end of this process, I’ll make sure that I backup the ISA configurations I’ve customized to ensure they are retained.

So we begin by editing the policy and providing the additional IP restrictions so that only the IP addresses from the ExchangeDefender servers can connect to the SMTP connection on my server.  In my example using SBS 2003’s ISA server configuration, it has built for me a SMTP access rule that I will edit.  Double check on the Smtp Server Access Rule and browse to the “From” tab.  From here you can see that the current allowed connections are from the entire Internet.  This is what we will be editing.

Figure 3 – Editing the SMTP server access rule

We will first begin by adding the necessary Address ranges that we need to limit connections.  After clicking on “Add” we are presented with a Network Entities screen.  We now need to click on “New” to add a new category of addresses that we will limit inbound port 25 connections from.  As you can see, you are presented with various ways that you can add different rules sets for access.  Ranging from “Networks” to sets, to various computers, to address ranges and so on.  This makes it easy to add a rule with a specific need in mind.

Figure 4: Defining the Network Entities

We will build a series of Address ranges based on the information given to us by the Hosted Antivirus and AntiSpam provider that we will use to limit the connections.  While we can use several categories of network entities to build the rule, including Address ranges for each range, Subnets for each one, the easiest way is to use the Computer Set rule and include in one set the five ranges that we have been given by the vendor to limit the connections to.  This allows for the best organized rule as all of the vendors IP ranges that he has given us to limit connections to will be included in one spot.  Be sure to add enough descriptive information to the rule set to ensure that you will remember the intent and to document it in your Firewall change log or whatever process you use to document firewall changes.

Figure 5: Using New Computer  Rule Element

When everything is all done, the rules we have built will be included as one set.  We can now easily remove the existing rule of “External” which allows all connections from all locations, with the more restrictive rule that only allows the 5 address ranges that have been specified.  And like all other edits to Firewall rules in ISA, it’s as easy as clicking on the “Apply” button to easily change the rule to our new edited one.
Figure 6:  Applying the new configuration

Last but not least, we need to remember that in the Small Business Server 2003 environment we need to remember that should we re-run the firewall wizard for any reason, any SBS wizard specific rule that we customized before will be reset back to the original once you rerun that wizard.  Therefore documentation of the changes you make, and ensuring that at the end of the process of customization you click on properties of the rule and you export the rule to allow for easy import will ensure that you can easily and quickly get the Firewall settings back as you need them to be.

Figure 7:  Exporting out the changed configuration

In reality for many of us that use the power of ISA 2004 to better protect and report on the Internet connectivity on our SBS 2003 networks, we typically only run the Connect to Email and Internet wizard once when initially setting up the ISA 2004 configuration.  After that first configuration, we tend to edit the rules as we need them and there is typically no need to rerun the setup wizard. 

You can now use or go to any number of port probing web sites and tools ranging from Steve Gibson’s veritable Shields Up on his web site to Microsoft’s portquery tool and see that no longer is your port 25 seen open to the Internet and ready for drive by port 25 password attempts. While you are still fully able to get all of your cleaned and de-spammed email, you are no longer the fully exposed connection you once were.

Before you limit the connections, a port query response comes back with the following:

Data returned from port:
220 Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Mon, 25 Dec 2006 03:06:17 -0800
portqry.exe -n xx.xx.xx.xx -e 25 -p TCP exits with return code 0x00000000.

After you limit the connection, the response comes back as follows:

TCP port 25 (smtp service): FILTERED
portqry.exe -n xx.xx.xx.xx -e 25 -p TCP exits with return code 0x00000002.

Thus providing a bit more protection from drive by SMTP auth attackers.

While I would never say that a firewall should be a “set it up and then forget about it”, typically the ISA 2004 configuration is straightforward enough that typically my only needs for adjusting are when my business needs change or a security stance changes have dictated a change in the firewall.  The rest of the time,  it just keeps doing what it does very well, being a great protection and reporting access tool for my business’ network.

And now, it gave me just a little bit more help in the war against SPAM.

(Now blogged from this location on my blog site, was formerly blogged at another location)

P.S.  as I’ve joked with folks.. the worse thing about all these external hosted spam filtering services is that they make your email boring.


One Response to Using ISA to protect the SBS mail server just a smidge more….

  1. Tim Long says:

    I’ve just been reading the overview of ExchangeDefender at the OwnWebNow web site and it certainly looks like a very impressive solution.

    As an alternative approach to configuring ISA, I always try to avoid editing any of the system-generated rules. I would create a new rule to do what I need, then disable the system rule. That way, it’s very obvious that the default behaviour is overridden and if you do run CIECW later, all you have to do is disable the system rule again. I also recommend using the comments/description area provided on each rule to copiously document what you did.