Muokkaa

Jaa

Configure proxy settings on an OT sensor

  • Artikkeli

This article is one in a series of articles describing the deployment path for OT monitoring with Microsoft Defender for IoT, and describes how to configure proxy settings on your OT sensor to connect to Azure.

Diagram of a progress bar with Deploy your sensors highlighted.

You can skip this step in the following cases:

Prerequisites

To perform the steps described in this article, you'll need:

This step is performed by your deployment and connectivity teams.

Configure proxy settings on your OT sensor

This section describes how to configure settings for an existing proxy on your OT sensor console. If you don't yet have a proxy, configure one using the following procedures:

To define proxy settings on your OT sensor:

  1. Sign into your OT sensor and select System settings > Sensor Network Settings.

  2. Toggle on the Enable Proxy option and then enter the following details for your proxy server:

    • Proxy Host
    • Proxy Port
    • Proxy Username (optional)
    • Proxy Password (optional)

    For example:

    Screenshot of the proxy setting page.

  3. If relevant, select Client certificate to upload a proxy authentication certificate for access to an SSL/TLS proxy server.

    Note

    A client SSL/TLS certificate is required for proxy servers that inspect SSL/TLS traffic, such as when using services like Zscaler and Palo Alto Prisma.

  4. Select Save.

Set up an Azure proxy

You might use an Azure proxy to connect your sensor to Defender for IoT in the following situations:

  • You require private connectivity between your sensor and Azure
  • Your site is connected to Azure via ExpressRoute
  • Your site is connected to Azure over a VPN

If you already have a proxy configured, continue directly with defining the proxy settings on your sensor console.

If you don't yet have a proxy configured, use the procedures in this section to set one up in your Azure VNET.

Prerequisites

Before you start, make sure that you have:

  • A Log Analytics workspace for monitoring logs

  • Remote site connectivity to the Azure VNET

  • Outbound HTTPS traffic on port 443 allowed to from your sensor to the required endpoints for Defender for IoT. For more information, see Provision OT sensors for cloud management.

  • A proxy server resource, with firewall permissions to access Microsoft cloud services. The procedure described in this article uses a Squid server hosted in Azure.

Important

Microsoft Defender for IoT does not offer support for Squid or any other proxy services. It is the customer's responsibility to set up and maintain the proxy service.

Configure sensor proxy settings

This section describes how to configure a proxy in your Azure VNET for use with an OT sensor, and includes the following steps:

  1. Define a storage account for NSG logs
  2. Define virtual networks and subnets
  3. Define a virtual or local network gateway
  4. Define network security groups
  5. Define an Azure virtual machine scale set
  6. Create an Azure load balancer
  7. Configure a NAT gateway

Step 1: Define a storage account for NSG logs

In the Azure portal, create a new storage account with the following settings:

Area Settings
Basics Performance: Standard
Account kind: Blob storage
Replication: LRS
Network Connectivity method: Public endpoint (selected network)
In Virtual Networks: None
Routing Preference: Microsoft network routing
Data Protection Keep all options cleared
Advanced Keep all default values

Step 2: Define virtual networks and subnets

Create the following VNET and contained subnets:

Name Recommended size
MD4IoT-VNET /26 or /25 with Bastion
Subnets:
- GatewaySubnet /27
- ProxyserverSubnet /27
- AzureBastionSubnet (optional) /26

Step 3: Define a virtual or local network gateway

Create a VPN or ExpressRoute Gateway for virtual gateways, or create a local gateway, depending on how you connect your on-premises network to Azure.

Attach the gateway to the GatewaySubnet subnet you created earlier.

For more information, see:

Step 4: Define network security groups

  1. Create an NSG and define the following inbound rules:

    • Create rule 100 to allow traffic from your sensors (the sources) to the load balancer's private IP address (the destination). Use port tcp3128.

    • Create rule 4095 as a duplicate of the 65001 system rule. This is because rule 65001 will get overwritten by rule 4096.

    • Create rule 4096 to deny all traffic for micro-segmentation.

    • Optional. If you're using Bastion, create rule 4094 to allow Bastion SSH to the servers. Use the Bastion subnet as the source.

  2. Assign the NSG to the ProxyserverSubnet you created earlier.

  3. Define your NSG logging:

    1. Select your new NSG and then select Diagnostic setting > Add diagnostic setting.

    2. Enter a name for your diagnostic setting. Under Category ,select allLogs.

    3. Select Sent to Log Analytics workspace, and then select the Log Analytics workspace you want to use.

    4. Select to send NSG flow logs and then define the following values:

      On the Basics tab:

      • Enter a meaningful name
      • Select the storage account you'd created earlier
      • Define your required retention days

      On the Configuration tab:

      • Select Version 2
      • Select Enable Traffic Analytics
      • Select your Log Analytics workspace

Step 5: Define an Azure virtual machine scale set

Define an Azure virtual machine scale set to create and manage a group of load-balanced virtual machine, where you can automatically increase or decrease the number of virtual machines as needed.

For more information, see What are virtual machine scale sets?

To create a scale set to use with your sensor connection:

  1. Create a scale set with the following parameter definitions:

    • Orchestration Mode: Uniform
    • Security Type: standard
    • Image: Ubuntu server 18.04 LTS – Gen1
    • Size: Standard_DS1_V2
    • Authentication: Based on your corporate standard

    Keep the default value for Disks settings.

  2. Create a network interface in the Proxyserver subnet you created earlier, but don't yet define a load balancer.

  3. Define your scaling settings as follows:

    • Define the initial instance count as 1
    • Define the scaling policy as Manual

  4. Define the following management settings:

    • For the upgrade mode, select Automatic - instance will start upgrading
    • Disable boot diagnostics
    • Clear the settings for Identity and Microsoft Entra ID
    • Select Overprovisioning
    • Select Enabled automatic OS upgrades

  5. Define the following health settings:

    • Select Enable application health monitoring
    • Select the TCP protocol and port 3128

  6. Under advanced settings, define the Spreading algorithm as Max Spreading.

  7. For the custom data script, do the following:

    1. Create the following configuration script, depending on the port and services you're using:

      # Recommended minimum configuration:
# Squid listening port
http_port 3128
# Do not allow caching
cache deny all
# allowlist sites allowed
acl allowed_http_sites dstdomain .azure-devices.net
acl allowed_http_sites dstdomain .blob.core.windows.net
acl allowed_http_sites dstdomain .servicebus.windows.net
acl allowed_http_sites dstdomain .download.microsoft.com
http_access allow allowed_http_sites
# allowlisting
acl SSL_ports port 443
acl CONNECT method CONNECT
# Deny CONNECT to other unsecure ports
http_access deny CONNECT !SSL_ports
# default network rules
http_access allow localhost
http_access deny all

    2. Encode the contents of your script file in base-64.

    3. Copy the contents of the encoded file, and then create the following configuration script:

      #cloud-config
# updates packages
apt_upgrade: true
# Install squid packages
packages:
 - squid
run cmd:
 - systemctl stop squid
 - mv /etc/squid/squid.conf /etc/squid/squid.conf.factory
write_files:
- encoding: b64
  content: <replace with base64 encoded text>
  path: /etc/squid/squid.conf
  permissions: '0644'
run cmd:
 - systemctl start squid
 - apt-get -y upgrade; [ -e /var/run/reboot-required ] && reboot

Step 6: Create an Azure load balancer

Azure Load Balancer is a layer-4 load balancer that distributes incoming traffic among healthy virtual machine instances using a hash-based distribution algorithm.

For more information, see the Azure Load Balancer documentation.

To create an Azure load balancer for your sensor connection:

  1. Create a load balancer with a standard SKU and an Internal type to ensure that the load balancer is closed to the internet.

  2. Define a dynamic frontend IP address in the proxysrv subnet you created earlier, setting the availability to zone-redundant.

  3. For a backend, choose the virtual machine scale set you created in the earlier.

  4. On the port defined in the sensor, create a TCP load balancing rule connecting the frontend IP address with the backend pool. The default port is 3128.

  5. Create a new health probe, and define a TCP health probe on port 3128.

  6. Define your load balancer logging:

    1. In the Azure portal, go to the load balancer you've created.

    2. Select Diagnostic setting > Add diagnostic setting.

    3. Enter a meaningful name, and define the category as allMetrics.

    4. Select Sent to Log Analytics workspace, and then select your Log Analytics workspace.

Step 7: Configure a NAT gateway

To configure a NAT gateway for your sensor connection:

  1. Create a new NAT Gateway.

  2. In the Outbound IP tab, select Create a new public IP address.

  3. In the Subnet tab, select the ProxyserverSubnet subnet you created earlier.

Your proxy is now fully configured. Continue by defining the proxy settings on your OT sensor.

Connect via proxy chaining

You might connect your sensor to Defender for IoT in Azure using proxy chaining in the following situations:

  • Your sensor needs a proxy to reach from the OT network to the cloud
  • You want multiple sensors to connect to Azure through a single point

If you already have a proxy configured, continue directly with defining the proxy settings on your sensor console.

If you don't yet have a proxy configured, use the procedures in this section to configure your proxy chaining.

For more information, see Proxy connections with proxy chaining.

Prerequisites

Before you start, make sure that you have a host server running a proxy process within the site network. The proxy process must be accessible to both the sensor and the next proxy in the chain.

We've validated this procedure using the open-source Squid proxy. This proxy uses HTTP tunneling and the HTTP CONNECT command for connectivity. Any other proxy chaining connection that supports the CONNECT command can be used for this connection method.

Important

Microsoft Defender for IoT does not offer support for Squid or any other proxy services. It is the customer's responsibility to set up and maintain the proxy service.

Configuration a proxy chaining connection

This procedure describes how to install and configure a connection between your sensors and Defender for IoT using the latest version of Squid on an Ubuntu server.

  1. Define your proxy settings on each sensor:

    1. Sign into your OT sensor and select System settings > Sensor Network Settings.

    2. Toggle on the Enable Proxy option and define your proxy host, port, username, and password.

  2. Install the Squid proxy:

    1. Sign into your proxy Ubuntu machine and launch a terminal window.

    2. Update your system and install Squid. For example:

      sudo apt-get update
sudo apt-get install squid

    3. Locate the Squid configuration file. For example, at /etc/squid/squid.conf or /etc/squid/conf.d/, and open the file in a text editor.

    4. In the Squid configuration file, search for the following text: # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS.

    5. Add acl <sensor-name> src <sensor-ip>, and http_access allow <sensor-name> into the file. For example:

      # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
acl sensor1 src 10.100.100.1
http_access allow sensor1

      Add more sensors as needed by adding extra lines for sensor.

    6. Configure the Squid service to start at launch. Run:

      sudo systemctl enable squid

  3. Connect your proxy to Defender for IoT. Ensure that outbound HTTPS traffic on port 443 is allowed to from your sensor to the required endpoints for Defender for IoT.

    For more information, see Provision OT sensors for cloud management.

Your proxy is now fully configured. Continue by defining the proxy settings on your OT sensor.

Set up connectivity for multicloud environments

This section describes how to connect your sensor to Defender for IoT in Azure from sensors deployed in one or more public clouds. For more information, see Multicloud connections.

Prerequisites

Before you start, make sure that you have a sensor deployed in a public cloud, such as AWS or Google Cloud, and configured to monitor SPAN traffic.

Select a multicloud connectivity method

Use the following flow chart to determine which connectivity method to use:

Flow chart to determine which connectivity method to use.

  • Use public IP addresses over the internet if you don't need to exchange data using private IP addresses

  • Use site-to-site VPN over the internet only if you don't* require any of the following:

    • Predictable throughput
    • SLA
    • High data volume transfers
    • Avoid connections over the public internet

  • Use ExpressRoute if you require predictable throughput, SLA, high data volume transfers, or to avoid connections over the public internet.

    In this case:

    • If you want to own and manage the routers making the connection, use ExpressRoute with customer-managed routing.
    • If you don't need to own and manage the routers making the connection, use ExpressRoute with a cloud exchange provider.

Configuration

  1. Configure your sensor to connect to the cloud using one of the Azure Cloud Adoption Framework recommended methods. For more information, see Connectivity to other cloud providers.

  2. To enable private connectivity between your VPCs and Defender for IoT, connect your VPC to an Azure VNET over a VPN connection. For example if you're connecting from an AWS VPC, see our TechCommunity blog: How to create a VPN between Azure and AWS using only managed solutions.

  3. After your VPC and VNET are configured, define the proxy settings on your OT sensor.

Next steps

We recommend that you configure an Active Directory connection for managing on-premises users on your OT sensor, and also setting up sensor health monitoring via SNMP.

If you don't configure these settings during deployment, you can also return and configure them later on. For more information, see:

« Configure initial settings and activate your OT network sensor

Control the OT traffic monitored by Microsoft Defender for IoT »