Tip

Security 'to-do' list

Security is not a sexy topic, but things can get downright ugly when the executive's password is found out or someone attacks and cripples your mail server.

Often, a company is unable to prioritize security until something terrible happens and the payroll summary mysteriously appears in the break room or your server is getting constantly bombarded with mail or packet bombs. More often, it is this pain that provides the security "wake-up call" for many companies.

The purpose of this paper is to provide a short list of things you can do to protect your servers and messaging environment from attacks.

  • Physical Server Security. As simple as this may seem, you would be surprised as to how many mail servers I have seen in someone's cubicle or in a general area of the building. All production servers should be logged off and behind a locked door of some kind. Do not underestimate the curiosity of your co-workers especially around review time. Depending on the account that is currently logged on, every mailbox could potentially be accessed by anyone who could walk up to the server and use the keyboard.
  • Network Security. In a word, Firewall.
  • Password Security. By enforcing strong passwords and regular change intervals you can make it more difficult for hackers to collect passwords. Also, use SSL to encrypt the usernames and passwords for your HTTP, POP, IMAP and (outgoing user) SMTP authentication.
  • Antivirus. This area has

    Requires Free Membership to View

  • shifted into the security model as an outbreak or malicious attack could cripple your systems. There are three areas of major concern we will discuss: SMTP, the Exchange Store and the client machines.
  • SMTP Relay. An open relay invites spam, jeopardizes the stability of your environment and could potentially get you blacklisted from other domains as an open relay server.

Physical Security
As mentioned earlier, there should be physical security between your Exchange servers and the rest of the population. This means a locked door of some kind that restricts access to the machines. Also, there should be some type of monitoring system in place to track changes to the server and access. Perhaps this simply means a clipboard that each administrator uses to record the time and day when they use the server console or reboot the server. Auditing should be turned on and each administrator should be using their own account and not a shared account. If you do not adhere to these "rules" then you will have no idea who rebooted the computer in the middle of the day or if someone is intentionally or accidentally crashing the systems.

Firewall
It is incredibly important to provide some protocol separation between your Exchange server and the Internet. In the event that you are connecting to branch offices or remote offices that are connecting to the Internet without a good firewall, then you may also need to separate your servers from those remote offices.

At a minimum, we are trying to protect our server from UDP and TCP attacks. Packet filtering and blocking is the bottom-line requirement. There are several acceptable ways of protecting your network and allowing access to the Exchange servers, but we will start with the most sophisticated method that allows application filtering and monitoring.

Microsoft ISA Server
Within your DMZ, you can place an ISA server. This box will provide firewall and proxy cache access for your clients. This server can do some incredible things with application publishing including the ability to "proxy" MAPI requests to the Internet without exposing your Exchange 2000 server. It also provides a mechanism for content scanning in order to accept mail and scan it for attachments or keywords. It can then send the mail to your Exchange Server in your private network.

Exchange 2000 Front End Server
Exchange 2000 now supports a server configuration that allows clients to access their mailboxes and Exchange content through a central server. This server acts as a relay for the client. When a FE server is placed in your DMZ or otherwise accessed by a POP, IMAP or HTTP client, the request is relayed to the appropriate backend server automatically.

Firewall Appliance or Server
Just about any firewall will allow packet and port filtering in order to protect your network and Exchange environment. While this is a good start for protecting your servers, it falls short of complete protection since you have to open ports to allow access to the data in your private network. For example, port 25 must be opened to allow for SMTP traffic, port 80 for HTTP.

By the time you open the necessary ports for HTTP, POP, IMAP and SMTP access you have opened many of the well-known ports and have invited outsiders to attempt hacks into your systems.

SSL
If you are using the HTTP, POP or IMAP functionality to allow access to your mail servers, you need to make sure that you have enabled SSL on each of these protocols, including the virtual SMTP server you are using for outbound mail for your POP and IMAP clients. If you are allowing those protocols and not requiring SSL, then you are letting your users send their usernames and passwords as clear text over the Internet.

The first thing you need to do is establish a Certificate Authority in your organization and request a ticket for your server. The ticket will refer to the DNS name of the server so that it matches the name you will request. The following articles discuss how to apply the ticket and secure your web services: http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q320291.

From within the Exchange 2000 protocol item in the System Manager, you should also associate your ticket with the IMAP and POP Services. To lock down the SMTP service, you need to be more careful since this service affects mail routing as well. An excellent article that details the processes for these services and the overall process can be found at http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q319574.

Antivirus
This is one of the most important aspects of security and something that is often overlooked. There are three areas of protection you need to consider:

  • Inbound (outbound is also a good idea) SMTP mail scanning.Third-party tools can be purchased that run on Exchange 2000 or on a separate box to collect, scan and forward SMTP messages. I highly recommend the Sybari Antigen for this purpose because of it's sheer speed and the fact that it comes with multiple scan engines, which are very helpful for new viruses.
  • Store Scans. You should also plan on a tool to scan the Exchange stores periodically for viruses in the public and private stores. Again, Antigen is a great tool for this as it uses the new Exchange 2000 API and can not only scan the stores, but monitor the X.400 and MTA services as well for signatures.
  • Client Protection. One of the reasons virus outbreaks can be so devastating is many were written to automatically use the address book to propagate messages out to those we know. You would open a message from a friend just to find out that it contained a virus. There are several add-ins to help protect the client machines from known viruses, but one of the best approaches is a free tool called the Outlook Security Patch. Outlook 2002 has this feature built in, but it is a separate download for Outlook 2000. When this tool is installed, programmatic access to the address book will be blocked. In addition, you can block access to file types as well including .EXE and .COM files and other attachments. this will greatly reduce your risks from an internal outbreak.

Open SMTP Relay=BAD
If you upgraded your Exchange 5.5 server or if someone changed the default Exchange 2000 settings, your server may be an open relay. What this means is that your server could be used to send messages for spam purposes. This is also bad for a number of other reasons, including the embarrassment when your server is used to send unsolicited spam mail for diplomas or "Hot Asian Babes." Also, this added traffic could cripple your server or your network and cause your company e-mail to bounce or sit in queues for days. On top of that, there are services on the Internet that detect and report open relays. Some companies use these blacklists to ban mail from certain domains. If your server is detected to be an open relay, you may find yourself unable to send mail to certain domains. Some of these services detect that Exchange is an open relay even though it may be closed. Here is an article that describes this aspect in more detail: http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q304897 By default, Exchange 2000 required authentication in order to relay. If you have a requirement to use Exchange 2000 as a relay server, we recommend that you read this article for specific instructions on how to make sure it is secure: http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q293800

You can take steps now to make your Exchange environment more secure. You are far better off doing these things now rather than later.

Steve Bryant is a Microsoft Exchange Most Valuable Professional and has spent the last several years designing and securing Exchange and Active Directory environments. He is the editor and a regular contributor to http://www.outlookexchange.com, an on-line resource for Exchange administrators and system designers, as well as an author for Exchange & Outlook Magazine and .NET Magazine.

This was first published in April 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.