Eugene Siu's Thoughts on Security : Exchange server

Reset Outlook connections without restart

esiu — Sun, 23 Sep 2007 09:21:28 GMT

This is a well hidden trick in Outlook. Not sure why this needs to be hidden. You can open Connection Status window by holding CTRL + right-clicking on the Outlook system tray icon on the Task Bar.

I want to highlight a couple features:

* Reset all connections by clicking on Reconnect. It helps resolve some problems
* Diagnose some Outlook problems by checking Req/Fail, Status and Conn columns.

I am using RPC over HTTPS to connect to my Exchange server, and most connections are good (Established). Despite Established, there are a few intermittent connection failures shown on Req/Fail, which warrant some investigation.

This hidden tool should become your friend as you troubleshoot Outlook.

Exchange 2007 RPC interfaces are locked down

esiu — Wed, 09 May 2007 04:40:36 GMT

Exchange 2007 RPC interfaces have retired support of various legacy RPC bindings, including AppleTalk, SPX and Banyan Vines. This exemplifies the philosophy of reducing attack surface area in the design of Exchange 2007.

Distribution List is more locked down in Exchange 2007 to reduce spam

esiu — Tue, 01 May 2007 04:30:00 GMT

Distribution list is used for grouping users together, and emails can be sent to all members belonging to a DL. In Exchange 2003, the default setting is that a DL accepts emails from any email addresses. It can be configured to reject external email addresses and even internal addresses. However, most users accept default configuration, and some DLs become susceptible to spam mails.

As a result, in Exchange 2007, DL is created to be secure by default. External email addresses are NOT allowed to send an email to a newly created DL by default. Of course, it can be loosened to allow mails from external email addresses to come in.

Configuration of existing DLs created by Exchange 2003 and prior is intact, though. Admin should evaluate needs to allow emails flowing from external email addresses to DLs. If they are not needed, they should be reconfigured to reduce spam.

Why do browsers show cert warnings for Outlook Web Access 2007 by default?

esiu — Sun, 04 Feb 2007 04:51:00 GMT

You may wonder why OWA 2007 show cert warnings by default on most browsers. At the back of your mind, Microsoft has talked so much about trustworthy computing, and they must still do not get security.

Exchange team has gone back and forth on this issue many times. It is related to giving more security or better perception of security. There are a few routes that we have considered.
1. Do not require SSL by default
2. Require SSL by default, and install it with a self-signed cert.
3. Require SSL by default, and require admin actions to install a cert issued by CA

"Do not require SSL by default" gives better perception of security because browsers do not give cert warnings. However, it connects in clear text without any SSL encryption. Therefore, this option gives better perception of security without better security

"Require SSL by default, and install it with a self-signed cert." does not give better perception of security because cert warnings are shown on browsers. On the other hand, self-signed cert allows encryption to occur by default without any admin intervention.

"Require SSL by default, and require admin actions to install a cert issued by CA" seems to have the best of both worlds offered by option 1 and option 2. However, the downside is that admin has to purchase a cert from CA before getting OWA to work properly out of the box. Most probably, admin would turn off encryption via IIS, which result in lack of security as in option 1.

It comes down to a classic struggle between usability and security. On the spectrum of security and usability, option 3 ranks highest on security, option 2 ranks medium on both, and option 1 ranks highest on usability. After long discussions, Exchange team have decided to go with option 2 as a good balance between security and usability.

After you understand the rationale behind the design, that may convince you that indeed Exchange team have placed a lot of emphasis of security on Exchange 2007.

To configure and test IP block list from Spamhaus.org for Exchange 2007

esiu — Tue, 30 Jan 2007 01:52:00 GMT

Set-IPBlockListProvider -Name "Spamhaus Example" -Identity sbl-xbl.spamhaus.org -AnyMatch:$true

If you want to test your setup, you can send an email to nelson-sbl-test@crynwr.com from your Exchange 2007 server on which IP block list is configured.

If you want more information, you can visit http://technet.microsoft.com/en-us/library/b513755c-5d3e-44fa-a6cb-771d48b544ac.aspx and http://www.spamhaus.org/sbl/howtouse.html.

Don't believe that anti-spam is disabled

esiu — Wed, 17 Jan 2007 01:51:00 GMT

After setting up Exchange 2007 Edge and Hub, you can verify their configuration via get-TransportServer.

On Edge and Hub, two anti-spam settings are important. You can use "get-TransportServer | fl name, anti*" to show the status of anti-spam related properties.

Assuming that you have 1 Edge and 1 Hub with antispam enabled only on Edge, you will see the following results.

On Edge machine
Name : EdgeMachine
AntispamAgentsEnabled : True
AntispamUpdatesEnabled : True

On Hub machine
Name : EdgeMachine
AntispamAgentsEnabled : False
AntispamUpdatesEnabled : False
Name : HubMachine
AntispamAgentsEnabled : False
AntispamUpdatesEnabled : False

When get-TransportServer is issued on Edge, antispam status is reported correctly.

When get-TransportServer is issued on Hub, both Edge and Hub status are reported. However, antispam status of Edge is reported incorrectly.

This takes place because it is represented as a boolean value. It can either be true or false. "Unknown" is a better value.