Exchange 2016 and network segmentation

Hello @Andy David - MVP , well that is something. Sort of terrible you have to come back and manually babysit this setting as Domain Controllers are decommissioned and replaced. In our case, we plan to always have redundant Domain Controllers in the same Exchange AD site, so theoretically Exchange should never need to reach out to different AD sites for Domain Controller services.

Any thoughts on using a stateful firewall rule to allow Domain Controllers to respond to queries, but not initiate traffic? If this works and is supported, it should prevent a threat actor from spreading through the network from an infected Domain Controller. Or at least make it more difficult for them.

Regards,
Adam Tyler

Well, it wouldn't be supported to have anything but ANY/ANY between Exch and DCs, but not supported doesn't mean "It wont work".
Its an important distinction. You can do what you want and whatever works. Its only an issue if it doesn't work - Then you can't go back to Microsoft support and say "Why doesn't this work" since its not supported.

I hope that makes sense :)

@Andy David - MVP , Right... I guess what I am getting at is, will it work? My role in the organization is still to provide maximum uptime at the end of the day and I'd hate to break Exchange by implementing network security changes that break the mail system. I tend to heed Microsoft best practices, but in this case it just seems reckless. Is there no network security focused paper on this topic, no other recommendations from them?

We're still in the process of rolling out Exchange 2016 right now, I'd hate to bork the install process because it can't connect to required resources.. Maybe get through the deployment with everything wide open and lock things down afterward, I'm not sure yet.

Regards,
Adam Tyler

Hello @Ashok M , there is a silly 1000 character limit, so this response is going to have to be spread over two posts. My apologies.

I think I expected your answer, however it is unfortunate. I can see why a ransomware attacker would seek to query AD sites and Services first thing, get a list of Domain Controllers, then focus their efforts as the primary target. Once one of these servers is owned, there is no restriction to moving throughout the entire network. In my opinion, the fact this is by Microsoft design is absolutely nuts.

End part 1..

@Ashok M

Reply Part 2:

So that said, I am wondering what else can be done to make an attackers life just a little harder. You've confirmed that Exchange Servers and Domain Controllers all need to be able to talk uninhibited. However, in my experience Domain Controllers aren't typically initiating TCP/UDP communications to Domain Joined workstations or member servers. Usually it is the client that is reaching out to get a copy of the sysvol directory or the latest version of group policy on a regular basis. If this understanding of how Domain Controllers serve clients is accurate, wouldn't it be possible to leverage a stateful firewall at least to prevent a potentially infected Domain Controller from "Initiating" unsolicited IP traffic to clients and member servers? In other words only allow Domain Joined systems to initiate connections and allow the stateful response only.

Regards,
Adam Tyler

Hi @AdamTyler-3751 ,

From network security standpoint, what you are trying to achieve is for your environment which has to be tested. on the other hand, we also have to consider service requirement. Here, we can provide suggestions on the recommendations, best practices, supportability for Exchange. With that said, restricting traffic between Exchange and DC's aren't supported which doesn't mean that it won't work. Like @Andy David - MVP said, exclusions can be set and tested, however there might be issues while working with support :)

Also, for the stateful firewall, there are instances wherein DC's can initiate traffic to the clients/member servers as well. One of the instances is to force GPO from DC which is one of the common administrative tasks which does require ports to be allowed from DC to Clients/member servers.

It is absolutely unreal to me that Microsoft has designed an enterprise server solution that is not securable with network segmentation. They've given us a set of servers (Exchange and DCs) that must communicate with EVERYTHING everywhere at all times.

At the rate that privilege escalation and RCE vulnerabilities are discovered for Windows and Exchange Server, it makes one wonder if Microsoft doesn't have a foot in the ransomware business. It seems they are actively working toward their customers being vulnerable and powerless against such an infection. No other self respecting IT professional would point a Windows server at the public internet and then not restrict it's access to the most vulnerable internal portions of the network. This cannot be a "best practice". I cannot be the only one to express this concern.

Regards,
Adam Tyler