Thanks for your feedback on my article. ItĂs always great with feedback especially from guys like you, but this time I must admit I miss some arguments as to why my recommendation is as wrong (or bogus) as you indicate it is
You state in your blog post thatĂs weĂre only speaking a handful of ports that requires to be opened in the intranet firewall, when putting the FE server(s) in the DMZ. Everything is of course relative but I donĂt call below list a handful of ports (no matter if itĂs a firewall facing the Internet or a DMZ).
˛ 53 (Transmission Control Protocol [TCP], User Datagram Protocol [UDP]) - Domain Name System (DNS).
˛ 80 (TCP) - Required for Outlook Web Access access for communication between Exchange front-end and back-end servers.
˛ 88 (Transmission Control Protocol [TCP], UDP) - Kerberos authentication.
˛ 123 (UDP) - Windows Time Synchronization Protocol (NTP). This is not required for Windows 2000 logon capability, but it may be configured or required by the network administrator.
˛ 445 (TCP) - Server message block (SMB) for Netlogon, LDAP conversion and Microsoft Distributed File System (DFS) discovery.
˛ 3268 (TCP) - LDAP to global catalog servers.
Other things adding to this is the number of Exchange back-endĂs and Global Catalog servers youĂve got on the internal network (as I mention you can make use of IPSec but itĂs too complex for many of the organizations out there).
If you place the FE server(s) on the internal network to publish OWA, RPC over HTTP(S), EAS, OMA, you only need to open one single port to the FE server(s) and thatĂs port 443. With the proper monitoring tools this is accepted as a secure solution in many organizations (yes also without an ISA Server in the DMZ), and keeps you from what could easily become an administrative overburden and an unnecessary high IT budget. Also bear in mind thereĂre a lot of small to mid-size organizations out there, and few of them has the possibility of investing in hardware, OS, an ISA Server license, training of internal IT staff and perhaps fees for external consultants.
My experience is organizations want simple and secure solutions nowadays; they simply donĂt have the time or the budget for ˘too complex÷ deployments.
BTW even though you put your FE server(s) on the internal network, you should of course still follow the hardening guidelines and use the templates from below MS Exchange paper:
The fact is, if you have an ISA firewall, you can very easily create a DMZ segment for the front-end and create strong access controls to the front-end from the Internet, and to the back-end from the FE. It is not a complex, nor difficult configuration. Its a matter of creating a few access rules and configuring the firewall properly.
I do consider this list a very small list of ports. Just eight ports out of over 65K ports. Worms and other exploits leverage any random port. If the FE exchange server were somehow compromised by an automated exploit (which is not out of the question, as I've seen this in more than one FE Exchange deployment), the back-end and the rest of the network would have been protected, since the worms didn't use those ports in the list required for intra-Exchange and intra-domain communcations.
The fact is, an Internet facing host is in a different security zone than a non-Internet facing host -- even if you pre-authenticate at the firewall, which may or may not be the case depending on the prototocols used and the functionas the FE Exchange Server provides. Therefore, as a member of a separate and distinct security zone, it behooves us to take advantage of the security technologies available to use to limit the damage from a potential compromise of a lower security from spreading to a higher security zone.
The cost of a third NIC in a ISA firewall is inconsequential. The cost of outbreak starting at the FE Exchange Server and spreading the back-end and the rest of network is substantial.
The only overhead is a few Access Rules on the ISA firewall.
However, if you don't have an ISA firewall, then its every man for himself
I understand your points but for example regarding protection against worms, you don't really need to place the FE server in a DMZ, only if itĂs acting as a SMTP gateway as well. In most of the environments I'm dealing with they typically have a dedicated SMTP gateway doing all the AV/AS filtering before the mail reach the internal network. And when you typically donĂt have more than one port opened to the FE server(s) on the internal network, it would be very hard to have them exploited (if possible you could as well exploit the back-end servers).
I donĂt say your preferred method is wrong, just that there is other often less complex and very secure solutions as well.
From: United Kingdom
Personally, I think the "don't put an FE in the DMZ" is based upon old fashioned DMZ networks where the internal firewall was a simple packet filter. In this scenario, opening up the ports for FE to BE traffic essentially opened up comminications from a, by definition, untrusted host, to key authentication servers in corpnet. Unfortunately, a simple packet filter had no understanding of this communication, as it only worked at the network layer.
However, now that ISA is being used more and more, for a "modern network" it makes sense to use ISA's application filtering capabilites and place the FE in an ISA perimeter network (notice I didn't call it a DMZ ) Surely this is always going to be better than simply placing it on the corpnet. Persoanlly if the FE was to be compromised at least ISA would be restricing acccess from the FE to coprnet, as opposed to having a compromised host direct on the coprnet itself.
Having said that, a lot of people are not switched on to the ISA perimeter network topology and still use the term DMZ when they actually mean screened subnet or when they are referring to the area between front-end and back-end firewalls.
I will be honest, many of our installs involve publishing an FE which is on corpnet, but this is often becasue customers wont implement a back to back topolgy with ISA protecting the internal element and hence faciltiate the option for an auth perimter network. I think at this stage it is good that people are at least using ISA for application layer filtering rather than tradtional firewalls, but we still have a way to go before they fully understand and importantly "trust" a firewall with MS on the tin...however silly that seems to us converts
From: United Kingdom
Noticed the following quote in one of MS's most recent best practices for Exchange publishing:
"This guide assumes that the Exchange front-end server is placed on the Internal network along with the Exchange back-end servers and not in the perimeter network. This design is a recommended scenario in the Planning an Exchange Server 2003 Messaging System guide. For additional security, it is also appropriate to place the Exchange front-end and back-end servers on a separate network with an ISA Server computer separating them from the internal LAN. This way, Exchange servers also benefit from the ISA Server remote procedure call (RPC) filter to protect the mailbox servers."
From: New Zealand
I had a similar dilemna in April 2004 in what is the best way to securely deploy Exchange. Fortunately at the time the " You had me at EHLO" blog came out, so I posted an email to them (and in particular KC Lemson who I believe was one of the Exchange PM's at the time). And my questions were the same - FE in DMZ... whole bunch of ports open... this seems insane!
I pointed out that between the sets/releases of documentation (E2K and E2K3) there seemed to be a paradigm shift in terms of opening ports vs. using reverse-proxy scenarios.
"* In the E2K docs, it said to put the FE in the DMZ, open a bunch of ports to the intranet where the BEs are. This is bad. * In E2K3 docs, it says to put the FE on the intranet and use a reverse proxy like ISA in the DMZ, and only punch 443/80 to the FE on the intranet. This is good.
Basically, you're right - in e2k, the documentation was not very good, in order to have a FE/BE scenario with a DMZ, you had to have a whole host of ports open from the DMZ to the intranet, including RPC ports for authentication (unless you used pass-through authentication which we did not do a good job of recommending against at the time). One of the reasons for this is that ISA 2000 didn't exist at the time that that documentation was written. By the time we updated that paper to talk about the reverse proxy scenario in more detail, ISA had been released and we were either in the middle of developing or had just released Exchange 2000 SP2 (I can't quite remember the date), and it had a set of functionality that made that scenario unnecessary."
I guess it is a case of getting the latest and most sound documentation available as Jason has so kindly pointed out - AND reading it.
I know what I would rather do - ISA + FE + SSL Bridging = sleeping well at night. This seems obvious, and I am preaching to the converted but attacks are surfacing on 443 and thus we need to be vigilant about this on our (and other people's) networks.
And if companies are getting to a level of complexity that they do require FE and BE scenarios then surely ISA is the perfect solution to the issue of 'where do we put these things'?
From: New Zealand
quote:It seems that each of the product groups has their own opinion or view on best practice...
Absolutely - they are the ones who know their products inside and out and some of these products are beasts. Heck - it is sometimes hard enough to concentrate on one product let alone a raft of them! I think (personally) it is a case of reading around what is best case in x situation and what is best case in y situation. And sometimes ISA is a great fit (if not the best fit) in the mix. Please don't talk about LCS and ISA - this still pains me deeply, especially when my company is saying 'Yes please' and I have to say 'well not yet' because of the lack of support in ISA. Major faux pas by the LCS/ISA teams... Two lines from the following document that still break my heart: "When you use ISA Server 2004 with Live Communications Server, only presence and instant messaging will be enabled for outside users. Scenarios involving features such as audio and video, data collaboration, and file transfer are not supported." But if that's my only grizzle with ISA then I'll take it.
From: United Kingdom
Nice to hear others share my LCS/ISA pain!
Quote from the LCS locker-room:
LCS Developer 1 - "What do you reckon we should do about external access to LCS Chuck"
LCS Developer 2 - "Err...we could talk to the ISA team Doug?"
LCS Developer 1 - "Nah, those guys take ages and boy are they paranoid"
LCS Developer 2 - "Ok, lets create an access proxy just for LCS that does a similar job, but we can control it. Anyhow, who uses ISA, most people use PIX or Checkpoint as they are good firewalls - aren't they?"
LCS Developer 1 - "Cool, what about ISA? Won't it break LCS?"
LCS Developer 2 - "Yeah, but they can use our proxy to sort that out "
D O H !
[ September 26, 2005, 06:52 PM: Message edited by: Jason Jones ]
From: New Zealand
Actually on the subject of LCS pain, and a complete departure from the original conversation (my apologies!), have either of you (Tom, Jason) managed to get LCS working at all through ISA? I have a couple of theories but my depth on LCS is, well, shallow and I have got that pressure building from above in regards to it. Our 'theory' at present is to have a LCS Proxy in the Perimeter network conversing through ISA to the core LCS server internally. BUT somewhere in there a NAT would need to occur (either Internal to Perimeter as our network is currently) or Perimeter to External (as our network is currently). Would using Routable addresses throughout make a difference? Don't laugh, I do know places in NZ that do this in order to hold their IP Allocation... Would a FE/BE ISA configuration work in this setup? Could splitting the networks such that a Perimeter with a limited number of 'internal' addresses work (there would be no NAT involved talking true Internal to the isolated Perimeter - it would be a Route)? I know that a major issue, from Tom's book, is the NATing of the client, so if you got around this could the issue be resolved? Just some questions to make everyone think a bit harder... Unfortunately I have not had time recently to implement a test on the split idea (Proxy and core) but I feel the time is coming so thought I would ask those who know and share the pain...
From: United Kingdom
Severly off topic now, but I am sure Tom won't mind as the thread had reached a stalemate anyhow
Yes we have done it both ways using the LCS access proxy (AP) e.g. without ISA and using ISA server publishing.
The architecture I used without ISA was:
LCS Client => Internet => LCS AP External Interface => LCS Internal Interface => Internal Network
Didn't really like this approach as it places quite a bit of trust in the AP so I tried the following:
LCS Client => Internet => Packet Filter DMZ => LCS AP External Interface => LCS Internal Interface => Internal Network
Finally I wanted to add ISA to the party as the best overall security solution:
LCS Client => Internet => Packet Filter => ISA Perimeter Network Interface => LCS AP External Interface => LCS Internal Interface => Internal Network
This worked pretty well but it needed ISA rules to server publish the AP on the LCS SIPS protocol (TCP5061). Once ISA was using server publishing, you lost all LCS functioanlity apart from presence and instant messaging.
For all scenarios, the AP should be hardened and in reality need to run very few services or be able to do that much.
Another important point is that you need your ISP to create SRV records so that the LCS client and auto locate the LCS server externally. This allows LCS client to seamlessly find the LCS server in and out of the office...works very well and cool! Assuming you can get your ISP to understand what SRV records are!
The problem is that people need to decide on functionality vs. security and there is no way to achieve this with ISA unless they write an LCS filter (or someone else does???) Sounds like a nice project for Greg @ Collective Sofwate
[ September 27, 2005, 07:08 AM: Message edited by: Jason Jones ]
From: New Zealand
Cool - thanks for the feedback Jason.
Personally I could not care less if people outside the organisation knew that I was on the phone (presence) and I sure as heck don't want to share data with them through IM! Hey that's why we have things like Sharepoint and Exchange!
I thought it might be a case of a filter being written to get everything sorted out... perhaps a task for the ISA team in SP2???
As we run our own DNS service I should not need to talk to the ISP but I will bear it in mind for our clients. Some of the ISPs here are a bit smart but it is the exception rather than the norm. It does come down to the decision on whether to expose IM functionality to the internet in the first place and that's not a decision I have to make, I just have to advise on the technological pitfalls of it... I figure there are a bunch of ways of getting in touch with me other than just IM so...
Anyway, many thanks again, and once I get some time to have a tinker I will supply any feedback (positive, negative, crying with my head in my hands) that I have from the 'experience'.
Tom, I have bought several of your books and I have even recommended to some of my peers that they pay special attention to any and all of your publications. With that said I am really hoping you are able to help me. We have just deployed ISA 2004 and everything works great except for SUN JVM applications. Please tell me that there is a fix for this and if you can guide me in the right direction.