Solving Network Connectivity for MDE and MDI
Hi, I’m Will Sykes, a Senior Security Researcher in Microsoft IR. My colleagues and I specialize in helping customers with incident response and compromise recovery. In our work with customers who’ve been the victim of cyberattack, we often must solve connectivity issues to support tools in a hybrid cloud configuration. Hybrid Cloud Challenges In today’s IT world we’re now implementing and integrating services that leverage cloud computing components. Correctly securing this often defies the adage of “never allow internet connectivity to sensitive systems” and can pose challenges to security and systems administrators to find a solution. In this article we’re going to cover a potential solution to allow the communication traffic for Microsoft Defender for Endpoint (MDE) and Microsoft Defender for Identity (MDI) in a more secure manner, while simultaneously disallowing the operating system to reach the internet. MDE and MDI MDE and MDI are both cloud powered solutions that need to run on all assets (MDE) and Tier 0 assets (MDI). To function these products must be connected to Azure endpoints, however the number of endpoints (MDI, MDE) can be large. This poses a challenge to traditional firewalls that can’t do address-based filtering and rely on IP filtering. In addition, both services cannot function in an environment where SSL inspection is done on the traffic. Thankfully both solutions support a proxy server, and the greatest advantage here is that the proxy can be configured at the MDE/MDI application level and not at the operating system level. During an incident response (IR), Microsoft DART will often deploy MDE and MDI to support real time monitoring and automatic actions to evict threat actors. Depending on the current state of the organization it may not be possible to reconfigure existing firewalls or proxies to support the new configuration. Because of the rapid nature of an IR and the need to have clear consistent network communication data from our toolset we needed an “in a box” solution. The Proxy Solution Because it’s possible to configure MDE and MDI to use a proxy without relying on the system configuration we developed a preconfigured Squid proxy solution that can be deployed automatically via a shell script in a fully configured setup. Let’s look at the parts of this solution. Operating System and Software To use the proxy, you’ll need to create an Ubuntu Linux server. Any version greater than 18.04 will do, and this can be physical or virtual. You’ll need to size the machine based on your expected load; in our experience we’ve run tens of thousands of endpoints through a proxy with 4 CPU cores and 16 GB of memory. The automation script will enable the Uncomplicated Firewall (UFW) and allow ports 22 for SSH and 3128 for Squid. The Squid install is basic; the configuration and the tuning is done via the script. The deploy script will build an endpoint file at /etc/squid/mdemdi.conf which contains the list of required cloud endpoints for MDE and MDI. It then creates a squid configuration file at /etc/squid/squid.conf with some defaults and lockdowns: The hosts allowed to use the firewall are the RFC 1918 internal networks. This can be scoped down or reconfigured depending on your network needs. The only destinations allowed by the proxy are in the mdemdi.conf file, every other destination is denied and only HTTP/HTTPS is allowed. Lastly the script will add some operating system tuning to support deployments in large environments based on our IR experiences. Internal Network Configuration Once you have the proxy configured, you’ll need to ensure that it can connect outbound to the internet unfiltered. If you have SSL filtering enabled on the proxy this will still cause MDE and MDI to fail communications. The proxy is configured to deny all internet destinations not needed by MDE and MDI, so this is a compensating control to avoid having unfiltered internet access. Of course, you can also add the identical filters to the network security devices allowing the proxy outbound internet. The next configuration step is to allow your internal networks to communicate to the proxy on TCP 3128, which is the configured listener for Squid. Configuring MDE and MDI MDE and MDI Version 3 To configure MDE you can use Group Policy to either use the native template or to manage the underlying Windows registry values. The setting can be found at Administrative Templates > Windows Components > Microsoft Defender Antivirus > Define proxy server for connecting to the network. If you need to configure devices not managed by Group Policy you can manage the following registry value: HKLM\Software\Policies\Microsoft\Windows Defender\ProxyServer This is a registry value of type REG_SZ and takes the following string format: http://<server name or IP>:<port> That’s it! Once that’s done you can confirm connectivity in the Windows Event View in the Applications and Services Logs -> Microsoft -> Windows -> Windows Defender -> Operational log. MDI Version 2 MDI can be installed directly with the proxy, however this must be done on the command line and not through the GUI. To do this add the ProxyUrl=" http://<server name or IP>:<port>" option the installer parameters. If you’ve already installed MDI and need to reconfigure the proxy that’s perfectly fine! You can use the handy MDI PowerShell Module's Set-MDISensorProxyConfiguration cmdlet or the built in utility Microsoft.Tri.Sensor.Deployment.Deployer.exe. Conclusion Based on our experiences in incident response, connectivity issues can slow or block vital security tools. The proxy solution allows network administrators to utilize a pre-configured appliance type solution to support MDE and MDI without having to modify existing security rulesets. A systems administrator can simplify their deployment of MDE or MDI by including the proxy solution as part of the application bundle, where its lifecycle can be tracked in lockstep with the application. Now the moment you’ve all been waiting for! The script can be downloaded at https://github.com/mswillsykes/squidmdemdi. Disclaimer The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
