When Microsoft created Exchange Server 2003, some of the biggest improvements that they made over Exchange 2000 were to OWA. Unlike previous versions of Exchange, OWA now looks and feels a lot like Outlook. In fact, you can do most of the things in OWA that you can do in Outlook. Best of all, OWA is now enabled by default. You can access OWA by opening Internet Explorer and enteringhttp://server's_IP_address/exchange. Before you get too excited though, there are some serious security implications to having OWA enabled by default. In this article, I will explain what you need to know about configuring OWA the safe way.
What are the risks?
Since Microsoft enables OWA by default, it would seem that having OWA enabled is harmless. By itself, OWA is pretty much harmless. After all, OWA is nothing more than a Web site that acts as an interface to a user's mailbox. The security risks have to do with the way that the network is configured.
To understand why an improperly configured OWA instance is such a threat, you must consider the nature of the server that OWA exists on. Exchange Server is publicly accessible by its very nature. If it weren't then no from the outside world would be able to send e-mail to mailboxes residing on the server. The reason why it is possible to send e-mail messages to mailboxes on the server is because the server has a publicly accessible IP address (port forwarding might be used as an alternative, but I will talk about that later). If someone from the outside world wants to send a message to one of your users, their mail client will perform a DNS query to determine the IP address associated with your mail server. Once the client knows the IP address, mail is transmitted to that address using the SMTP protocol.
Like every other server on your network, your Exchange Server is probably behind a firewall. The firewall is responsible for blocking any protocol that you don't specifically allow. However, the SMTP protocol is allowed to reach your mail server because you would not be able to receive external mail without it.
Keep in mind that this very same server is also running OWA. However, if your firewall isn't configured to allow inbound HTTP traffic, then OWA won't be accessible to those outside your network perimeter. You could technically allow the outside world to access OWA by simply allowing the HTTP protocol to pass through your firewall. This is an extremely bad idea though.
Right now you might be wondering why it's safe to allow SMTP traffic to reach the server, but it isn't safe to permit HTTP traffic. The reason for this is that SMTP is an extremely simple protocol. It has one use and one use only; to send and receive messages. HTTP on the other hand is much more complex. There are dozens of known HTTP exploits. If you blindly allow HTTP traffic to pass through your firewall, you are asking for trouble.
The solution
There are several tricks to implementing OWA safely. The first trick is to control how traffic enters your network. You can't really get around permitting inbound HTTP and HTTPS traffic. You can however isolate that traffic so that outsiders can't use HTTP exploits against other parts of your network.
I have seen some people accomplish this isolation by placing an Exchange Server into a DMZ. DMZ stands for demilitarized zone. It refers to an isolated part of your network that the firewall does not protect. I personally think that it's a bad idea to place an Exchange Server into a DMZ because the server will have absolutely no protection. Besides, Exchange Server relies on the Active Directory. A hacker could potentially take over the Exchange Server and then use it as a staging platform for attacks against your Active Directory or against other Exchange Servers in your organization.
When it comes to controlling inbound traffic, I prefer to use a technique called port forwarding. Port forwarding allows you to redirect specific types of traffic to a designated IP address, regardless of the traffic's intended destination. For example, you could create a port forwarding rule that directs all HTTP traffic to your OWA server regardless of which server the packets were actually intended for.
Isolating OWA
Just because you have configured your firewall to direct HTTP traffic to your OWA server doesn't mean that OWA is secure though. You still have a publicly accessible server that is prone to HTTP exploits. Because the server is subject to HTTP based exploits, your best bet is to insure that there is no real data on the server. This means moving all of your Exchange databases to a different server.
This is known as a front-end / back-end configuration. The idea is that the front-end server acts as a sort of buffer against Web based attacks. Internet based users are never given direct access to the servers containing the Exchange databases. Instead, OWA users authenticate into the OWA front-end server (the server without any databases), and the front-end server acts as a proxy that relays information between the user and the back-end server.
The primary reason for implementing a front-end / back-end configuration is that doing so allows you to isolate your Exchange Servers that contain data so that those servers are in no way directly accessible from the outside world. The easiest way of accomplishing this is to multihome your front-end server. You can then attach your front-end server to an isolated segment of your network. Once the front-end server is isolated from the rest of your network, you can connect the server's other NIC to a switch on the network segment that contains your other Exchange Servers.
By connecting the front-end server to the network in the manner that I have described, it becomes accessible from both the Internet and from the private network. Since this is the case, you might be wondering what stops Internet users from passing through the front-end server and accessing the rest of your network.
The reason why you don't have to worry about Internet users accessing the rest of your network through the front-end server is because of a fundamental rule of networking. There is a rule that says that in order for two nodes to communicate on a network, they must share a common protocol. While it's true that the end user, the front-end server, and the back-end server are all using the TCP/IP protocol, they are not all using it in the same way. Remember that TCP/IP is actually a suite of protocols rather than being one individual protocol. The firewall insures that Internet users are only able to access the front-end server by using the HTTP or HTTPS protocol. However, the front-end server does not use HTTP requests to communicate with the back-end server. This prevents an Internet user from passing an HTTP request through an OWA server to the backend network.
In case you are wondering, Exchange actually contains a setting that you can use to designate a server as a front-end OWA server. If you were to open the Exchange System Manager, navigate to Administrative Groups | your administrative group | Servers | your server, right click on the server and select the Properties command from the shortcut menu, you would see that the General tab of the server's properties sheet contains a check box that you can use to designate the server as a front-end server. When you select this check box, Exchange will automatically take care of some of the security requirements pertaining to keeping the Exchange databases isolated.
Encrypting OWA traffic
Another reason why a default OWA installation is a threat to your network's security is because by default, OWA doesn't encrypt anything. Passwords and e-mail messages are both transmitted across the wire in clear text for anyone with a protocol analyzer to read.
As you may know, Internet Information Server offers multiple authentication options. Clients accessing a Web site may use Windows integrated authentication, basic authentication, and anonymous authentication. Anonymous authentication simply won't work for an OWA Web site because OWA needs to know who is logging in so that it can display the correct mailbox.
This leaves basic authentication, which transmits passwords in clear text, and Windows integrated authentication, which is generally a better choice if the person accessing the Web site is running a Windows operating system. The problem is that you have no way of controlling what operating system your users will be running when they access your OWA Web site. That being the case, basic authentication is the only choice that will work.
Basic authentication does transmit passwords in clear text, but you can get around this problem if you encrypt the session using SSL over HTTPS. Using SSL is an ideal solution since users would otherwise be using the HTTP protocol to access the OWA server. Keep in mind though that communications between the front-end server and the back-end servers do not use HTTP and therefore SSL encryption is not an option.
If you happen to have an ISA Server at your disposal, you can make communications between the front-end server and the Internet even more secure. There is a technique by which you can copy the front-end server's certificate to the ISA server. You can then configure the ISA server to impersonate the front-end server. Internet users would never actually communicate with the front-end server directly.
Instead, the users would communicate with the ISA Server (the perimeter firewall's port forwarding feature would have to be configured to pass HTTP and HTTPS packets to the ISA Server rather than to the front-end server). The ISA Server would then act as an application level firewall / proxy. It would screen inbound HTTP and HTTPS requests. If the requests were valid then the requests would be passed along to the front-end server. The server's response would then be relayed back to the user. If the inbound packets are determined to be malicious, then the packets are blocked from ever reaching the front-end server.
Communications between the front-end server and the back-end servers seems to be a touchy issue for some reason. There are a couple of different schools of thought on the subject. Some people believe that since users are authenticated prior to the front-end server ever initiating communications with the back-end server, the user is trusted. Furthermore, the packets are flowing across your own private network, so there is no need to encrypt communications between the front-end server and the back-end servers. On the flip side of the issue, security purists believe that you should encrypt any traffic that's flowing across your network as a way of protecting user's privacy and as a way of guarding the system against security breaches.
I personally believe that whether or not you encrypt front-end to back-end traffic should depend on your own organization's security needs. If you do decide that IPSec encryption is necessary, then you might be interested in knowing that you can't implement IPSec in the usual way.
Windows has three different IPSec policies built in. I don't really want to get into all of the specifics regarding these policies because they are beyond the scope of this article. Generally speaking though, if you activate any of the built in policies, then the policy will apply to all IP traffic flowing in or out of the machines that the policy applies to.
The reason why the built in policies are not appropriate is because you don't want blanket IPSec encryption to apply to the front-end server. Remember that a lot of the traffic that's coming into the front-end server is coming from the Internet and is already encrypted with SSL. You don't want to attempt to encrypt that traffic with IPSec. The back-end server on the other hand can use a blanket IPSec policy. The backend server will never communicate directly with Internet users. Since the back-end server's communications will be limited to the private network, encrypting all inbound and outbound traffic with IPSec is perfectly acceptable.
There are a few different ways that you can get around the blanket coverage problem. What I recommend doing is to create a separate organizational unit within the Active Directory and moving your front-end server into it. The reason why I suggest doing this is because IPSec policies are group policy objects. Group policies can be applied at the organizational unit level. This means that you could have one IPSec policy for your front-end server and a separate IPSec policy for everything else (including your back-end servers).
There is also another side effect to using a separate organizational unit for the front-end server. Having the front-end server placed in a separate organizational unit from everything else allows you to assign the server an entirely different computer level security policy. Since the server will be accessible from the Internet, you have to assume that the server will be attacked on a regular basis. The fact that the server will have its own security policy means that you can defend the server by applying a very rigid security policy without affecting any of your users or any of your other servers.
OK, so we've established that you will need a separate IPSec policy for the front-end server, but you might still be wondering how you would prevent the front-end server from having blanket IPSec encryption. Microsoft gives you a few built in IPSec policies that you can activate, but there is nothing stopping you from creating your own policy. An IPSec policy is nothing more than a collection of rules.
For the front-end server's IPSec policy, you must simply create a policy around rules that tell Windows to encrypt any traffic flowing between the front-end server and the backend server. All other traffic should remain unencrypted. As you create the rule, you will have to specify each backend server by IP address. If you add an additional backend server later on or if the server's IP address changes, you will have to update your rule to match the change.
