LOG SENSOR AND TELEMETRY SERVICES IN ISOLATED NETWORK

Published Jul 23 2021 05:16 AM 4,073 Views
Microsoft

TelemetryFinal.gif

Dear IT Pros,

We knew that it is normal for Domain Controller and critical servers to be in isolated network without internet access.

How could we provide the cloud-based, Azure log analytic services for these objects? The services could originate from different products like DLP Cloud, MDE Cloud, MDI Cloud, Azure Log Analytics and more. What is the best way to accommodate these needs?

We will discuss the following topics:

  • Microsoft Monitoring Agent - MMA connection for older servers (Windows 2008R2, 2012R2, 2016 Servers) in isolated network.
  • Telemetry connection for newer servers (Windows 10, Windows 2019) in isolated network.
  • Stand-alone Sensor in isolated network.

Microsoft Monitoring Agent Connection for older Windows in isolated network

The steps below are applicable only to devices running previous versions of Windows such as: Windows Server 2016 and earlier or Windows 8.1 and earlier.  Offline devices in the same network of Azure Log Analytics

  • The only extra step is that we configure MMA with proxy setting pointed to Proxy Server IP address or FQDN together with its port. We need the following steps:
    • Install MMA with Cloud Service workspace key & ID for example: MDE ID and Key, Log Analytics Workspace ID and Key, DLP Service ID and Key.
    • Click Advance button and enter the Proxy IP Address:Port Number

 

LAB Demo

In this Demo Lab, we will use the Proxy Server on a Windows 2019 device instead of Proxy Appliance.

 Proxy Server on Windows 2019 with Internet Connection:

  • Download WinGate (80MB) and Install WinGate:

TanTran_0-1627039988988.png

 

 Configure Wingate \ services

>  WWW Proxy server

TanTran_1-1627039988998.png

 

On Windows 2012R2 Server,

Run MMA setup 

> Run MMA setup as usual

> Connect the agent to Azure Log Analytics (OMS)

TanTran_2-1627040117939.png

 

 

> Click Advance

TanTran_3-1627040117945.png

 

Typing in the proxy server IP Address and Port number (8080)

TanTran_4-1627040224489.png

 

> Next, Finish.
Result:

TanTran_5-1627040224494.png

 

There is no problem as long as the system time is within time discrepancy (15min) with Azure time.

 

Telemetry connection for Windows 10, 2019 in isolated network

For newer Server of Windows 2019 and Workstation of Windows 10, we need to use the built-in Telemetry service of Windows OS together with Proxy configuration to transport diagnostic logs to the Cloud Analytic Services like MDE,

For endpoint devices that aren't permitted to connect to the Internet, you need to configure a proxy connection to allow telemetry to forward log diagnostic data to Microsoft Cloud Service.

Let us start with an important notice:

  • An OMS gateway server cannot be used as proxy for disconnected Windows 10 or Windows Server 2019 devices when configured via 'TelemetryProxyServer' registry or GPO.
  • For Windows 10 or Windows Server 2019 - while you may use TelemetryProxyServer, it must point to a standard proxy device or appliance.
  • In addition, Windows 10 or Windows Server 2019 in disconnected environments must be able to update Certificate Trust Lists offline via an internal file or web server.

The WinHTTP configuration setting is independent of the Windows Internet (WinINet) Internet browsing proxy settings and can only discover a proxy server by using the following auto discovery methods:

  • Transparent proxy, no extra configuration needed.
  • Web Proxy Auto-discovery Protocol (WPAD), no extra configuration needed.
  • Registry-based configuration, manual static proxy configuration.
  • Netsh command, manual static proxy configuration. It is suitable only for desktops in a stable topology (for example: a desktop in a corporate network behind the same proxy)

Configure the proxy server manually using a registry-based static proxy

Prerequisite:

When using this option on Windows 10 or Windows Server 2019, it is recommended to have the following (or later) build and cumulative update rollup:

These updates improve the connectivity and reliability of the CnC (Command and Control) channel.

Enable access to Microsoft Defender for Endpoint service URLs in the proxy server

  • If a proxy or firewall is blocking all traffic by default and allowing only specific domains through, add the domains listed in the downloadable sheet to the allowed domains list.
  • The following downloadable spreadsheet lists the MDE services and their associated URLs that your network Firewall filtering rules must be set to allow the connections to them.

Spreadsheet of specific DNS records for service locations, geographic locations, and OS.
Download the spreadsheet here.

  • If a proxy or firewall has HTTPS scanning (SSL inspection) enabled, exclude the domains listed in the above table from HTTPS scanning.

Configure the proxy server manually using a registry-based static proxy

The static proxy is configurable through Group Policy (GP). The group policy can be found under:

 Administrative Templates > Windows Components > Data Collection and Preview Builds > Configure Authenticated Proxy usage for the Connected User Experience and Telemetry Service

TanTran_6-1627040346399.png

 

  •  select Disable Authenticated Proxy usage:

TanTran_7-1627040346407.png

 

  •  Enable "Configure Connected User Experiences and Telemetry"

TanTran_8-1627040346414.png

 

The policy sets two registry values TelemetryProxyServer as REG_SZ and DisableEnterpriseAuthProxy as REG_DWORD under the registry key HKLM\Software\Policies\Microsoft\Windows\DataCollection.

- The registry value TelemetryProxyServer is in this format <server name or ip>:<port>. For example: 10.0.0.3:8080

- The registry value DisableEnterpriseAuthProxy should be set to 1.

 

Configure the proxy server manually using "netsh" command

Use netsh to configure a system-wide static proxy.

 Note:

This will affect all applications including Windows services which use WinHTTP with default proxy. - Laptops that are changing topology (for example: from office to home) will malfunction with netsh. Use the registry-based static proxy configuration if you do not want the whole system communicate over the internet.

 

  • Open an elevated command line as administrator.
  • netsh winhttp set proxy <proxy>:<port>

For example: netsh winhttp set proxy 10.0.0.3:8080

To reset the winhttp proxy, enter the following command and press Enter:

  • netsh winhttp reset proxy

 

MDI Mirroring in Isolated Network

For MDI in Isolated Network, you will need to install a stand-alone sensor which will collect log data from all the Domain Controllers on the LAN Network.

Defender for Identity standalone sensor requirements:

  • The Defender for Identity standalone sensor supports installation on a server running Windows Server 2012 R2 or Windows Server 2016 (Include server core).
  • The Defender for Identity standalone sensor can be installed on a server that is a member of a domain or workgroup.
  • The Defender for Identity standalone sensor can be used to monitor Domain Controllers with Domain Functional Level of Windows 2003 and above.
  • 2 NICs, one for Management and one for Capturing log data.

Setup steps

  • Configure Network adapters

The Npcap driver allow network adapter to collect all network traffic packets (windows capture in promicuos mode). Download the Npcap version 1.0 from https://nmap.org/npcap/

  • Uninstall Wincap if you already installed it.
  • Installing Npcap with the following options: loopback_support=no and winpcap_mode=yes. (deselect the loopback support and select WinPcap mode). 

The Defender for Identity standalone sensor requires at least one Management adapter and at least one Capture adapter:

  • Management adapter - used for communications on your corporate network. The sensor will use this adapter to query the DC it's protecting and performing resolution to machine accounts.

This adapter should be configured with the following settings:

  • Static IP address including default gateway
  • Preferred and alternate DNS servers
  • The DNS suffix for this connection should be the DNS name of the domain for each domain being monitored.

TanTran_0-1627042299153.png

 

Ports

The following table lists the minimum ports that the Defender for Identity standalone sensor requires configured on the management adapter:

MANAGEMENT ADAPTER PORTS

Protocol

Transport

Port

From

To

Internet ports

       

SSL (*.atp.azure.com)

TCP

443

Defender for Identity Sensor

Defender for Identity cloud service

Internal ports

       

LDAP

TCP and UDP

389

Defender for Identity Sensor

Domain controllers

Secure LDAP (LDAPS)

TCP

636

Defender for Identity Sensor

Domain controllers

LDAP to Global Catalog

TCP

3268

Defender for Identity Sensor

Domain controllers

LDAPS to Global Catalog

TCP

3269

Defender for Identity Sensor

Domain controllers

Kerberos

TCP and UDP

88

Defender for Identity Sensor

Domain controllers

Netlogon (SMB, CIFS, SAM-R)

TCP and UDP

445

Defender for Identity Sensor

All devices on network

Windows Time

UDP

123

Defender for Identity Sensor

Domain controllers

DNS

TCP and UDP

53

Defender for Identity Sensor

DNS Servers

Syslog (optional)

TCP/UDP

514, depending on configuration

SIEM Server

Defender for Identity Sensor

RADIUS

UDP

1813

RADIUS

Defender for Identity sensor

Localhost ports

Required for Sensor Service updater

     

SSL (localhost)

TCP

444

Sensor Service

Sensor Updater Service

NNR ports

       

NTLM over RPC

TCP

135

Defender for Identity

All devices on network

NetBIOS

UDP

137

Defender for Identity

All devices on network

RDP

TCP

3389, only the first packet of Client hello

Defender for Identity

All devices on network

Capture adapter - used to capture traffic to and from the domain controllers.

  • Configure port mirroring for the capture adapter as the destination of the domain controller network traffic. You could use one of the following method:
        • Switched Port Analyzer (SPAN) – Copies network traffic ports to another port on the same switch. Both the Defender for Identity standalone sensor and domain controllers must be connected to the same physical switch.
        • Remote Switch Port Analyzer (RSPAN) – Allows you to monitor network traffic from source ports distributed over multiple physical switches. RSPAN copies the source traffic into a special RSPAN configured VLAN and switches’ trunks. RSPAN works at Layer 2.
        • Encapsulated Remote Switch Port Analyzer (ERSPAN) – Is a Cisco proprietary technology working at Layer 3. ERSPAN allows you to monitor traffic across switches without the need for VLAN trunks. For Defender for Identity to work with ERSPAN traffic, a switch or router that can decapsulate the traffic needs to be configured as the destination of ERSPAN where the traffic is decapsulated. Then configure the switch or router to forward the decapsulated traffic to the Defender for Identity standalone sensor using either SPAN or RSPAN.
  • On the Capture Adapter, TCP/IP v4 properties:
        • Configure a static non-routable IP address (with /32 mask) for your environment For example, 10.10.0.10/32.
        • no default sensor gateway and no DNS server addresses.
  • Installing the Sensor and configure MDI as the normal case, you could also take reference of the setup steps from Microsoft documents or from my techblog article “MDI Setup and Troubleshooting”

Limitation:

  • Defender for Identity standalone sensors do not support the collection of Event Tracing for Windows (ETW) log

 

I hope the information is useful for future deployment in isolated environment.

Until next time, Cheer.

 

Reference:

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.

 

Co-Authors
Version history
Last update:
‎Jul 24 2021 02:15 AM
Updated by: