Securing Exchange Data from Unapproved Mobile Devices (or how to block a phone or service from taking data out of your Exchange Server)
Published Sep 05 2008 12:20 PM 28K Views

Many companies and users consider mobile access to Exchange data an essential feature.  Exchange ActiveSync (EAS) is very popular as it allows this access and many devices have licensed and implemented EAS (including Windows Mobile).  Some companies use remote servers to access Exchange data and push it out to their mobile clients that aren't EAS enabled. Of course these mobile access options can be a little concerning when you think about the security implications. Evaluating these devices (and servers) to make sure they comply with data protection policies is a necessary step for a lot of companies that want to protect their messaging data.  This post will details some of the options available to companies that want to limit access to a specific set of supported devices.  The first question we usually get is, "How do you stop unapproved devices and servers from accessing Exchange data?"  In general, I hear people talk about three ways to block devices:

  1. Use an ISAPI filter (Not recommended)
  2. Set policies that only the devices you care about can implement (Better)
  3. Block the devices at the firewall (Recommended!)
Let me describe each method in a bit more detail. Custom ISAPI filter: Since creating a custom ISAPI filter is both time consuming (you have to write custom code) and not a best practice, I'm not going to talk too much about it except mentioning that it is a possible solution. More details can be found here for those interested in exploring this option. Policies as a blocking agent: Using policies is a very easy way to do this (by unchecking the box titled "Allow non-provisionable devices" (image below) and then setting a policy that the particular device doesn't support. A list of which policies are enabled with which version of the server (and thus which generation of clients) is listed below. You may need to test a device to see which version of the policies are implemented as it varies by licensee).  The challenge with this method is that many of today's devices are upgradable and thus may implement a policy in the future while still not providing the security you want (for example, if you want to make sure the device and storage memory are encrypted by at least 128-bit encryption (WM 6+ uses AES 128-bit encryption for storage card encryption but another device might simply do 40-bit encryption).  Because of this discrepancy, it is important to understand what devices are connecting to your network, and which ones can connect, so that you can decide if your organization is ok with this level of control. Using ISA Server 2006 to block unwanted clients: Finally, you can block at the firewall.  This is by far the best solution and is really easy to implement with ISA Server.  Below, I list out, and describe, the steps of how to configure your ISA server so that you can block by device type (using the User-Agent string of the device to identify and block it), and by server type (using the IP address range of the server). Blocking by User-Agent String in ISA Server 2006: Blocking a particular device from accessing EAS is easy to do if you filter by the device's User-Agent string at the firewall.  You can create a rule for each device type you want to block.  In ISA Server you should already have an EAS rule set up (if not follow the wizard that the "Publish Exchange Web Client Access" takes you through).  Simply right click on that rule (pictured below) and then select "Configure HTTP". From here, you'll get the below dialog to appear. Make sure you select the last tab named "Signatures". When you hit OK you will go back to the main ISA Server screen but at the top it will ask you if you want to apply or discard the changes you made. (see below)  When you accept the change you are done. Some mobile access methods work though an Internet service as opposed to directly from the device itself.  This method might be of concern to certain organizations because they have no idea what devices are connecting to their servers, how many devices are using the service or what control (policies) they have on the phone (in many cases, none at all).  These services usually have users enter their login and password and then save that on a remote server.  The remote server then logs into OWA for that user, scrapes out the information and then pushes the data down to the user's device.  In these cases, user credentials and data have left the organization and there is no control over it, or even knowledge of where it is.  From the mail ISA screen, click on the "Create Access Rule" link. (shown below) This will bring up a wizard that will take you through the process.  In this case we will block the fictitious servers of "Bad Site".  On the first page you will Name the rule; let's say we call it "Block Bad Site". On the next screen we will be asked if we want this to be an Allow or Deny rule.  Since we want to keep these servers from accessing our Exchange Server, we will select Deny. The next screen will ask us what traffic we want to block.  This is where the wording can be a bit tricky if you're not familiar with ISA Server.  In this case you want to choose "All outbound traffic". You now need to define who this rule applies to.  Select "Add" if the group you want isn't already listed (for this example I'll assume nothing has been created or set up yet). You will get a dialog that lets you pick who you want to apply their access rule to; select New and choose Computer Set as we are going to specify a range of IP addresses. Now we need to name this new computer set (we'll call it Bad Site Servers for this example).  You can also add a description in the bottom of the dialog if you want.  Then click "Add" and select "Address Range". You now can specify the address range of the server.  If the service you are blocking has more than one range of IP addresses, you will enter more than one of these (we'll go through an example of two).  You need to enter a name and the starting/ending IP addresses (shown below is just an example).  The description is optional.  Then click OK. You can repeat this process (clicking on Add and adding another address range) as many times as there are Address ranges.  Below you can see our example has two IP address ranges.  When all of them are entered, click OK. You will now notice that in the "Add Network Entities" list (under Computer Sets) you have the set you just defined (Bad Site Servers in this case).  Select the new Computer Set that you defined, click Add, then click Close. Your access rule now applies to the computers you specified (in this case the Computer Set of Bad Site Servers).  You can add additional sources if you wish or click Next to move on. You now need to define the destination for this traffic.  In this case, ISA Server (localhost) is the destination of this traffic.  Select Add to bring up your options to make this selection. Under Network, you can select Localhost, then click Add and then click Close. In this case Localhost is our only destination so we can select Next. Now select who this applies to add "All Users" and then click Next. You're done creating the access rule.  Just click Finish to take you back to the main ISA Server view. When you hit OK you will go back to the main ISA Server screen but at the top it will ask you if you want to apply or discard the changes you made. (see below)  When you accept the change you are done. The following dialog will appear once your changes have been applied.  Click OK. You're done.  Below you can see that there is now a new firewall policy rule that you created to block the server you didn't want to access your site. Note: In general, "Deny" rules should precede any "Allow" rules, although there are exceptions to this. You will need to be familiar with ISA Policies Best Practices to understand the fine points of ISA rule definition. And there you have it; how you can block by device type (User-agent string) and how you can block by server (IP address).  New devices and services come online all the time so it's tough to have a comprehensive list but some of the more common User-Agents are: Symbian devices: "Symbian" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader Motorola: "mot-" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader Samsung: "sec-" or "samsung" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader LG: "lg-" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader Siemens: "sie-" http://www.developershome.com/wap/detection/detection.asp?page=userAgentHeader Nokia Devices: "Nokia" http://discussion.forum.nokia.com/forum/showthread.php?t=83267 BlackBerry Devices: "BlackBerry" http://na.blackberry.com/eng/developers/resources/journals/mar_2007/profile.jsp Apple Devices: "Appl" (no e on this one as Device ID starts with Appl so this covers all cases) Note: if you just want to block only the iPod Touch, or only the iPhone, you can just block on "iPod" or just "iPhone". http://forums.macrumors.com/showthread.php?t=361166 Some of the common Servers that try and access Exchange Server are below (with links to their docs that list their server IP address ranges): BlackBerry Internet Service: http://www.blackberry.com/btsc/articles/644/KB11036_f.SAL_Public.html Good Mobile Messaging (GoodLink): http://www.goodlink.com/documentation/GoodAdminGuide_exchange.pdf For those that want more info on HTTP filters in ISA server, there are a lot more detail here. - Adam Glick

7 Comments
Not applicable
On a somewhat related note, why is it necessary to require a password on a mobile device in order to remotely wipe it?
Obviously, using a password on the device is more secure regardless of whether you use ActiveSync or not.  But it is exactly the non-protected devices that I am most concerned about and want to be able to remotely wipe.
I would love to be able to wipe lost devices but I know I would get a huge amount of resistance if it also meant requiring a password on the device.
Is there any way to remotely wipe a device without requiring a password also?
Thanks.
Not applicable
Excellent. We're about to upgrade to ISA 2006 fom 2004 so this is nice to see. Now if we could only find a way to block specific models. : ) A great start!
Not applicable
Hi Peter,
The issue you refer to happens on devices that don't have any policy set.  Since the remote wipe is sent down with/as a policy, if no policy is set, then it prompts for one.  The most common is PIN policy which is why you see it ask for a password to be set up (you could define a policy where a PIN wasn't required but you would still get a policy prompt).  In Exchange Server 2007 SP1, we introduced a "Default" policy that Admins could set.  With a default policy, you will not run into the "prompt for policy" on a wipe as all device that connect will automatically have policies pushed down to them (even if that policy has no PIN requirements in it).  It is always a good idea to have some policies applied to all devices that connect to your Exchange Server.  Using the Default policy in SP1 will make this simple and the prompt issue experienced by organizations that didn't previously apply policies will become a thing of the past.  If you are not on Exchange Server 2007 SP1 I’d recommend upgrading or setting a policy that you apply to all users and this will avoid the situation you are referring to.
Not applicable
Hi Peter,
We disallow all of our users access via ActiveSync, and then we lock them down to a single device when they request access.

One quesiton, if you lock them down using the set-casmailbox <userid> -ActiveSyncAllowedDeviceIds <deviceID> how do you remove the ID from thier cas-mailbox settings?

I know you can remove device partnerships with OWA, ps, or EMC, but it doesn't remove the deviceID you manually set.

Thanks
Brian
Not applicable
As a webmaster, you definitely should use user-agent headers to manager server traffic. But understand that this is purely a pragmatic tactic and not a serious security measure.



I wrote more about this here:


Webmaster Tips: Blocking Selected User-Agents

<a href="http://faseidl.com/public/item/213126">http://faseidl.com/public/item/213126</a>

Not applicable
Intresting article. Makes me wonder if this can be done to control Iphone usage as well. While we do want to allow users to use an iphone we want to control WHO is using them. I figure if we place the rule with an exception........ Also I wonder if the User-Agent string is known for the Iphone?
Not applicable
This article has some serious flaws

What about the concept of least privilege?

You should deny all access first thewn make exceptions for your known mobiles and servers. I think you should rewrite this
Version history
Last update:
‎Sep 05 2008 12:20 PM
Updated by: