CipherTrust's IronMail

Organizations struggle to find the best way to secure email systems. A good messaging security plan should include multiple levels of protection. Such an approach means combining several pieces: antivirus tools, content-scanning systems that can block email that has particular characteristics, spam-blocking utilities, and network security tools. Microsoft Exchange 2000 Server and Exchange Server 5.5 provide some of these capabilities, and third-party vendors offer a wide array of solutions, but someone has to integrate all these products into the messaging system, configure them, and manage them. Understandably, already-busy administrators would like a simpler alternative.

Better Security Through Appliances?
CipherTrust, a 3-year-old Atlanta-based company, thinks that the answer is to package security services—including a filtering SMTP proxy, antispam tools, a virus scanner, and Secure Sockets Layer (SSL) proxies for IMAP, POP, and HTTP Web mail—in an appliance that sits on the network perimeter. The appliance can do all the heavy security lifting, letting the messaging system concentrate on routing and delivering messages. CipherTrust offers these features, along with a set of policy-management tools and an extensive reporting facility, in a pair of appliances for midsized to large enterprise networks.

The company's IronMail 110 is a 1U (1.75") rack-mount unit with one disk, power supply, fan, and network interface; the IronMail 210 is a 2U (3.5") unit with hot-swappable disks, redundant power supplies, and dual NICs. Both units run a customized version of the OpenBSD OS, which is well regarded for its security and stability. In addition to blocking buffer overruns and other common attacks, the IronMail software provides

The IronMail's license key controls the appliance's feature set. You can purchase additional features and add the corresponding keys at any time; the appliance then updates its interface and shows only those capabilities you have access to.

The appliance approach has some interesting benefits: Putting the messaging system's security functionality into a separate appliance eliminates the requirement to install software or change the configuration of your Exchange servers and offloads security-related message processing to a separate computer. But does this approach work? I tested the IronMail 110 on my production mail network for about 6 weeks. Here's what I found out.

IronMail Setup
Setting up the appliance is straightforward; one power cord and a network connection are all you need. Although the unit has VGA output and USB and PS/2 ports, you typically configure the IronMail through its Web-based interface. (A command-line interface, intended primarily for maintenance tasks, is also available.) By default, the appliance uses a fixed IP address of 192.168.0.254 and requires an SSL connection on port 10443. I used the default administrator password and the Web interface (which requires Microsoft Internet Explorer—IE—5.0 or later) to create an administrative account.

The IronMail setup wizard helps you configure the SMTP settings for your network. IronMail uses a queuing system that lets you specify which operations you want to use on your messages and the order in which you want the appliance to apply them. I activated all the available queues and changed my firewall's settings to point to the IronMail's IP address. After sending a few test messages, I opened IronMail's Dashboard, which Figure 1 shows, to make sure the queues were working properly. I used the Anti-Spam tab to turn on the maximum level of spam blocking, then went about my ordinary mail routine.

Initially, I had trouble making my firewall correctly route inbound SMTP connections to the IronMail appliance. The fix involved changing the IronMail's LAN IP address; doing so required a reboot, but the appliance was back up and in service after about 2 minutes. Inbound mail then flowed as usual, and the Dashboard soon reflected that the appliance was scanning inbound and outbound messages for viruses and had intercepted some spam.

The Dashboard didn't show the number of messages processed since the last time the device was rebooted. I expected to see a summary of how many messages the IronMail inspected, how many it classified as spam, how many contained viruses, and so forth. This quirk made the Dashboard more of a curiosity than a serious monitoring tool. The logs, however, accurately reflected message flow.

Spam and Virus Blocking
I get from 10 to 30 spam messages per day, so I was eager to test the IronMail's antispam features. For spam detection, the IronMail supports Vipul's Razor distributed spam reporting network (aka SpamNet) as well as the Mail Abuse Prevention System's (MAPS's) Realtime Blackhole List (RBL), header analysis, Rhyolite Software's Distributed Checksum Clearinghouse (DCC) service, reverse DNS lookups, and user spam reporting.

The RBL is a list of IP addresses that belong to known or suspected spammers. By using the IP address of an inbound connection to query the RBL, the IronMail software can determine whether the message is coming from an RBL-listed host. My tests didn't reveal any RBL-tagged spam, probably because my ISP uses the RBL to filter inbound SMTP traffic.

A proprietary set of header-analysis tools looks for bogus information in the message headers—a common sign of spam. The IronMail's header analyzer looks for forged dates, sender addresses, domains, or message IDs and for missing To, From, or Subject headers. Each missing or forged item adds a user-defined number of points to the message's score. When a message's score exceeds your threshold, IronMail tags the message as spam. The default settings tagged an unacceptable volume of legitimate mail as spam, so I turned off this filter after a few days.

The DCC service lets individual users or servers report spam messages to a central DCC server. When the number of reports for a particular message exceeds a threshold you set, the central server tags the message as spam. DCC clients such as the IronMail can query the DCC server to determine whether it has identified a specific message as spam. The default DCC score settings flagged many of my legitimate messages as spam, but I was able to fine-tune the settings to reduce the number of false positives. CipherTrust is investigating ways to improve the DCC process to eliminate false positives altogether.

Reverse DNS lookups let the IronMail tag as suspicious any incoming connection whose IP address can't be resolved. When I enabled this option, I found that a surprising amount of mail traffic, mostly from mailing lists, was flagged as spam. I had to turn off this check.

User spam reporting lets users forward spam messages to the appliance for inclusion in the spam filter list. To make this method work, you need to use the SMTP address that you gave the appliance to set up an Active Directory (AD) contact or custom recipient for spam reporting in the Global Address List (GAL).

You can specify what happens to the messages that each detection method catches. The IronMail can tag the message subject with a user-defined string, delete the message, shunt it to a quarantine queue, or generate a log entry and let the message through.

I set separate subject-line tags for different detection methods so that I could see which filters the software applied to which messages. After I tweaked the filters, the IronMail classified more than 200 messages as spam over the next week. Of those, about 85 percent actually were spam. That's solid performance, and the IronMail software let me easily adjust settings to the desired level of aggressiveness.

The ability to set a subject-line tag for each type of spam lets you easily use Microsoft Outlook rules to filter spam. However, I found that the IronMail's initial filter settings blocked too many legitimate messages. For example, DCC filtering tagged messages from The New York Times and The Wall Street Journal news-alert services as spam, and the reverse DNS lookup blocking stopped most mail I was receiving from a discussion list that Microsoft's Office group runs. Interestingly, the IronMail didn't report catching any spam through the Razor network. This finding might have been a result of the IronMail's queue approach to message filtering. A message that one filter rejects or tags isn't queued for evaluation by other spam filters, so the Razor filter wouldn't have had a chance to tag spam if the other filters did so first.

I could have set the filters to quarantine rather than tag messages. However, I would then have had to use the Web-based interface to review the quarantined messages. That capability is useful for small sites, but it isn't something that administrators of a 50,000-seat Exchange shop are likely to want to do.

I had one serious problem, which was of my own doing but annoying nonetheless. My mail servers are set up to accept mail for several inbound domains, and I use Exchange 2000's relaying-control features to let them do so without opening relaying to the world. The IronMail uses one check box to control relaying; if you select that check box, you tell the device to act as an open relay. You can control which domains are treated as inbound, but neither the interface nor the documentation make that clear, and you apparently can't configure the IronMail to let only authenticated users relay. Because I set up the appliance as a relay, a couple of the Internet's automatic relay blackhole scanners blocked my server's IP address, and I had to manually reset the relay configuration and request a rescan.

The IronMail's antivirus feature uses the Sophos scanning engine and quarantined all infected messages presented to it. Inexplicably, my unit was set by default never to automatically check for updates, but checking for new updates manually is easy. When I turned on automatic signature updates, I found that the default interval is 24 hours. That's a long time when a virus is spreading, so I'd suggest reducing this interval.

Policy-Based Management
Although most organizations have ad-hoc email policies in place, Exchange's tools for controlling who can send mail and under what conditions are relatively weak, and setting policies that consistently apply to all email users is difficult. In this area, the IronMail software shines. The appliance offers a wide range of policy controls, including the ability to

You can also specify recipients or recipient domains that are permitted to bypass the policy restrictions. Email sent to such a user or domain can skip all defined policy checks, which is useful if you use SMTP to move mail between different parts of your organization. However, I would prefer an expanded feature that provides finer-grained control by acting more like a Web proxy, with individual users allowed to bypass policy checks based on the credentials they use to authenticate to the SMTP server.

Monitoring
In addition to the Dashboard, the appliance provides a broad set of monitoring features. After you set policies that log mail actions, you can use either FTP or the secure copy command (scp—http://www.openssh.com) to export those logs, either as Internet-style log files or as comma-separated value (CSV) files, to a host. You can also specify events that trigger alerts. However, those events are limited to health reports for the IronMail services running on the appliance—you can't get notification of quarantined virus messages, for example. You can get alert notifications through email, pager, or SNMP traps.

I wish CipherTrust had integrated its product with the Microsoft Operations Manager (MOM) and Windows Management Instrumentation (WMI) standards instead of generating only text-format files. And because the IronMail line isn't based on Windows, you can't specify a program to run when a certain condition occurs.

Imperfect but Impressive
When I heard about the IronMail line of products, I was skeptical that an integrated appliance would be a better security solution than selecting individual products. Concentrating security services in one device would probably make them easier to manage, but I thought I'd prefer the flexibility to mix and match multiple services. However, I was impressed with the ease of management that the IronMail's software offers. All the features share a clean, discoverable interface, and because the IronMail is Web-based, I could manage the device while I was on the road. I was also impressed by the appliance's broad range of functionality, particularly by the capability and flexibility of the policy and antispam features.

Nevertheless, this product isn't perfect. The spam filters are sometimes overzealous, and the relaying problem I encountered could have been prevented with the addition of a simple "Are you sure?" confirmation dialog box. The documentation is skimpy (although CipherTrust is revamping it and preparing a line of online and classroom training courses). And when I went to the support site, I couldn't find any support resources that didn't require a support package (I suspect most customers will choose the annual maintenance package, however).

But when you factor in the cost of individual security packages, servers to run them on, maintenance, and management, the IronMail becomes attractive. If you need enterprise-strength security, monitoring, and antispam features, the IronMail products are well worth investigating. For smaller organizations, even the basic feature set, which doesn't include the optional policy and antispam modules, will probably be worthwhile.