User Tools
microsoft:secure_excange_2012_eac
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
microsoft:secure_excange_2012_eac [2017/01/10 15:20] admin |
microsoft:secure_excange_2012_eac [2017/01/12 11:44] (current) admin |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Securing access to Microsoft Exchange 2013 EAC ====== | + | ====== Exchange 2013 EAC Securing access to Microsoft ====== |
| The coexistence of the Exchange 2013 Administration Console (EAC) with the other Exchange website virtual directories represents a considerable security vulnerability for any organization that installs it using the out-of-box defaults. Since most organizations need Outlook Anywhere and EWS to be Web-facing, and usually OWA too, the EAC will also end up being publicly accessible – inadvisable security practice in itself, even more so for another important reason that I will explain. The EAC uses the IIS Virtual Directory /ecp which has other non-admin functions for normal email users, so it is not really desirable to try to limit access to it. Besides, an Exchange Service Pack or Cumulative Update is quite likely to reset the Virtual Directory settings and permissions later anyway. Now that the Exchange Management Console application has been retired, it is not practical to completely disable EAC unless you especially enjoy PowerShell, so we need to find a way to harden the server. | The coexistence of the Exchange 2013 Administration Console (EAC) with the other Exchange website virtual directories represents a considerable security vulnerability for any organization that installs it using the out-of-box defaults. Since most organizations need Outlook Anywhere and EWS to be Web-facing, and usually OWA too, the EAC will also end up being publicly accessible – inadvisable security practice in itself, even more so for another important reason that I will explain. The EAC uses the IIS Virtual Directory /ecp which has other non-admin functions for normal email users, so it is not really desirable to try to limit access to it. Besides, an Exchange Service Pack or Cumulative Update is quite likely to reset the Virtual Directory settings and permissions later anyway. Now that the Exchange Management Console application has been retired, it is not practical to completely disable EAC unless you especially enjoy PowerShell, so we need to find a way to harden the server. | ||
| Line 18: | Line 18: | ||
| The only valid mitigation therefore is to restrict access to the ECP virtual directory to local subnets – something that we had wanted to avoid, and which on first sight looks impossible (since it’s a Virtual Directory, not a Website that we can re-bind to a new IP address and firewall more restrictively). In order to do this you will need to install the IIS Security Feature ‘IP and Domain Restrictions’: | The only valid mitigation therefore is to restrict access to the ECP virtual directory to local subnets – something that we had wanted to avoid, and which on first sight looks impossible (since it’s a Virtual Directory, not a Website that we can re-bind to a new IP address and firewall more restrictively). In order to do this you will need to install the IIS Security Feature ‘IP and Domain Restrictions’: | ||
| + | |||
| + | {{ :microsoft:iis-ip-domain-security1.png |}} | ||
| + | |||
| + | For the Default Web Site’s /ecp Virtual Directory (which is the public one), configure IP Address and Domain Restrictions: | ||
| + | |||
| + | {{ :microsoft:iis-ip-domain-security-settings.png |}} | ||
| + | |||
| + | In there, click Edit Feature Settings… (in the right-hand pane) and set ‘Access for unspecified clients’ to Deny. Then use Add Allow Entry to define your permitted IP ranges. | ||
| + | |||
| + | As I mentioned in the opening paragraph though this will need to be checked after Service Packs and Cumulative Updates are applied to the Exchange Server, in case this configuration is lost. | ||
| + | |||
| + | In fact the same precautions against brute force attack of the Administrator account would also apply to earlier versions of Exchange, and for VPN connectivity – i.e. when AD accounts are being used for any public facing authentication, the built-in Administrator should never be granted remote access. | ||
microsoft/secure_excange_2012_eac.1484058042.txt.gz · Last modified: 2017/01/10 15:20 by admin
Page Tools
