Deploying Microsoft Defender for Servers in Network-Restricted Environments

[hspinto]

Microsoft Defender for Servers (part of the Microsoft Defender for Cloud security suite), being a comprehensive solution for server protection across multi-cloud and hybrid environments, requires the deployment of several agents to achieve its multiple protection capabilities. As many of our customers run their Windows/Linux server environments without direct Internet outbound connectivity, there is the need for guidance on how to successfully deploy Defender for Servers with such restrictions. This article aims thus to bring additional clarity by summarizing all the considerations that must be taken when deploying each Defender for Servers component in network-restricted environments.

IMPORTANT: The Microsoft Defender for Servers team recently released the strategy and plan towards Log Analytics Agent deprecation. Please, read it carefully before planning your Defender for Servers deployment.

General considerations

There are many types of network-restricted environments – from air-gapped to proxy-based outbound connectivity. As Defender for Servers is a cloud-based solution, the systems running in air-gapped or with intermittent connectivity environments are significantly limited in the protection they can get from Defender for Servers. For these scenarios, the Agentless Scanning capability of Defender for Servers already provides some protection.

The scenarios covered in this article focus on providing Internet outbound connectivity to machines via a HTTP proxy, which is common in enterprise customers when Private Link is not available. Proxy-based connectivity can be implemented either via a system-wide proxy (transparent proxy, auto-discovery, or operating-system-wide settings) or via manual per agent static configuration. Of course, the more transparent the proxy configuration is, the easiest it is to deploy Defender for Servers agents. Depending on the proxy configuration approach and on the operating system type, each Defender for Servers agent and extension has its own specificities detailed in the following sections.

For Windows systems, it is important to distinguish between WinINet and WinHTTP proxy settings. While WinINet settings are the most used by end users (e.g., when specifying Internet browser proxy settings), they have limited or no effect in Defender for Servers agents and extensions and are a recurrent cause of confusion. In any case, all machines should be configured whenever possible before proceeding with the Defender for Servers agents and extensions deployment, according to the recommendations below.

Microsoft Defender for Endpoint

The recommended approach for deploying the Microsoft Defender for Endpoint (MDE) sensor in Defender for Servers is through the MDE extension, which is triggered by turning the Defender for Endpoint auto-provisioning settings on in Defender for Servers. Once the MDE extension (MDE.Windows or MDE.Linux) is deployed into the protected machine, it enables and onboards Defender for Endpoint to the customer tenant. If the machine has network restrictions and does not have correct HTTP proxy settings, it will:

• [In Windows] Show up as successfully deployed, but the machine will not appear as onboarded in the Defender for Endpoint backend.
• [In Linux] Fail the MDE extension deployment and the Defender for Endpoint sensor will not be installed.

As the MDE extension deployment unfortunately does not support extension-level proxy configuration, it is crucial to ensure the operating system is configured according to the outbound connectivity restrictions, prior to enabling auto-provisioning. The HTTP proxy itself must also be configured to allow for the list of Defender for Endpoint backend URLs.

Windows

For Windows environments, you have many HTTP proxy configuration options (see detailed instructions). The more transparent (e.g., WPAD) or system-wide (e.g., WinHTTP) the configuration is, the more straightforward the MDE extension deployment is. In short, if you cannot go the transparent proxy way, use WinHTTP (simplest) or registry/GPO-based static configuration. Please remember that WinINet proxy settings are not a viable solution for Windows Server environments. For a detailed explanation of how the different Windows proxy options impact Defender for Endpoint behavior, I highly recommend reading this article.

Linux

For Linux environments, you have only two options: transparent proxy, which requires no additional configuration for Defender for Endpoint, or a static proxy. Currently, PAC, WPAD, and authenticated proxies are not supported. For static proxy configuration, you must follow the Defender for Endpoint for Linux static proxy discovery steps. You must not forget that installation-time proxy settings (required by the respective Linux package manager) are different from the post installation configuration ones (statically defined in the Defender for Endpoint service itself). Having both correctly configured is important not only at deployment time but also later in the MDE extension lifecycle – sometimes, the MDE extension may appear in a failed state, even if the MDE sensor is operating correctly, when the extension is for some reason redeployed in a condition in which installation-time connectivity is broken.

In some Linux distributions, the /etc/environment proxy definition may not be forwarded to the MDE extension at installation-time and will fail the extension deployment. In this case, you should provide proxy settings in the systemd drop-in file for the Azure Linux Agent (a.k.a. walinuxagent, in most distributions), which eventually runs the MDE extension deployment (see official documentation). To do so, follow these steps:

1. Create or edit the file 13-Proxy.conf in /lib/systemd/system/walinuxagent.service.d/
2. Add the following lines to the file:

[Service]
Environment=http_proxy=http://<hostname>:<port>
Environment=https_proxy=http://<hostname>:<port>

3. Save the drop-in file and run the following commands to let the service recognize the change:

sudo systemctl daemon-reload
sudo systemctl restart walinuxagent.service

Azure Monitor Agent / Log Analytics Agent

Many Defender for Servers features depend on logs being collected from the guest operating system, such as File Integrity Monitoring, Adaptive Application Controls, and others (see full list here). No matter what your option for log collection is, either the legacy Log Analytics Agent (a.k.a. Microsoft Monitoring Agent or MMA) or the new Azure Monitor Agent (AMA), both agents have a similar behavior and configuration options in the face of proxy-based Internet connectivity. If the machine has network restrictions and does not have correct HTTP proxy settings, it will not collect logs into the Log Analytics workspace, despite successfully deploying the extension (except MMA for Linux, which fails the extension deployment).

Both agents support static proxy configuration settings. For your reference, see the AMA documentation for proxy configuration and a similar reference for the MMA. In at-scale deployment scenarios, you will want to include proxy settings in the agent extension deployment template (e.g., in an Azure Policy definition). Unfortunately, as there are not built-in Policy definitions for proxy-dependent AMA/MMA extension deployment, you will have to build your own, including the following settings for each agent option. For AMA, the proxy settings to add to the extension deployment are documented in the link above. For MMA, you can add the following properties to the extension resource definition:

In Windows:

"settings": {
  "proxyUri": "host:port"
}

If your proxy requires authentication, you must add the following:

"protectedSettings": {
   "proxyUser": "user",
   "proxyPassword": "pass"
}

In Linux (see documentation:(

"protectedSettings": {
  "proxy": "[user:pass@]host:port"
}

Before deploying your preferred agent, do not forget to ensure your proxy has the required rules for each of the agent endpoints, by following the AMA or MMA documentation for proxy/firewall requirements.

It is worth noting that both agents support connectivity to Log Analytics over Private Link. You can find out more in the Private Link for Azure Monitor documentation.

Guest Configuration Extension

If you are using Defender for Servers with the AMA agent, you will need the Guest Configuration extension to analyze operating system security baseline settings in Windows and Linux machines. This was available out of the box in the legacy MMA agent but requires a specific extension for AMA scenarios. Although the Guest Configuration extension does not support proxy settings, you can make it communicate privately over the Azure Virtual IP address by applying a specific tag to the respective virtual machine (see documentation, valid for Azure Virtual Machines).

The Guest Configuration extension is not required for Arc-enabled servers because it is included in the Arc Connected Machine agent. However, you must ensure the Arc agent connectivity is configured according to the network restrictions it may face (see details below).

Qualys Agent

Customers who implement vulnerability assessment with the Qualys agent must consider that the Qualys extension configuration does not accept any proxy configuration details. The proxy settings for the Qualys agent must be set after the extension is installed. See the documentation for more details.

Azure Arc-based scenarios

All the multiple agent configuration options we have seen so far apply equally in multi-cloud or hybrid scenarios with Azure Arc. However, with the Arc agent, there is of course an additional network configuration required. Azure Arc supports both proxy-based and Private Link outbound connectivity. You can define the HTTP proxy with system-wide settings or else with static configuration (check the implementation details for Linux and Windows). You are even given the option to define static proxy configuration when generating the Arc agent deployment script in the Azure Portal. If you prefer to use private endpoints instead, you can follow the step-by-step guide for Azure Arc with Private Link. No matter what the Azure Arc connectivity option is, do not forget that all the other agents have their own approach and must be configured separately, as we have described above.

Conclusion

Microsoft Defender for Servers depends on several agents to provide all its capabilities and all these agents require HTTP outbound connectivity to public backend services. In typical enterprise scenarios, Azure virtual machines or on-premises/third party cloud machines do not have direct access to the Internet and thus systems administrators need to plan for the deployment of Defender for Servers agents according to the connectivity configurations supported by each of them. This article hopefully provided a comprehensive compilation of all the options available and links to the product documentation containing all the relevant guidance for this matter. Please let us know if some scenario is not covered here or if information is missing.