ExchangeServer ch8

The Expert's Guide for
Exchange 2003
Preparing for, Moving to, and Supporting
Exchange Server 2003
by Steve Bryant
viii
Books
Contents
Chapter 8 Exchange Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Identifying Security Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Reducing Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Segregating Your Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Exchange Server Edge Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Securing Authentication and Controlling Protocol Access . . . . . . . . . . . . . . . . . 147
Pop and IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
SMTP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Securing the Data Stream and the Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Securing the Email Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Digital Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Securing Servers and Dealing with Harmful Email Messages . . . . . . . . . . . . . . . 158
MBSA . . . . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
MBSA 2.0 . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Hardening the OS . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
URLScan . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
SCM . . . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Server Patch Management . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Windows Update . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Software Update Services . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
SMS 2003 . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Dealing with Harmful Email Messages ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Managing SMTP Relays . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Preventing Virus Outbreaks . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Preventing Unsolicited Email . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Outlook’s SmartScreen Function ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Exchange Server 2003 Antispam Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
IMF . . . . . . . . . . . . . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Third-Party Solutions . . . . . . . ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Protecting the Exchange Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
142
Chapter 8:
Exchange Security
Welcome to the final chapter of The Expert’s Guide for Exchange 2003. I’ll complete this book with
probably the most important topic for today’s Microsoft Exchange administrator (except for disaster
recovery): security. I’ve designed this chapter to provide the information you need to protect your
Exchange environment from malicious attacks and security breaches – and to offer some ideas and
strategies that can help you secure your environment before vulnerabilities become problems.
My goal is to discuss potential security concerns – along with solutions that design or redesign
your Exchange environment to protect your company’s assets. Exchange security is a large topic that
many books and white papers address. Although space limitations keep me from covering overall OS
hardening strategies and detailed scenarios for every situation, I’ll discuss some of the major expo-
sures of unsecured systems. I’ll then cover five key areas, illustrating approaches you can take and
offering configurations you can use to secure your Exchange system.
I’ll first address reducing the number of protocols you use, then cover how to partition your
environment to significantly reduce your exposure. I’ll discuss how to protect authentication
credentials and control protocol access. Next, I’ll consider ways to secure data transmission for
privacy and data integrity. Finally, I’ll review the essential tasks of locking down your servers and
dealing with harmful email messages (e.g., unsolicited email messages, email messages infected with
harmful attachments). All of these strategies will help protect your environment as you face the
challenge of balancing access and security.
Over the years, various vendors, other authors, and I have collected most of the information and
many of the tips you’ll find in this chapter. Some of the information comes directly from Microsoft
books and white papers. I especially recommend two Microsoft white papers, one specifically about
Secure MIME (S/MIME) – Quick Start Guide for S/MIME in Exchange Server 2003 – and the other
about securing Exchange Server 2003 through security policies – Exchange Server 2003 Security
Hardening Guide. I also recommend Paul Robichaux’s books Secure Messaging with Microsoft
Exchange Server 2003 and Secure Messaging with Microsoft Exchange Server 2000. You should also
review the following Microsoft white papers about Exchange security:
• Exchange Server 2003 Message Security Guide
• Slowing and Stopping E-Mail Transmitted Viruses in an Exchange 2003 Environment
• Exchange Server 2003 Transport and Routing Guide
You can reach many of these and related documents through http://www.microsoft.com/technet
/prodtechnol/exchange/2003/library/default.mspx. You’ll find that each of the white papers listed is
very specific in nature. I’ll use this chapter to paint a larger security picture on a broader canvas.
Brought to you by Quest Software and Windows & .NET Magazine eBooks
Chapter 8 Exchange Security 143
Identifying Security Problems

As you know, security threats are real and the results of successful attacks can be catastrophic.
Keeping your environment secure is an ongoing process that requires time, effort, and current
knowledge about tools and risks. Few businesses assign much time or money for security until it’s
too late and a productivity outage occurs.
Companies that have started a security program should understand that help is available and
that administrators can ask for it when needed. For example, you should check out the Microsoft
newsgroups. You can watch the posts for security concerns and updates and submit your questions.
In addition, check the Microsoft Exchange Web site and the Microsoft Security Web site for update
notifications and alerts.
• http://www.microsoft.com/security
• http://www.microsoft.com/exchange/techinfo/security
• http://www.microsoft.com/exchange/library
Many security threats and concerns can affect your messaging environment’s stability and your
users’ productivity. Any of you who’ve watched the logs on your company’s firewall or even at home
understand what’s out there. The Internet has always been risky for unprotected systems, but now it’s
lethal – and the days of dual-homing an Exchange server on an unprotected link are gone.
Doing so would expose your systems to port sniffers, Denial of Service (DoS) attacks, Internet
Control Message Protocol (ICMP) and Universal Database (UDB) flood and SYN attacks, and address
spoofing. To make matters worse, even if you’re protected by a good firewall, you’ll need to put
processes in place to protect your systems from virus outbreaks, spam, beacons, phishers, and
unauthorized access – as well as from new attacks and vulnerabilities. Lastly, you’ll need to figure out
what to do about security for offline folder store (OST) and personal folder store (PST) files on
mobile equipment, telephones, and PDAs.
Reducing Functionality
As simple as the concept of reducing functionality is, administrators rarely implement this approach.
In some cases, software vendors don’t encourage the reduction. The trend has been to increase
access and to provide more connection options for users. The truth is that increased access and
functionality is counterproductive for security. Reducing functionality reduces exposure.
You need to list your organization’s specific connectivity requirements and make an effort to
reduce the number of protocols you use. By disabling unused protocols, you can dramatically
reduce your exposure to various types of attacks and vulnerabilities. New Exchange Server 2003
environments are more secure than upgraded systems (the same is true for new OSs as well) because
environments inherit protocol settings during upgrade processes. If you upgrade from Exchange 2000
or Exchange 5.5, you should pay particular attention to this section of the chapter.
Let’s start with a couple of simple questions: Can you limit your Internet access to HTTP Secure
(HTTPS)? Can your company can get away with a single port for remote and Internet access to email?
I ask because you can now use HTTPS over TCP (port 443) for online access and offline synchro-
nization of email. Microsoft also has improved Outlook Web Access (OWA), which now offers
compression features, notifications, and encryption, as well as junk-email management.
144 The Expert’s Guide for Exchange 2003
Moreover, you can use a single secured configuration for all communications to your environ-
ment and run all HTTPS packets through a reverse-proxy server or a router that uses stateful packet
inspection. With HTTPS, you have multiple access methods – including OWA, Outlook with RPC-
over-HTTP, Outlook Mobile Access (OMA), and synchronization (e.g., ActiveSync) with PDAs. The
result is a much simpler design that uses fewer protocols and is therefore easier to monitor and
troubleshoot. Moreover, when you put such a system into place behind equipment and software that
performs stateful packet inspection, you can better monitor and track access. You require a total of
just two inbound ports for mail: port 443 for HTTPS and port 25 for SMTP.
Segregating Your Network

Let me discuss Internet connectivity a little further. One point about security that I’ll emphasize is that
you never want to allow any type of connection directly to your production servers. Instead, layer
your communications and segregate traffic wherever you can.
For example, Microsoft Internet Security and Acceleration (ISA) Server and Novell’s
BorderManager products can act as buffers between the Internet and your mailbox or front-end
Exchange servers. Other reverse-proxy servers – including open-source servers and hardware
appliances – can provide screening, monitoring, forwarding, and proxy services for inbound requests.
In addition, outsourcing companies such as Postini and MessageLabs can accept email messages on
your behalf, clean them, then forward them to your servers. You can set up basic IP rules from your
environment to accept email messages from the email processing company only. No more Directory
Harvest Attacks (DHAs) or port scans on port 25. No more worries about mail relays or sacrificial
servers placed to process inbound SMTP messages. Of course, those services have a price, but I’m
sure you get my point: Protection from the Internet means no direct communications.
Exchange front-end servers are great for providing a single namespace for your environment. If
you have five mailbox servers and you want to channel all of your HTTP, SMTP, and POP traffic to a
single server or use a single namespace such as Email.company.com, you need a front-end server to
proxy your requests. (Keep in mind, however, that a front-end server offers little in the way of
security and nothing at all for Outlook clients.)
Some companies I’ve worked with allow connectivity only through VPNs. VPNs offer security in
that they’re usually proprietary and require specialized client software. Unless you link your VPN
solution to Active Directory (AD) or manage it carefully with complex passwords and localized key
devices such as smart cards or SecurID, terminated employees could potentially continue to connect
and gain access to systems. Moreover, you shouldn’t introduce unprotected remote systems into the
production environment without careful consideration of virus signature updates and OS patch
updates. VPNs for Exchange email alone probably aren’t the best solution for your network or for
security.
Instead, consider a layered path into your network, such as the path Figure 8.1 shows. It includes
an intelligent firewall system such as Microsoft’s ISA server to detect suspicious network traffic before
it hits your Exchange environment.
Figure 8.1
Layered path into the network
Por Exchange
t 11 Inva
0 comlid HT
Server 2003
man TP
ds
Port 443
Port 25
Internet
21 TP
OWA users Port SM
lid ands
va
In omm
c Exchange Server
Outer firewall Reverse-proxy Inner firewall 2003 performs the
blocks unwanted server accepts and accepts the authentication and
Internet SMTP traffic bridges SSL bridged, accepts or declines
Servers sessions and drops SSL sessions the session
invalid commands
You have several choices for stateful inspection tools, including Microsoft ISA Server and tools
from CheckPoint Software Technologies, Cisco Systems, and Novell. These tools can detect suspicious
or malformed packets and drop sessions before any communication with the Exchange environment
begins.
You can add a layer between the Internet and the production servers in several ways. Unless you
have more than one mailbox server, the border server in the DMZ can communicate directly with
Exchange Server 2003. Otherwise, the border server must communicate with an Exchange Server
2003 front-end server, as Figure 8.2 shows.
Figure 8.2
Deploying an Exchange Server 2003 front-end server Exchange
Mailbox servers
Exchange
Mailbox servers
Por Inva
t 11
0 comlid HT
man TP
ds
Port 443
Port 25
Internet
21 TP
OWA users Port SM
lid ands
va
In omm Exchange Server 2003
c
Outer firewall Reverse-proxy Inner firewall front-end servers
blocks unwanted servers accepts and accepts the Exchange Server
Internet SMTP traffic bridges SSL bridged, 2003 performs the
Servers sessions and drops SSL sessions authentication and
invalid commands accepts or declines
the session
If you have multiple internal servers, you’ll need to take advantage of at least one Exchange
Server 2003 front-end server to handle and proxy the requests to the appropriate back-end or
mailbox server.
For each of the protocols you must allow from the Internet, you’ll need a border device or server
to handle the traffic. If you need to allow POP, IMAP, SMTP, and HTTP, you might need to establish
multiple border servers or a firewall that can intelligently monitor each of the protocol streams for
improper traffic. Moreover, the solution you put into place must be able to drop the session and
handle floods, port scans, and other attacks. If you can reduce your communications protocols to
HTML only, you have more options because more devices are available to screen mail and proxy
HTML requests.
Exchange Server Edge Services

One of the strengths and limitations of Exchange Server is its reliance on AD. And SMTP traffic
particularly relies on AD. With Exchange 2003, Exchange 2000, and Exchange 5.5, Exchange servers
(even front-end servers) must have a stable, reliable connection to the Directory Service (DS). Placing
an Exchange server in the DMZ to handle inbound mail flow is both risky and tricky because you
must establish direct access to AD from devices in your DMZ.
For inbound SMTP traffic, many companies currently use Message Transfer Agent (MTA) products
(e.g., Sendmail, Qmail) and antivirus screening products (e.g., from Symantec, McAfee) to shield
Exchange. Many diehard Exchange shops I work with implement fault-tolerant Sendmail servers in
the DMZ to collect, scan, and forward email messages into their environment, as Figure 8.3 shows.
Microsoft is currently developing an edge product to bring some AD routing and logic into the DMZ
– without exposing your production Exchange systems and AD.
Figure 8.3
Deploying edge devices and services
Port 25
Exchange
Outer firewall Microsoft Exchange Inner firewall Server 2003
Internet SMTP blocks unwanted Edge Services accepts the
Servers traffic bridged,
SSL sessions
A copy or subset of the AD allows the

Edge Device to: AD DC
Perform Recipient Filtering
Spam Confidence Level Tagging
Specialized SMTP Routing
n Note Microsoft Exchange Server Edge Services, expected in 2005, will provide autonomy and
intelligence in the DMZ for inbound email message routing. The product will let you place a
specialized server in the DMZ that’s designed specifically to handle email protection, email
security, and email message hygiene. The server will be limited to SMTP email message
handling, but it will hold enough logic and controls to use antivirus and antispam technologies
to screen email messages and process routing rules. It will handle any necessary relaying,
address rewrites, masquerading, and format conversion. Microsoft Exchange Server Edge
Services will be a limited function server with all the SMTP tools and not much more.
Securing Authentication and Controlling Protocol Access

After you’ve defined the protocols and network path, you must secure the transmission of
authentication information. Although most administrators understand the reasons for adding a Secure
Sockets Layer (SSL) certificate to the OWA server, few implement similar protection for POP, IMAP,
and SMTP relay functions. In this section, I’ll show exactly what’s transmitted over the wire when
various clients authenticate to collect email messages. Moreover, I’ll show you various methods you
can use to enforce security – including Microsoft IIS virtual directory settings and IP restrictions – and
how to protect your SMTP traffic between domains. I’ll also cover the Outlook Web Access Web
Administration utility and the specific security settings available that reduce the risk of OWA access
through kiosks and remote systems.
j Tip
To download the Outlook Web Access Web Administration utility, go to
http://www.microsoft.com/downloads/details.aspx?familyid=4bbe7065-a04e-43ca-8220-
859212411e10&displaylang=en.
Let’s examine a typical OWA authentication stream without SSL that someone collected by using
a basic protocol analyzer (i.e., a sniffer).
GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=5606&STRMVER=4&CAPREQ=0 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 10.10.10.1
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Basic c3RldmU6Q29NcExlWFBhU3NXb1JkIQ==
The authorization string base64 decodes to steve:CoMpLeXPaSsWoRd, which clearly

identifies the username and password. If you’ve read about OWA security, you know that you should
always use SSL with Basic authentication. Because Basic authentication uses no hash, the user’s
credentials are encoded with base64, then sent over the wire. Most sniffer programs can collect these
authentication packets and most can also trigger on the word authenticate or negotiate to collect only
those packets that contain logon information. In addition, the email message itself is sent as clear text
with the HTML stream:
Steve, </FONT></DIV><DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV><DIV
Just to let you know...you have the job! Don’t tell
dir=ltr><FONT face=Arial size=2>J
anyone.</FONT></DIV><DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV><DIV
Steve</FONT>
dir=ltr><FONT face=Arial size=2>-S
The first thing you need to do is change the method IIS uses to authenticate the session. Open
the IIS virtual directories for Exchange and check two directories. Both the Exchange directory and
the public virtual directory must be set to permit Integrated Windows authentication (unless your
servers are front-end servers, in which case Basic authentication is the only method available). You
should also make sure that you disable Anonymous access. You shouldn’t use Basic authentication
unless Integrated Windows authentication experiences problems with some browsers – or you’ve
configured your servers to function as front-end servers.
Use the IIS Manager console to set these virtual directories. With Exchange 2000, you made the
changes in Exchange System Manager (ESM), but now you make them in IIS.
Integrated Windows authentication better protects passwords by hashing them before encoding.
Passwords are then sent in a secured manner. When you enable both Integrated Windows and Basic
authentication, as Figure 8.4 shows, Basic will be used only if Integrated fails.
Figure 8.4
IIS Authentication Methods screen
While you have the virtual directory Property screens available, enable the ability to force the use
of SSL for OWA sessions. You can reach the operative screen only after you’ve installed a certificate
on the Web site. If you haven’t yet installed the certificate, use the IIS tools to create a certificate
request. Be sure to get the certificate from a registered trusted authority, especially if you plan to use
smart phones or synchronize PDAs with Exchange Server 2003. (Smart phones and PDAs often lack
the ability to trust a CA.)
Requiring SSL use for OWA sessions, which Figure 8.5 shows, is a clever way to ensure that you
don’t permit password transmission without some type of encryption or protection. Although this
approach can help protect the HTML data stream, it isn’t the correct procedure to protect the SMTP
data, as I’ll discuss later in the chapter.
Figure 8.5
Requiring SSL for OWA sessions
Finally, to better protect the OWA session, you can now use forms-based authentication.
You can enable this option by using the ESM to modify the HTTP Virtual Server properties to gain
the following benefits:
• You can define whether and how cookies are used.
• You can use compression options.
• You can time out a session.
• You can use logon with user principle name (UPN).
Pop and IMAP

OK, now that I’ve addressed the HTML environment, let’s look at other protocols. POP is by far the
worst: The username and password are sent in clear text and no encoding takes place. (Of course,
you need to remember that POP is 20 years old. ) If you can get rid of anything, get rid of POP and
disable the protocol.
IMAP isn’t much better in respect to security. If you must use either protocol, force it to use a
secured channel. You can set the secure channel requirement in the ESM under the Protocols menu
for each server, as Figure 8.6 shows. You must first install a certificate on the server.
Figure 8.6
Requiring a secure channel for POP and IMAP sessions
j Tip
Requiring SSL for both POP and IMAP is the only way to protect passwords and data during
transmission.
For Internet access, run the secured POP and IMAP ports through an intelligent firewall (i.e., a
firewall that understands stateful packet inspection), then into your Exchange environment. If you
permit use of the standard ports, make sure your firewall allows port 993 for IMAP (SSL) and 995 for
POP3 (SSL). You’ll need to configure the clients to use these ports and SSL to communicate with your
servers.
SMTP Security
I’ll discuss two security issues relative to SMTP. The first is authentication. If you have POP and/or
IMAP users, you’re probably letting your servers relay outbound email messages on behalf of those
users. Antispam doctrine insists that you not let servers relay. Therefore, many administrators allow
relays only if a user authenticates. This approach, however, creates a new problem in that the
credentials passed probably aren’t encrypted, as the following data stream indicates.
EHLO bryant1
AUTH LOGIN
ZG9tYWlubmFtZVxtaWtl
UGFTc1dvUmQh
MAIL FROM: <mike@windowsitpro.com>
RCPT TO: <sbryant@windowsitpro.com>
DATA
QUIT
In this data stream, the lines under AUTH LOGON base64 decode to domainname\mike and the
password: PaSsWoRd! If you take this approach to protecting your environment against relays, you
jeopardize the usernames and passwords of your POP and IMAP users. (If these past few paragraphs
haven’t dissuaded you from permitting those protocols, I’ll be truly surprised.)
Outlook Express (or just about any POP client) supports the use of secured channels for SMTP
traffic. You don’t need to open any additional ports to use secured channels, but you must create a
new SMTP virtual server to force the setting. An excellent article, “How to Protect SMTP Communica-
tion by Using the Transport Layer Security Protocol in Exchange Server,” at
http://support.microsoft.com/default.aspx?scid=kb;en-us;829721&product=exch2003, explains the pro-
cess in detail. In short, the steps of the process are as follows:
1. Add another IP address to the server’s network adapter card.
2. Create a new SMTP virtual server.
3. Configure IP access restrictions if possible.
4. Configure access control to require authentication.
5. Configure the security setting of the virtual server to require secured channels.
6. Configure the relay settings as needed.
7. Configure a DNS name for the virtual server.
8. Point the POP and IMAP clients to the new server and configure them to use SSL.
You should create a new SMTP virtual server, using a different IP address and DNS name,
specifically for the clients to talk to. Don’t require SSL on your default SMTP virtual servers or you
probably won’t send or receive many email messages. Few SMTP servers on the Internet are
configured to use or allow SSL – and fewer still require it. Also, don’t require authentication to your
default SMTP virtual servers – or you won’t receive Internet email messages.
Finally, don’t require that clients authenticate to your SMTP servers unless you’ve added a certifi-
cate to the virtual server and configured the clients to require SSL. Otherwise, they’ll be sending their
usernames and passwords over the wire. Should a spammer intercept these credentials, you’ll become
the equivalent of an open relay.
Securing the Data Stream and the Message

Because I’ve been discussing the SMTP, I’ll consider it first in this section. SMTP email messages
aren’t secure, not by a long shot. The first thing you know about Internet email messages (i.e., SMTP
email messages) is that the email message information is sent as clear text, as is the subject line and
the sender and receiver information. Any and all information sent through standard SMTP connectors
(in any email system) not specifically designed to use SSL (from both servers) will be sent as clear
text. Expense reports, meeting notes, application information, and medical records are just a few of
the things that someone can detect, intercept, read, and redistribute without your knowledge. In fact,
I bet that those activities are taking place right now for many of you.
So let’s review what it takes to lockdown such activity. In the previous section, I discussed how
to enable SSL for SMTP virtual servers. However, just because your SMTP virtual connector has an SSL
certificate installed, the server doesn’t necessarily use it for outbound mail. That is, even if the
installed certificate is used to receive inbound secured mail, having the certificate doesn’t mean that
you’re sending secure outbound mail. Because the sending server must force a secured session, you
need to focus your efforts there to ensure that email messages are transported securely to the target
servers.
Microsoft Exchange Server supports the use of Transport Layer Security (TLS) as prescribed in
Request for Comments (RFC) 3207 and its predecessor, RFC 2487. The benefit of this support is that
all other mail systems that follow these RFCs can communicate over TLS and thus provide greater
security for message transport. The RFCs define how the starttls verb is used and at which point the
communication is encrypted.
You should understand, however, that TLS doesn’t offer an end-to-end solution. The email
message itself isn’t encrypted – only the communications channel between the two SMTP MTAs is
encrypted. TLS encrypts both the authentication and the transport of the email message for your
SMTP clients who need to relay and for SMTP email messages sent to and received from other
servers and domains when you need a higher level of security.
The TLS RFCs discourage several practices, including requiring TLS on your SMTP transport stack.
Exchange Server 2003 lets you force TLS on the SMTP virtual server, but you shouldn’t do so. If you
do, you can communicate only with servers that
• are configured to use TLS
• accept your certificate
• use a certificate that your server recognizes
• can establish a secured channel with your server
To secure the communications between your company and another, you need to first make sure
the receiving server can accept the secured channel. If you follow the recommendations I discussed
previously (for securing the message relay by allowing authentication and adding a certificate to
encrypt the session), you’ll already have a certificate installed on your SMTP virtual servers.
To see whether your company or your partner companies have implemented TLS on their SMTP
servers, telnet to the servers over port 25 and issue a starttls command after ehlo or helo. (This
check works for your servers as well.) If you can’t establish a connection, you might want to call the
administrator at the other company to see whether the company is set up to use SSL over SMTP.
Because the RFCs list only a few replies, the answer you get should be yes or no, as in the two
examples that follow. In the first case, the reply is negative, and in the second case, affirmative.
ehlo
250-message1.ProExchange.com Hello [10.10.10.35]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
starttls
554 5.7.3 Unable to initialize security subsystem
ehlo
250-email.theproexchange.com Hello [10.10.10.35]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-TLS
250-STARTTLS
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50 250 OK
starttls
220 2.0.0 SMTP server ready
After you know that you can establish a secured channel with the target domain, you must create
a connector in Exchange to use SSL. You can use Exchange Server 2003 ESM to create a new SMTP
connector for specific domains or email addresses. Use the Address Space tab on the connector’s
Properties pages to select the domains that should require TLS. You can then use the Advanced tab
to configure outbound security to require TLS encryption, as Figure 8.7 shows.
Figure 8.7
Configuring outbound security to require TLS encryption
Fortunately, you can use the same connector to identify all domains that should use SSL. You
need only add subsequent domains to the Address Space tab.
After you’ve selected the correct settings, you should be ready to test the transport. Be sure to
increase logging on the SMTP virtual server to monitor communications.
Securing the Email Message

Although SSL helps to protect authentication and email message transport, it does nothing to protect
the email message itself. For end-to-end security and data integrity, you need to scramble (encrypt)
email messages from the senders’ machines and unscramble (decrypt) them for readers on their
machines. Moreover, the data must remain scrambled not just during transport but also during storage
of the email message.
Scrambling the email message is important when you need to protect information from access
by others, even by network administrators. Moreover, you need to put a mechanism into place that
lets users validate the author of a particular email message. How can you know whether the email
message you received really came from the person identified in the email message?
The answer lies in encryption and the use of keys to protect the data. In this section, I’ll cover
the options for email message encryption and digital signatures, discuss how to choose a method,
and along the way, offer some insight as to the types of CAs from which you can choose.
Encryption
Several methods of encryption are available for Outlook (and other applications). Most are based on
the notion of public/private encryption keys. Microsoft Certificate Services supports this configuration,
which is called public key infrastructure (PKI). The private key is protected and kept on the user’s
computer or a secured data card. The public key is distributed to others and in most cases published
to the Global Address List (GAL).
Microsoft chose the PKI approach for many reasons, including scalability and improved security.
PKI works well with AD and can support deploying smart cards for authentication, encrypting files,
and signing and encrypting email messages. PKI is flexible in that it also supports IP Security (IPSec)
security, code signing, and even Web-server authentication. Before you decide on a CA or structure,
you should first take your total requirements into consideration – given that certificates have uses
beyond email messages.
Let’s run through a scenario from the beginning. Your company decides that you need the ability
to send and receive encrypted email from partners and other companies. (The implication is that
these entities must know and trust the CA that issues the certificates or some confusion will ensue.)
Authority trusts exist to “link” CAs together in one harmonious environment, but because of the
security implications, this type of communication usually dictates that users’ get their certificates from
VeriSign, Thawte, or another recognized issuer of CAs. After entities receive certificates, they can
install the certificates into any Windows XP or Windows 2000 machine. Doing so lets Outlook and
OWA recognize and use the certificates.
Does completing this process mean that you can now send encrypted email messages? Not really,
because the most important component is missing. To encrypt an email message to a specific person,
you must use that person’s public key to encode the message.
As I mentioned earlier, in this scenario, each user has two keys: The private key is protected and
the public key isn’t (at least not as much). If you want someone to send you an email message that
only you (and your private key) can open, that person must use a subset of your private key to
encrypt the email message. After the sender does so, only your private key has the proper algorithm
to decrypt the email message. Cool, right?
The problem with this design is that you need to get your key to the sender. If you’re all in the
same AD and Microsoft Certificate Servers are involved, the recipient’s key is in the GAL. If certificates
aren’t published in the GAL, you must find a way to share your public key with those who want to
send you encrypted email messages. The easiest way to share the key is to digitally sign the email
message.
Digital Signing
Digital signing is different from encryption in that the email message is sent with your public
certificate as an attachment. Technically, the email message is still encrypted, but the encryption is
performed in a different order and isn’t really secure. Let me explain.
When you sign an email message, it’s encrypted (behind the scenes) with your private key, using
information from your public key. Your public key is sent with the email message so the reader can
open the email message directly. Why? Because the information needed to decrypt the email message
is contained within the public key. As a result, recipients get a copy of your public key and can
associate your name, email address, and that key in their address book. After you’re in their address
book, senders can use your private key to encrypt an email message. Although this information
sounds complicated, the process of signing an email message, for which Figure 8.8 shows the
Security Properties screen, is actually fairly simple (and not something that you’ll need to worry about
very often).
Figure 8.8
Adding a digital signature to a an email message
After you install a certificate on the Outlook client, you can add a digital signature as easily as
you can request a delivery receipt. Sending an encrypted email message is just as easy, but you need
the recipient’s public key to encrypt the message “for their eyes only.”
Opening an encrypted or digitally signed email message involves little fanfare. In Outlook, the
recipient simply sees an icon that indicates the email message is encrypted or identifies an attachment
as a digital signature. Other email clients will acknowledge the email message differently, but the
work that goes on “under the covers” is the same. For example, the same features are available in
OWA and Lotus Notes though the menu choices differ. The process works well because the
mechanisms for secured Internet email messaging are defined in the S/MIME RFCs – and most
messaging vendors, including Microsoft, follow them closely.
Securing Servers and Dealing with Harmful Email Messages

Although Microsoft designed Windows Server 2003 to have fewer security vulnerabilities than
previous OSs, you must still plug some holes. I’ll cover tools available from Microsoft to detect weak
spots on your server and third-party tools you can use to perform more thorough scans. In addition
to discussing securing your messaging servers, I’ll cover methods for maintaining patches on the
system.
Patch management plays an increasingly important role in the security of corporate networks,
particularly for network OSs. Firewalls, mail servers, database servers, desktops, and Web servers
from all major vendors are regularly patched to protect the systems from newly created or discovered
exploits and to provide additional stability through code improvements. Microsoft and Sun are leading
the race to automate these updates by providing a Web-based mechanism to identify and download
the most critical patches automatically to close potential exploits before they’re exposed.
Automating patch application, particularly for critical security patches, is increasingly important
because the “time to exploit” is decreasing rapidly. The patch that closed the Nimda exploit was
available 331 days before the outbreak occurred. The patches that stopped the SQL Slammer and
Nachi exploits were available more than 150 days before the viruses were released. With the more
recent Blaster worm, the time to exploit was roughly 30 days. You can see that it’s increasingly
important to apply updates as soon as they’re available and ensure complete deployment across the
enterprise.
MBSA
The first thing that you need to do after installing and configuring a server is scan it for known
vulnerabilities. Microsoft has updated its Microsoft Baseline Security Analyzer (MBSA) to include
support for Windows 2003 as well as support for previous OSs. Actually, MBSA can run on almost
any current Microsoft OS. With just a few clicks, you can run MBSA against a single computer, an
entire domain, or a range of IP addresses. A central scanning machine can process up to 10,000
machines at a time. The IP scanning option works quite well because MBSA will ignore all non-
Windows–based machines within the range. Administrator access is required, so be sure to run MBSA
as a domain administrator or as another account that has local administrative permissions on the
desktops and servers.
MBSA runs many Windows, IIS, Microsoft SQL Server, and desktop checks and places the results
in a report. MSBA checks an impressive list of options and settings, including Administrators Group
Membership, auditing settings, Auto Logon, Automatic Updates settings, unnecessary services, whether
the machine is a domain controller (DC), Guest Account status, file system types, Internet Connection
Firewall (ICF) settings, and Local Account Passwords (e.g., blank, matching user names). MBSA
notifies you about any disabled or currently locked out accounts.
For IIS, MBSA identifies scripts virtual directories, IIS logging options, the IISADMPWD virtual
directory, and IIS installations on DCs. MBSA also catalogs parent paths and inventories unnecessary
services. MBSA ships with a services.txt file containing a list of services that are often installed, but
seldom used – including FTP, Telnet, the World Wide Web (WWW) Publishing Service, and SMTP.
SQL checks are equally intense. MBSA scrutinizes the security mode and local account passwords
and the roles. MBSA runs even more checks against the OS and Internet Explorer (IE) for patches,
Microsoft Data Access Components (MDAC), Exchange Server, Microsoft SNA (Systems Network
Architecture) Server, Content Manager, Microsoft Office, Microsoft BizTalk Server 2000, and many
other applications. In fact, running MSBA in your environment should be a requirement for servers
and desktops alike. MBSA reports give you a list of possible concerns as well as instructions for
resolving them.
MBSA 2.0
In the first half of 2005, Microsoft should release the next version of MBSA. This new version will
provide even better capabilities to detect, analyze, and address security concerns. The reports will
continue to show common security problems and missing updates, but the new analysis engine will
become the base scanning engine for all software that Windows Update Services supports.
Hardening the OS
Although OS hardening is important to securing your Exchange environment, I lack space to cover
the subject completely. However, I’ll note several things you can do to greatly reduce your exposure
to unauthorized server access. You should uninstall unnecessary services, lockdown key IIS and
Exchange directories, apply specific changes to the registry and file system, and change how services
execute. To get started, go to http://www.microsoft.com/technet/security/prodtech/win2003
/w2003hg/sgch01.mspx, where you’ll find the Windows Server 2003 Security Guide.
In the guide, you’ll find specific information about how to lockdown both AD and Windows
2003. To make things a little quicker, you can download Exchange Group Policy Security Templates
from http://www.microsoft.com/downloads/details.aspx?familyid=6a80711f-e5c9-4aef-9a44-
504db09b9065&displaylang=en. You’ll receive not only a white paper about how to lockdown your
Exchange servers (Exchange Server 2003 Security Hardening Guide) but also eight Group Policy
templates to automate the process. Each of the eight templates is designed for a specific Exchange
server role: HTTP, back end, front end, SMTP, POP, IMAP, Network News Transfer Protocol (NNTP),
and Exchange Servers that are also DCs (an incremental policy).
URLScan
URLScan is a powerful control tool that lets the server monitor incoming HTTP requests and filter out
requests you don’t permit. URLScan is especially important on Win2K servers because they lack the
built-in security that Windows 2003 includes. The rules upon which you can base URLScan filters
include several factors (e.g., content, length). If you use Windows 2003 machines, you can probably
skip installing and configuring URLScan (unless you want to incorporate such features as verb control
filters). If you use an older version of IIS, you should download the latest version (URLScan 2.5, as of
this writing) from the URLScan Web site at http://www.microsoft.com/technet/security/tools
/urlscan.mspx.
SCM
The release of Windows 2003 Service Pack 1 (SP1) is on the horizon. With it will come a new tool to
help simplify the lockdown procedures used with the security templates. The Security Configuration
Manager (SCM) will provide a wizard to walk you through disabling unnecessary services (including
IIS Web extensions), blocking unused ports, and securing open ports through IPSec. The ability to
configure audit settings and multihomed network settings and the support for security templates will
let administrators not only apply specific lockdown settings but also better understand the effects of
applying them (and understand how to remove them if necessary).
Server Patch Management

As I mentioned previously, patch management plays an increasingly important role in the security
of corporate networks, particularly for network OSs. The automation of patch application, particularly
for critical security patches, has become increasingly important. You will need to make sure both the
clients and servers are current with all the known security updates. I’ll discuss some methods you can
use to keep your OS up-to-date.
Windows Update
Microsoft Windows Update is the online resource for fixes, updates, and enhancements to Windows
OSs ranging from 64-bit versions of the Windows 2003 family to Win98. The Windows Update
Catalog is the online database that indexes and categorizes the updates and provides the core index
for all of Microsoft’s patching solutions including the built-in Windows Update components installed
in Windows 2003, XP, and Win2K systems. Because Windows Update is built into Win2K and later
OSs, it’s an ideal solution for consumers and small businesses that don’t have a server or an IT
administrator.
Software Update Services

For companies with servers and IT administrators, Microsoft Software Update Services (SUS) provides
a more complete patch management solution. By deploying SUS, administrators can download the
latest updates to an intranet server, test the updates, select updates to deploy to specific computers,
then deploy the updates in a timely and efficient manner. SUS provides dynamic notification of
critical updates to Windows-based computers, whether or not they have Internet access, and it
provides a simple, automatic solution for distributing updates to networked clients and servers.
SMS 2003
Microsoft Systems Management Server (SMS) 2003 extends the core server patching capabilities of
Windows Update Services by adding even more control for patch management as well as complete
software distribution. Compared to Windows Update Services, SMS 2003 offers more advanced control
of content targeting, distribution control, scheduling, and reporting. It also adds full compliance
checking. SMS completes the update management solution with extended levels of control for
software updates of all types combined with an integrated asset management solution.
Of the Microsoft patching tools that you can use for Exchange Server, only SMS 2003 currently
offers a patching mechanism that can monitor and keep your Exchange systems up-to-date. To be
honest, monitoring shouldn’t concern you much – as long as you check the Exchange product pages
every week or so to monitor for new patches and hotfixes specific to Exchange.
Because Exchange updates don’t come out as often as other product updates, automating patches
for Exchange isn’t as critical as for the OSs. If you’re interested in automatically scanning for and
applying patches to your Exchange services, you can always consider SMS 2003 or products available
from third parties such as Quest or Configuresoft.
Quest’s Patch Management for Microsoft doesn’t require the use of agents as does SMS and it
can be up and running in 15 minutes or less. In addition to the ease of deployment, Quest’s Patch
Management for Microsoft provides detailed progress tracking and reporting, the ability to roll back
service packs or patches that cause issues, and the ability to deploy custom patches.
ConfigureSoft’s Enterprise Configuration Manager (ECM) provides centralized security patch
management and a Web-based console for administration. ConfigureSoft’s Enterprise Configuration
Manager also provides extensive reports and the ability to set up compliance rules to monitor key
settings and optionally auto-enforce or auto-change settings to bring them into compliance.
Dealing with Harmful Email Messages

Email messages are the leading distributor of infected files. No matter how good your firewall is, an
infected file can get into the system. If you really think about it, infection begins at the client level. To
make things worse, email virus scanners might pick up infected files, but will they scan HTML links?
An embedded HTML link to a graphic or a Web page can be as dangerous as a virus. From the
server side, the wrong SMTP configurations not only permit incoming infected email messages but
also let spammers and malicious users use your mail servers to harm others.
Managing SMTP Relays

By default, Exchange Server 2003 doesn’t permit relaying on the servers. You should check this
setting periodically on your front-end and back-end servers as well as on the server in your DMZ
that routes email. The best way to control relays on your Exchange 2003 and Exchange 2000 servers
is through IP addresses. By default, no machine should be allowed to relay. With Exchange, this
restriction means that the target SMTP address must be someone within your SMTP domain, as
Figure 8.9 shows.
Figure 8.9
Setting up relay restrictions
Within Exchange, SMTP configurations are in the ESM under a server’s protocols menu. You’ll
need to check each SMTP virtual server you have under each server.
Preventing Virus Outbreaks

Too many folks believe that a simple gateway messaging scanner will protect the enterprise.
However, you need to cover several fronts in the battle against infected email messages. Client
machines offer the greatest risk to the environment. You should require each machine to be security
compliant, then monitor for that compliance. Of course, protecting the border is important, and
performing a periodic scan against the Exchange stores helps prevent infected files from “living” in
the databases.
Gateway servers get the most attention and rightly so because they reside where a virus usually
enters a network. You should take steps to scan and clean email messages as they enter your
environment from the Internet. In fact, cleaning them before they enter the Exchange environment is
even better. Many companies offer SMTP scanning engines that automatically update their virus
signatures on a schedule, thereby ensuring that the virus-scanning signatures are always up-to-date.
Some of the more sophisticated tools use multiple brands of scanning engines in case one vendor is
late in updating its signatures for a new virus.
Assuming that you can block every incoming infected file, you’re still at great risk of an outbreak
because you have clients. (Without them, however, you and I probably wouldn’t have jobs!)
Someone who uses OWA from the Web or uses an Outlook, POP, or IMAP client can easily attach
an infected file to an email message and send it to someone within the company.
Because the email message never crosses your gateway scanner, it will go unnoticed, potentially
right into a user’s Inbox. To mitigate the risk of an internal infection, you should invest in an
Exchange-aware virus-scanning engine that you can install on your messaging servers. Many brands
of such scanners are available, and they let you scan the Exchange stores live or on a schedule –
and also scan MTAs. The net result is an internal scanning configuration that prevents intracompany
outbreaks.
Last and most important is the client itself. The most dangerous outbreaks typically begin when
some malicious code or mechanism infects a client and leverages that client’s email program to
propagate the virus. As of Outlook 2000 Service Release 1 (SR1), this problem hasn’t recurred because
of a new security feature: the Object Model Guard. When the feature first came out, many users
complained because it interrupted PDA synchronization software. It prevents programmatic access to
the address book and the functions that send email messages. Because of this feature, a program
that tries to infect email messages can succeed only if the client clicks a button to permit it or an
administrator has disabled the Object Model Guard.
In addition to protecting the object model, Outlook also controls access to certain types of files.
Administrators can centrally control files and the Object Model Guard by downloading and installing
the Outlook Administrator Pack from http://www.microsoft.com/office/ork/2003/tools/boxa10.htm.
With this tool, you can create an Outlook form in a public folder to better control the security
settings on the Outlook client. For example, you can create a profile that lets administrators but not
the sales team get to executable files within email messages. The files are still in the email message,
but the Outlook client won’t be able to access them. You can extend this level of protection to any
file type you want to control. By eliminating attachments or limiting the types of attachments that
users can open, as Figure 8.10 shows, you greatly reduce your exposure to email-borne outbreaks.
Figure 8.10
Outlook default security settings
The Outlook Administrator Pack offers the best way to centrally control the behavior of the
Outlook client. This control is especially helpful when certain groups of users need access to specific
types of files or need additional programmatic access to their Outlook sessions, as is the case with
PDA users.
So what do you do with Outlook clients earlier than Outlook 2000 SR1? Although security
updates and some protections are available through third-party antivirus products, I recommend
eliminating those clients altogether. Outlook 2003 can run on any XP or Win2K machine and
Outlook XP (2003) can run on Win98 machines. Therefore, your best bet is to get rid of the old
clients. (You’re entitled to a license for Outlook 2003 for every Exchange 2003 Client Access License –
CAL – you purchase, which leaves you with no excuse to not install Outlook 2003 on every client
machine that has a valid Exchange 2003 CAL – unless of course those machines run Windows 9x.)
For those of you who want to protect yourself from being victims of infected Outlook 98 or
Outlook 97 machines, you can leverage an Exchange feature that blocks access from those clients
specifically. Exchange Server 2003 detects the version of the Outlook client connecting and can block
access based on the version number of the requesting client. To learn more about this feature, see
“XADM: Feature to Disable MAPI Client Access” at http://support.microsoft.com/?kbid=288894.
Preventing Unsolicited Email

For those of you who wonder whether you should upgrade to Outlook 2003, let me help you make
up your mind. To begin with, Outlook 2003 includes a feature that blocks HTML-embedded messages
from automatically retrieving pictures from the Internet, as Figure 8.11 shows.
Figure 8.11
Outlook 2003 External Content Settings
This feature alone should help reduce much of the pornography that comes across in unsolicited
email messages. Spammers pay ISP costs, and they use HTML-embedded messages because they can’t
afford to send millions of large email messages and thereby limit the number of people they can
reach. By using this blocking feature (which is enabled by default), you ensure that the email mes-
sages that do get through probably won’t contain graphics.
When you connect to a graphic link embedded in an email message, you’re often connecting to
an untrusted source. In addition, the HTML link you use is probably designed to identify you. When
a client downloads external embedded graphics, you could be confirming that your email address is
authentic. Confirmed email addresses are very valuable to spammers.
Outlook’s SmartScreen Function

The previous two versions of Outlook shipped with a junk-mail filter, but Outlook 2003 ships with an
improved technology known as SmartScreen. Outlook’s SmartScreen function comes with four settings
that individual users can set within their own Outlook profiles. Outlook’s SmartScreen Junk E-Mail
options let you choose among various levels of protection, as Figure 8.12 shows.
Figure 8.12
Outlook SmartScreen’s Junk E-mail options
The default setting of No Protection offers very little in respect to email message filtering. With
this setting, Outlook will only block email messages based on specific domains or senders that the
client has already determined to be junk-email senders. In other words, if John gets email messages
from a questionable address and adds a filter to block them, he’ll no longer get messages from that
address. The effectiveness of this feature is low because most spammers change their sending domain
names regularly or spoof sites and use fake return addresses. The second level, Low, scans email
messages against the lists you’ve provided and searches the subject and body fields for specific words
and phrases hard-coded into Outlook.
Outlook’s SmartScreen has two drawbacks. First, you can’t add or remove key words from the
filter list. Second, as an administrator, you have no central way to manage the settings for the Junk
E-mail Options. With SmartScreen, the responsibility for blocking unsolicited email messages fails on
the users’ shoulders. For some organizations, this scenario is acceptable, but I prefer to have some
leverage over the settings from a central console.
You probably shouldn’t use Outlook SmartScreen’s highest scanning option often. The Trusted
Lists Only option filters out every email message whose sender isn’t in your address book or in a
Trusted Senders or Trusted Recipients list. Of course, if you do business with Company.com, you
can easily add that entire domain to your Trusted Senders list. Also, if you want to receive email
messages from someone at Aol.com, you could add Aol.com or the individual email address to the
Trusted Senders list.
However, the drawbacks of this setting are obvious. Unless you have specifically opened a
domain or user account within Outlook, SmartScreen will filter out an email message. Moreover, the
setting is likely to create some confusion and add work for end users because they’re responsible for
identifying junk email messages, handling filtered email messages, and managing their own false
positives.
Exchange Server 2003 Antispam Tools
Exchange 2000 lets you block email messages based on the sending domain and sending IP address.
A diligent Exchange 2000 administrator could inspect incoming email messages, collect the sending
server’s IP and domain, and build a block list in Exchange 2000. As administrators used these settings,
they began to learn how spammers operate.
Spammers often operate out of small or home offices and in countries with fast network links.
The most prolific spamming companies must constantly change server IP addresses to confuse spam
filters. The IP address you blocked last week will probably never be used again. Spammers acquire a
DSL or network link with banks of IP addresses. In theory, 32 IP addresses should provide a month’s
worth of spam if spammers change the IP address, server name, sending domain, and email
messages every day.
Exchange 2003 not only blocks domains and IP addresses, but also supports basic antispam tools
such as whitelists, blacklists, and third-party blacklist servers. By using the Sender Filtering page,
which Figure 8.13 shows, you’ll be able to filter email messages from particular domains as well as
email messages with blank sender fields.
Figure 8.13
Deploying sender filtering
Exchange Server 2003 now supports the use of blacklist servers, as Figure 8.14 shows. Exchange
Server 2003 can compare the sender’s domain against a list of known spam domains located on
third-party servers on the Internet. Relays.visi.com, for example, is one of several free blacklist servers
you can use.
Figure 8.14
Configuring blacklist service use
You’ll need to check out the block list services you choose; many are free and some are
unreliable. In the past year, the industry lost several well-known Real-Time Block Lists (RBLs), and
one in particular became so compromised that all senders were confirmed as blacklisted!
You can create an Exception list, as Figure 8.14 also shows, to identify the mailboxes that should
never be filtered. Perhaps you have a couple of executives who want to handle spam filtering on
their own by using the Outlook 2003 filters. You can add their SMTP addresses through this screen to
ensure that no server-based rule ever filters their email messages.
IMF
For me, the Intelligent Message Filter (IMF), a new add-on for Exchange Server 2003, is the most
exciting improvement since the release of SP1. Based on the SmartScreen technology, the IMF, which
Figure 8.15 shows, works by scanning an email message at the (Exchange) gateway and at the
mailbox store itself.
Figure 8.15
Configuring IMF
n Note The configuration screen for the IMF might make you think the tool is simplistic or less than
functional, but it has useful capabilities. Microsoft offers a 39-page white paper that describes
the IMF and its various configuration scenarios. To access “Exchange Server Intelligent Message
Server Overview,” go to http://www.microsoft.com/exchange/downloads/2003/imf/imf
_wp.asp.
One benefit of IMF is that unsolicited email messages are moved or deleted before the client ever
connects to the server. This benefit is key for PDA, OWA, POP, and smart phone environments
because these clients don’t always have their own antispam filters.
IMF still needs some improvement. For example, you can’t change the Simple Object Access
Protocol (SOAP) Contract Language (SCL) rating per user or group or manually edit or augment the
logic that filters the email messages. Instead, Microsoft is keeping the code and the logic behind the
IMF very quiet. Aside from the drawbacks just mentioned, IMF works very well. If you have no anti-
spam tools, I highly recommend deploying IMF.
Third-Party Solutions
Many other hardware and software products can help you fight spam. Service companies such as
MessageLabs and Postini can intercept your incoming email message (by redirecting the MX records),
scan the email messages for infected attachments and spam, and send the clean email messages on to
your environment. Your best approach to finding the right solution for your environment is to contact
other companies to see what has worked well for them, then arrange for a vendor trial.
Protecting the Exchange Environment

In this final chapter, I’ve discussed Exchange security and how you can work to achieve it. I hope
the chapter’s information and references offer information and approaches you can use to keep your
Exchange system and your company’s assets secure.

ExchangeServer ch8

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ExchangeServer ch8

Uploaded by

Copyright:

Available Formats

The Expert's Guide for

Identifying Security Problems

Segregating Your Network

Exchange Server Edge Services

A copy or subset of the AD allows the

Securing Authentication and Controlling Protocol Access

The authorization string base64 decodes to steve:CoMpLeXPaSsWoRd, which clearly

Pop and IMAP

Securing the Data Stream and the Message

Securing the Email Message

Securing Servers and Dealing with Harmful Email Messages

Server Patch Management

Software Update Services

Dealing with Harmful Email Messages

Managing SMTP Relays

Preventing Virus Outbreaks

Preventing Unsolicited Email

Outlook’s SmartScreen Function

Protecting the Exchange Environment

You might also like