Best practise for setting up an (Exchange) Webmail & Web DMZ server behind a MX(84)?

Jonas_Eriksson
Here to help

Best practise for setting up an (Exchange) Webmail & Web DMZ server behind a MX(84)?

Hi, I am trying to help a friend with some setting up, or actually, it is partially set up already at this point by some external consultant.

 

An MX84 is connected to the internet (got AMP as well), and on the intranet there is a Windows Server 2016 with Exchange, SQL, file server. The Webmail and a "webserver DMZ" should be reachable from the internet on their respective public IPs, and currently 1:1 NAT mappings are in place for port 443 (webmail) on PublicIP1 to InternalIP1 and 25 for the webserver dmz which I believe is Exchange sending emails out for PublicIP2 to InternalIP2. This Exchange Server does not receive mails directly btw.

 

The question is now what else needs to be configured in the Level 3 Firewall settings, to prevent this from becoming insecure? I am assuming there should be a rule in place to limit the DMZ access to the Internal network, i.e. having ALLOW Any InternalIP2Range (DMZ) to InternalNetworkRange Any would be silly (that's how it is right now, which looks a bit questionable, no?  Many thanks for - probably obvious - hints! 🙂 

12 REPLIES 12
Adam
Kind of a big deal

If you are using 1:1 NAT then the default firewall is deny all.  As long as you only set the allowed inbound connections to the minimum ports you need there shouldn't be an excess.  That is about as secure as you can get aside from having the IDS/IPS enabled if you've licensed that.  Also making sure your servers are patched and that they have their own client protections in place. 

Adam R MS | CISSP, CISM, VCP, MCITP, CCNP, ITILv3, CMNO
If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.

Thanks Adam, yes the 1:1 only specifies one port each I believe (25 + 443), is that what you meant? I believe the Level 3 FW rules then need to open only the required ports from DMZ to internal network and vice versa. IDS/IPS is also enabled, yes.
Uberseehandel
Kind of a big deal

To be honest, for many organisations it more secure, more reliable and more cost effective to use Exchange as a Service. Keeping it working is somebody else's problem, and in our experience, we can rely on it.

 

We no longer have any servers at any of our sites, they are all virtual and all hosted elsewhere. Simples . . . 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

Thanks, I agree in general that this is best for small businesses. Some have specific requirements though to not use outsourcing.


@Jonas_Erikssonwrote:
Thanks, I agree in general that this is best for small businesses. Some have specific requirements though to not use outsourcing.

Outsourcing involves getting rid of all the people who know what they are doing and then paying through the nose to have a bunch of know-nothings look after the systems.

 

SAAS and PAAS are fundamentally different to outsourcing. In actual fact, they are extremely cost effective. We still have complete control over what we do and we can rely on better up-times, flexible capacity, and very fast roll-out of additional services. It lets IT/IS staff concentrate on the interesting stuff. It makes no difference whether our servers are in Switzerland or the UK or California, it makes no difference whether the servers are real or virtual. In reality our Exchange Server is more secure and has better failover systems when run as a service than if it were in-house.

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

I agree with @Uberseehandel - best practice would be to use something like Office 365 and forget the issue,

Yes, thanks for your input but as I wrote earlier some companies have requirements that prevent this option.


@PhilipDAthwrote:

I agree with @Uberseehandel - best practice would be to use something like Office 365 and forget the issue,


And then make sure you've whitelisted all the office 365 addresses if you have enabled Spam and Malware blocking on the MX! 🙂


@AnythingHostedwrote:

@PhilipDAthwrote:

I agree with @Uberseehandel - best practice would be to use something like Office 365 and forget the issue,


And then make sure you've whitelisted all the office 365 addresses if you have enabled Spam and Malware blocking on the MX! 🙂


On my list of things to do later this year, after getting to grips with the API, is updating the whitelist from the RSS feed automatically. There are too many entries to do this manually every month just for MS, let alone the other big services sites. When I have mentioned this to some (quite prominent) dev-ops types, they have looked blank. It seems an obvious one to me. For giggles, I wonder if Alexa .  . . 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
MarkW
Here to help

Hey, Jonas.  Since I don't have all of your setup details, I'm going to just try and advise on the way it SHOULD be done (well, SHOULD according to MS, anyway!)

 

I went looking for some documentation on this, but didn't come up with it right away, going from memory the only role MS supports in the DMZ is the edge transport role on 2016.  If you have a DMZ setup and want to publish Webmail to the outside world you need some kind of reverse proxy.  Part of the reasoning I remember reading is a webmail server has to be a domain member and have a lot of ports open for exchange and domain communications.  So rather than opening up all those ports that are needed, just open 443 on the proxy.

 

Microsoft has a 'free' one, that is call Web Application Proxy (WAP).  It's just a role that can be installed on a 2012R2 and I think 2016 server.  With this server in place the only L3 rule you need from DMZ to Internal network is 443 to be allowed to the servers you are setting up the proxy for (like RDS and Webmail maybe) and the ADFS server.  

 

So the answer to what ports you need to open from DMZ to LAN depends on what is actually in your DMZ.  Hopefully that helps.  

 

 

MRCUR
Kind of a big deal

You note that the Exchange server doesn't "directly receive mail" but port 25 is NAT'd to it. If this is accurate, and you're using a hosted spam filtering service, then you should limit the 1:1 NAT remote IP's to those of the hosted spam service so that 25 isn't simply open to the world. 

MRCUR | CMNO #12

Hi, as far as I understood it, this was meant to be so that the local Exchange can send out, and while simply that server could have FW port 25 opened, I am wondering if they felt the 1:1 NAT was required for the lookup of the sending IP to ensure delivery. But yes, if they are using an external spam filter for MX/incoming mail, then perhaps it would make more sense to solely use that one for sending out as well...
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels