One of the most frequent questions that I receive is about placing Exchange Front End server in DMZ. Personally I believe that placing any domain member (not just Exchange Server) in DMZ does not protect your internal network or your domain/forest.
Let’s take a look at how an attack to domain member placed in DMZ could look like. This is not limited to Exchange servers in DMZ, but applies to any domain member server that you might want to put in DMZ and open access to it from the internet. Such attack can be performed to any server in DMZ and again is not limited to domain members.
We have few possible targets. E.g. Windows Server, IIS or applications installed on the server. We will assume that operating system has latest updates applied. For this attack, we will focus on the third option -- 3rd party applications. I often (too often) see 3rd party applications running on dedicated servers (e.g. Exchange Front End Server in DMZ). These 3rd party applications are most often not patched and are running under some very privileged account on the system.
For this attack we will assume that 3rd party application has at least one vulnerability. Very common these days are SQL or other type of injection attacks due to lack of input validation. In our attack, hacker finds a bug (all he needs is one) in the application and since application is running under System account (still common these days) anything that is executed through the bug in the application, also runs as System.
Attacker, using bug in the application, uploads a key-logger to the server and installs it. He will now wait till the system administrator logs on to the server using his domain credentials to perform common administrative tasks. Since our attacker is all excited about this attack and can’t wait too long for system admin to log on, he can speed things up by e.g. stopping IIS service on the server. First user that will notice that web application is not working will very likely notify system administrator about it.
I sometimes see (unfortunately in too few occasions) that system administrators only have full permissions on servers that they need to take care of and not all of them. Attacker in our case can protect himself just in case and removes all users from local administrators group, leaving only “Domain Administrators” group as the member. This way attacker made sure that account that will logon to the server next, will be member of Domain Administrators.
Once the attacker has credentials of domain administrator, he can logon to the server. Now he stops and thinks about what would be the coolest thing to do. My guess is that he would run “dcpromo” on the server and make it a domain controller. The attacker now actually owns a domain controller in DMZ. In other words, he owns the domain and anything that is part of domain.
Main problem that I see too often when placing server in DMZ is false sense of security that DMZ provides. As we can see, placing domain member server in DMZ does not protect domain or internal network.
So, to DMZ or not to DMZ? You will have to decide for your own network. :-)
In the second party of “To DMZ or not to DMZ” I will write about protecting member servers that are accessible from the internet.