About four months ago I wrote an article on SSL offloading for the Citrix XenMobile MDM server and talked about how this new feature helps us in placing the MDM server on our more secure corporate LAN as apposed to the DMZ. And although I still feel that this is a valid, robust and decent set up, I must admit that the idea of placing the MDM server in the DMZ doesn’t sound that bad after all, considering all that comes into play. During my last article on XenMobile I gave it a bit more thought and just recently I discussed it with a few community members as well. Let’s just say that, for now, I’m in doubt. Please feel free to share your thoughts on the matter, I might need your help on this one!
Before I skip to XenMobile and the MDM server in particular, let’s first have a look at the DMZ in general, because it is, or at least can be, a tricky concept to get your head around. Note that the concepts talked about throughout this article are not Citrix, or XenMobile, specific, they apply to all other types of servers and services as well.
The DMZ basics
Its purpose is to add an additional layer of security on top of your internal corporate network. In other words, the intention of a DMZ is to ensure (although that’s a big word) that publicly accessible servers cannot contact other internal network segments, in the event that a server is compromised or infected in some way. It acts as a buffer or neutral zone between the internet and your internal corporate LAN. It basically comes in two flavours, single and double hop DMZ’s. The first uses two firewalls with the DMZ being in between, the double hop configuration adds a third firewall creating a second DMZ before entering the internal LAN. And just so you know, DMZ stands for demilitarized zone, do North and South Korea ring any bells?
Reverse Proxy
Some hosts, or services, are more vulnerable to attacks than others, for example, when hosts provide certain services to users outside of your local network, they’re publicly faced so to speak, like e-mail (relay), web, VPN or FTP to name a few, they’re more prone to attacks because of their ‘direct’ connection with the internet. Although this could be a reason to place such a host in your DMZ, nowadays we would probably implement some sort of reverse proxy like Microsoft ISA / ForeFront or a Citrix NetScaler (which isn’t just a reverse proxy, I know) preventing direct access to our back-end machines.
Do note that most DMZ examples you find using Google primarily focus on firewalls, most of the time they don’t include any (reverse) proxy solutions, keep that in mind when reading their textual explanations.
It will than handle all external requests, offer application layer firewall capabilities that will check, inspect and filter the data, which might include e-mail, on multiple levels, take care of user authentication, SSL Offloading, which basically comes down to data inspection as well, support for 3d party token (two factor) authentication if and when we need it, and the list goes on. This way we don’t have to worry about our machines being exposed to the big bad internet and we can place them on our secure internal network. Now the real question is… should we?
Come to think of it, isn’t this functionality available for our machines in the DMZ as well? I’ll get back to this in a minute.
Why is it still around?
So why do we still have a DMZ than? Although smaller companies might decide that they don’t need one. First of all it acts as a (very) important extra barrier, a first line of defence if you will, before reaching our internal network, increasing overall security. Secondly, some machines actually need to be placed in the DMZ, there might be several reasons for this.
For one, not all traffic can be run through a proxy or is allowed for (pre) inspection, it may need a direct connection to the outside, and since you don’t want to open up a one to one connection to the internet from your corporate network, machines handling this type of data will probably end up in your DMZ. And if you don’t have one, this might be a valid reason to create one. Another use case might be when user authentication can’t be handled externally and needs to take place on the host itself, something we would like to prevent from taking place on our internal LAN, no unauthenticated users and / or uninspected traffic on our internal corporate LAN! Although, depending on the scenario, and as always, different people will have different opinions on this. Hosts that need to handle their own SSL (offloading) traffic will most likely end up in the DMZ as well.
Another reason might be because of company policy, when hosts fulfil a public service, like the ones we just listed, it needs to be placed the DMZ, period. Unfortunately there’s no one size fits all. Just remember that placing a machine in the DMZ just because it feels save, may not always turn out to be the smartest move, at least not without reviewing and inspecting your current (DMZ) infrastructure. For example, what if a machine needs to domain joined, like SharePoint for example? In that case you might want to rethink your DMZ deployment and security strategy before taking action.
Perhaps add-in a reverse proxy to front your DMZ machines as well as some of your internal resources, assuming it’s not there already. Or maybe data isn’t allowed to be pre inspected or users can’t be pre authenticated, in that case you could create a separate DMZ forest / domain using a one way trust or deploy a RODC in your DMZ offering one way replication from your internal network to your DMZ, this way extending your internal domain to the DMZ and limiting the risk towards your internal network when, and if, it gets compromised, god forbid.
As a final note, we should always try to limit accessibility as much as possible with regards to our DMZ firewalls. For example, allowing http or https traffic into (inbound) your corporate LAN might not be necessary, if so, make sure to close these ports. Sometimes outbound traffic might be all you need. Machines that serve a special purpose, like MDM for example, are often designed with DMZ placement in mind, for example, they handle user authentication using secure LDAP without needing to join the internal domain, ‘just’ LDAP will do! No need top open up anything else.
What about reverse proxy in the DMZ?
As highlighted a few paragraphs back, we can also front our DMZ machines with some sort of reverse proxy device (which is a common practice today) as we do for our machines on the corporate (internal) network, handling data inspection, including SSL offloading, virus detection, perhaps user authentication if applicable and possible, and a lot more (although due note that not all reverse proxy capable devices or software offer the same feature set). This will all take place before any data hits our DMZ machines.
So if data has already been inspected, filtered and users are pre authenticated (if needed) why would we want to place those machines on our internal LAN? Never mind if they’re domain joined or not. Is it because of the extra firewall in between? Probably. Are they more vulnerable to attacks in our DMZ as apposed to (web) servers on our internal LAN? Will it enhance user performance? I’m guessing the answer is an ‘overall’ no. The way I see it, they’re as secure on your DMZ as they will be on your internal corporate LAN. Assuming the above applies. And besides, machines being compromised in your DMZ potentially (unless domain joined) only affect other machines in your DMZ, machines compromised on your corporate LAN, well…
However, unfortunately this setup isn’t always possible, some machines can’t fronted with a proxy and need a direct connection to the outside. Some data isn’t allowed to be pre inspected or send through a proxy device. Now if we can’t pre inspect data (SSL offloading) and or authenticate users etc. than, no, we don’t want such a machine on our internal LAN. Again, depending on the situation, opinions will differ on this.
In a ideal world we would like all of our DMZ machines to be stand alone with local configured accounts only, no need for domain joined devices or LDAP queries, internal database connections etc.
Note that the other way around also happens, companies stating that they don’t want any machines in their DMZ. Something I was told as well starting out as a junior admin, keep your DMZ as clean as possible! Unfortunately it isn’t that straight forward, as we’ve seen, sometimes we don’t have a choice unless you’re willing to take some risks.
Let’s summarize
before we continue with the MDM server, let’s first summarize what we’ve established so far. Let me start by stating that I’m just listing some of the possible combinations we might encounter with regards to DMZ server placement. I’m not saying I’m right, what works for you will depend on your specific needs and wishes, unfortunately that’s just the way it is. The same goes for some of the workarounds mentioned as well like creating a DMZ forest or implementing a RODC in your DMZ, both far from ideal but if you’re out of alternatives, it might be your best option.
Of course I’m assuming that today most networks, if not all, will have some sort of reverse proxy / firewall configured, it being a NetScaler, Microsoft ISA / ForeFront server, an F5 appliance or what have you. So unless certain machines can’t be ‘fronted’ have a look at one of the other options. And just to be clear, we’re only referring to publicly faced machines, Web, VPN, FTP, Mail, MDM etc.
Break it down
I think we can break it down into the following categories: data can or cannot be pre inspected. Users can or cannot be pre authenticated or authentication isn’t needed. Machines need or don’t need to be domain joined. LDAP might be needed, some machines need to be able to talk to an internal database, or some other ports might need to be open, this goes for inbound as well as outbound. So depending on which ‘category’ a machine falls into, some would say it can and must be placed in the DMZ while others might argue that the internal network is just as safe, or even more secure. However, in some cases it’s clear that the DMZ is your only valid option. Note that I’m leaving certificates out for now.
I’m pretty sure I left a few out, and to be honest I’m kind of hoping you’ll help me fill in the blanks here, thanks!
Room for discussion
As mentioned earlier, you could state that when data is pre inspected and users are pre authenticated, no matter if the machine is domain joined or not, that placing it on your internal LAN is best. But why is that? Seriously? If a machine is publically faced and we have total control, more or less, over the data and tha users connecting, wouldn’t it make much more sense to place it on your DMZ? I mean, data inspection and user authentication will be handled in the exact same way and if it’s domain joined and gets compromised ‘they’ will have the same level of excess from your DMZ as from your internal network. The same applies if it’s not domain joined by the way. When placed in your DMZ, single or double hop, at least there will be an extra firewall between the machine and your internal network providing us with an additional security barrier. Also, from the DMZ your publically faced machines will probably respond smoother and snappier (less hops) to external requests coming in.
If data can be pre inspected but users can’t be (pre) authenticated, than it all depends if the machine in question needs to be domain joined or not. If it does, than you probably might want to reconsider using the solution at all. The same applies if users can be pre authenticated but data can’t be inspected and the machine needs to be domain joined. In both cases you’ll end up with either uninspected data or unauthenticated users on your DMZ, but with direct access to your internal domain, or they’ll end up on your internal LAN directly.
But what if data can be inspected but users can’t be authenticated and the machine doesn’t need to be domain joined? You’ll probably end up using LDAP quries from the machine itself. Of course you could opt for local accounts on the machine itself, but for now let’s assume LDAP is used. The question is, does it need to be placed internally or externally (DMZ)? This way you could end up with user authentication taking place on your internal LAN, and we want to know who we let in right? Than again, it will be on a machine that isn’t domain joined and all data / traffic will be specifically addressed to that machine alone. What’s the worst that could happen?
XenMobile MDM
The XenMobile MDM server has a few specific characteristics that could influence it’s placement. For one, when users enrol their device, authentication (needs to) takes place on the MDM server before it’s ‘known’ by the system and certificates are exchanged, policies get applied etc. So no pre authentication.
Second, XenMobile needs to be able to contact Apple’s APNS, which stands for Apple Push Notification Services. Now this has been a point of discussion for some time now. Officially it’s stated that Apple’s APNS ports need to be opened continuously, which isn’t a preferred set up when it’s placed on your internal network. And even in your DMZ you would want to prevent such a configuration, but hey, if it can’t be changed you’ll just have to live with it. It’s also known by most that APNS traffic can’t be fronted with a reverse proxy, it needs a direct connection. Another potential security flaw.
To be honest, I’m not a hundred percent sure where these statements originated but what I do know, is that it isn’t all that bad. For example, I’ve found multiple articles discussing the placement of a XenMobile MDM server behind a proxy, APNS traffic included. I’ve also spoken to a few people that have successfully implemented XenMobile MDM this way. Let me clear up a few things on this. First of all, the APNS ports are only needed for outbound traffic! So it doesn’t need to have a two way continues connection with the outside. The APNS process works something like this, a change is made on the MDM infrastructure, a notification is than send from the MDM server to the APNS somewhere on the outside, next APNS informs the Apple device to go and check with the MDM server to see what’s new, it will use Home Worx / receiver for this, and there you go, outbound traffic only. It’s also stated by various Apple representatives that they handle millions of APNS requests per day and it hasn’t gone bad yet, let’s just hope it stays that way. I got the above image from an external resource, check out this link.
By the way, since it’s Apple’s Push Notification Service, this will only apply to iPhones and iPads, but I guess you figured that much.
As for APNS behind a NetScaler goes, have a look at this article, it’s from the Citrix Blogs: How to Allow Outbound Traffic on XenMobile Device Manager through Proxy
Now that we know that a reverse proxy (NetScaler) isn’t an issue, which also means that incoming traffic can be inspected as needed, that we only need outbound APNS traffic to be permitted and user authentication takes place on the MDM server, what about server placement? Oh, and did I mention that it doesn’t need to be domain joined?
Well, as stated earlier opinions will probably differ, no pre authentication means unauthenticated users on your internal domain which is a no go in most cases. But… the machine doesn’t need to be domain joined (they thought about this), it uses secure LDAP for user authentication, all traffic is specifically aimed at the MDM machine and we have several options to secure the device enrolment process. For companies that require higher, and more secure, levels of authentication we can implement third party two factor authentication combined with several high security options using certificates combined with usernames plus a one time generated PIN, or AD password, together with an invitation URL send from within the company. Does this change anything?
So you tell me, DMZ or internal LAN? Why?
As always, thanks for reading and or commenting.
Join [displaycount list=”Bas van Kaam”] other subscribers !
[optinform]
4 responses to “Citrix XenMobile MDM… To DMZ or not to DMZ? I might need your help one this one!”
Thanks Bas, very useful. and we are facing issues to configure RSA token and MS CA for two factor authentication on Netscaler, it doesn’t work, any ideas ?
Just now Citrix update us, that XenMoible is beyond the base capabilities of authentication within XenMobile (RSA token and MS CA for two factor authentication)
Thanks for the article. I was searching around for some general explanation of the DMZ. This one nails it.
No problem, glad it helped!