Problem solve Get help with specific problems with your technologies, process and projects.

Protecting the messenger, part 3: Royal administrator or apprentice?

Protecting the messenger, part 3: Royal administrator or apprentice?

Are you the royal administrator or apprentice of network security in your company? Is security the monarch of your domain or will you end up in exile? Are you supporting false security or will you be thrown in the lion's den, like Daniel? Hackers roam the Internet like roaring lions seeking to devour your confidential data. Will you be steadfast in the allegiance of network security or surrender to the stronghold of hackers?

We continue our four-part series on protecting your mail server with this follow-up to my article "Protecting the messenger, part two" which launched our investigation into your Exchange 2000 Server security. In this mini-series, we will focus on security at the Exchange System Manager level. However, it's important that you understand that layered security requires that you continually address the potential threats against any of the seven layers of the Open Systems Interconnect (OSI) model. Join me on a journey to explore and identify the security vulnerabilities in your network.

Are you logging your e-mail subjects and tracking messages?

Log e-mail subjects and track messages
Your Exchange 2000 Server provides an option to log e-mail subjects, track messages, and store tracking information to a log file (stored in your Exchsrvr<servername>.log folder.) These additional options are not enabled by default. Consider enabling both options to assist you with better message tracking as part of your overall security plan.

As with other logging options, take into account any server performance overhead (i.e., disk, memory, and processor usage) and make sure that your server has the capacity to handle the additional loggings -- in particular, services and protocol logging, which we will cover later.

One of the benefits of message tracking is that you can track (similar to doing a tracert on a IP address) the path that an e-mail takes to other e-mail systems and search by e-mail subjects, senders, and/or recipients. Being able to collect this additional information now can assist you later -- not only in tracing an e-mail security issue, but also assist you in troubleshooting a message delivery problem.

Make sure that you unshare this message tracking folder and restrict read access to administrators only. In your <servername>.log folder in Exchsrvr, you will find the message tracking log file (i.e., 20021118) that you can open with Notepad to view the following fields:
Date, Time, client-ip, Client-hostname, Partner-Name, Server-hostname, server-IP, Recipient-Address, Event-ID, MSGID, Priority, Recipient-Report-Status, total-bytes, Number-Recipients, Origination-Time, Encryption, service-Version, Linked-MSGID, Message-Subject, Sender-Address.

Use Message Tracking Center and define the messages that you want to track in logs moving forward. Increase your log file maintenance to remove log files after 14 days and archive off-site for long-term retrieval. (Microsoft recommends removal of log files after seven days; however, I have found that doubling their recommendations works better for me most of the time.)

To enable subject logging and message tracking, right-click on your Exchange server listed under the Servers container of the First Administrative Group in System Manager. In the General table, click on each option and then set "remove files older than" to 14 days, instead of seven days. You may find that setting the maximum age longer than 14 days is more practical in your Exchange organization.

Remember to hit the Apply button in order for your new changes to take effect.

This is NOT a front-end server
The last option on the General tab is the "This is a front-end server," which allows you to enable your Exchange server as a relay -- that is, an Outlook Web Access -- server. This mode supports client connectivity via the Internet Explorer browser; however, it exposes your Exchange server to a whole new level of security threats.

Don't even think about converting your existing Exchange server to a front-end relay server. Instead, set up your Exchange server to be accessible to your remote users through a Virtual Private Network (VPN) connection. A less desirable option (in my opinion) is to set up a secured and dedicated front-end IIS Web server and enforce 128-bit encryption using the Secure Socket Layer (SSL) over port 443. Port 80 connections should never be accepted to your Exchange OWA server.

Make sure that you update your firewall policy to only permit port 443 through to your front-end IIS Web/OWA server. Block all the other TCP/IP ports and set a maximum connection limitation in your static route (or address translation entry) to your mail server. Avoid using unlimited values for your maximum connections.

A less desirable option is to set up the front-end IIS Web server outside your firewall and configure your perimeter router to only permit port 443 through. In either case, your firewall policy will need to be updated and traffic filtering will need to be done in your perimeter router.

Domain Controller (DC) services on this server
Periodically check the text box "Domain controller used by services on this server" on the General tab to make sure that the name of the DC that manages user access is your AD root (first installed) server. You will want to control which server manages user access in your domain; if this server changes, you want to be the first to know.

Services diagnostic logging
Although Microsoft has made some improvements by enabling more security features in their applications out-of-the-box, no services logging are enabled in Exchange 2000 Enterprise Server, by default. At a minimum, you will need to define the diagnostic logging level for the appropriate services in your organization.

Outlook 2000 Clients
Let's take a moment to review the configuration of your Outlook 2000 clients. I'll begin by setting up a new Outlook client using the startup wizard. Click on the Microsoft Outlook icon that is created after an Office or Outlook installation. Select the "Corporate or Workgroup" option, the Exchange Server, and then to "Manually configure information services." Change the default Profile Name of "MS Exchange Settings". Add the Exchange Server and appropriate Address Books as services for the new profile you created.

Avoid adding other services (such as Internet e-mail, Fax Mail Transport, etc.) to corporate e-mail profiles. Use a dedicated profile for the other services. Once you have specified the Exchange server, mailbox, and performed Check Name, select to "Manually control connection state" and the "Choose the connection type when starting."

Microsoft defaults to automatically detect connection state upon startup, which I don't suggest you do. In manual mode, Outlook will require human intervention to proceed, making it difficult for a hacker's program or process to launch your Outlook automatically. Keep in mind that Outlook will prompt your users to connect or work offline every time they startup their e-mail.

In the Advanced tab, you will notice that you can add additional mailboxes to open under one profile. Make sure that you regularly monitor user mailboxes and identify who has access to open other mailboxes. (I once detected that a certain VP was inadvertently opening up one of my engineer's mailbox without knowing it. This kind of mailbox access must be granted through a formal process.)

An often overlooked setting is the "Encrypt information" for Outlook clients using the network and/or dial-up networking. Make sure that you enable this for all of your users and select NT Password Authentication for logon network security. Change the default offline folder path, file name, and select the Best Encryption option (with your disk compression) to protect your users offline folder. Remember to add the services Global Address Book, Personal Address Book, and Personal Folders (with password) to your newly created profile. Know the Permissions and Roles of your Inbox Properties. In Outlook, go to File, then Folder, and select Properties for "Inbox", then go to the Permissions tab.

How secure are your e-mail communications?

At a minimum, install/import a digital certificate and use Secure MIME (S/MIME) to secure your e-mail communications (content and attachments). Go to Security tab In Options, under Tools and click on Setup Secure E-mail. Type a name for your settings name, select S/MIME for message format, then click on the New button to create your settings. Enable default security setting for message format and for all secure messages. Next, you'll need to choose the digital certificate you installed previously for signing and for encrypting. (Check out Verisign's Go Secure for Microsoft Exchange for more information. Depending on your organization, you may opt to use Exchange Server Security for message format instead of S/MIME.)

Security zone
Select the appropriate security zone for your organization, which will control the behavior of security zone-aware programs (such as Outlook and IE), and reduce the potential harm of unsafe content delivered to your users. Microsoft's default security level for the Internet zone is Medium; however, I suggest that you experiment with the security level High -- which provides the most security -- for each zone. Keep in mind that this security level will affect some of the Web sites that you visit. An often overlooked area is the Trusted Sites zone. You may want to consider reviewing and adding your company's business partner secured (https) Web sites to your security zone and set to security level High. Consider adding non-secured sites that your company does not want users visiting in the Restricted Sites, again with the security level set to High.

It's been my experience that some of these basic steps have often been overlooked by experienced IT professionals. If you're serious about security, you must pay attention to security details and leave no room for hackers.

In the absence of network security, there exists an opportunity for intrusion.

Please write to me or visit my Web site ( and let me know if this article has brought to light any potential weak links in your network.

Luis Medina is the author of "The Weakest Link Series," which offers network managers an opportunity to identify ongoing network security issues. Luis also answers security questions in's Ask the Expert section. Submit a security question to Luis here or view his previously answered Ask the Expert questions.

This was last published in November 2002

Dig Deeper on Network Security Best Practices and Products

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.