Skip navigation

Designing a Protection Frontier to Safeguard your Network

Ever since the Melissa virus hit in March 1999, Exchange administrators have had to be extremely vigilant against virus attacks. Today, antivirus mechanisms must be part of our standard deployment practices, which include protection at each of the entry boundaries into an organization—gateways, client machines, and mail stores. One important antivirus protection boundary is the mail gateway into an organization. The SMTP host that receives and relays inbound mail for your organization should be a focal point of your antivirus measures. Recently, while working on a project with one of my customers, I had a chance to learn about a world-class protection frontier that this customer had deployed. This week, I'll discuss this vital piece of your overall antivirus solution.

The protection frontier concept is key to protecting your environment from inbound viruses. Protection frontier is simply a fancy name for a matrix of SMTP services that attempt to eliminate the threat of inbound (and potentially outbound) viruses. This virus wall serves other purposes as well, such as preventing email relaying, email impersonation, and unsolicited commercial email (UCE—SPAM). Your protection frontier should provide two key features: content scanning and virus scanning.

Content scanning lets you filter inbound SMTP mail based on content and attachment characteristics, not virus signatures. For example, you can scan all inbound messages for attachments with the .vbs (VBScript) extension and eliminate them before they get inside your organization (thus preventing attacks like Melissa). Content scanning should be at the perimeter of your protection frontier and be done before virus scanning. Why? Content scanning is less expensive than virus signature detection. Why go to the trouble of scanning all your attachments for viruses and then end up blocking those messages via content scanning later. By placing content scanning before virus scanning, you can improve the efficiency of your protection measures.

You can perform virus scanning on the same system that provides content scanning or on the same system that provides Exchange SMTP services. When you provide content scanning, virus scanning, and mail relay on the same box, you have a stacked virus wall. This setup is possible because you can configure each component to receive and forward to the next one. The content scanner listens on SMTP port 25 for inbound email, scans messages for suspect content, eliminates it, and passes the resulting messages on to the SMTP-based virus scanner. The virus scanner scans for matching virus signatures and forwards uninfected messages to the Exchange SMTP service (Internet Mail Service—IMS in Exchange 5.5 or the SMTP virtual server in Exchange 2000).

This stacked approach is very cost effective because it negates the need for separate servers for each function. You can configure each component to listen on a different TCP port for SMTP traffic. For example, the content scanner listens on port 25 and forwards to port 8000. The virus scanner listens on port 8000 and forwards to Exchange SMTP services listening on port 6000. This configuration lets all components function on one host.

Other good design practices are also important. You should locate your SMTP hosts inside your first-level firewall in the DMZ and provide multiple virus wall hosts to provide redundancy and load balancing. Also, consider dedicating virus wall servers for both inbound and outbound traffic. By also scanning outbound content, you reduce the chances of your organization being a source of a virus outbreak (you don't want everyone blocking your SMTP server because you're pumping out viruses).

A good protection frontier has many variations. If you're not providing this type of service for your organization, you need to look into whether this type of design is a requirement for you. You need to make sure you're protecting the entry point for email into your organization.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.