Network Threat Prevention

The Network Threat Prevention feature of Jamf Protect helps further protect your macOS endpoint by preventing threats from reaching your devices. Network Threat Prevention provides additional protection by blocking the following types of threats:

  • phishing attempts

  • malware

  • Command and Control (C2) servers

  • unauthorized app stores

Network threat prevention provides category-based content filtering, which allows IT and security teams to prevent access to risky content. With network threat prevention, administrators can configure clear, informational, block page messages that will not confuse end users.

Network threat prevention can either be deployed independently, through a configuration profile in Jamf Pro (or another UEM); or can be deployed alongside a Jamf Protect agent deployment.

Configuring the network threat prevention feature of Jamf Protect involves the following steps:

  1. Activating your RADAR account

  2. Configuring a security policy.

  3. Configuring a block policy

  4. Deploying network threat protection to macOS devices

  5. Testing and validation

  6. Configuring UEM Connect from within RADAR

Network Threat Prevention Data Processing

Enabling network threat prevention in Jamf Protect results in all customer data (including personal data) processed by this feature being transferred, processed, and stored within Jamf infrastructure located in Ireland. If you do not enable network threat prevention there will be no change to how your data is processed when using Jamf Protect.

General Requirements

  • Administrator access to your Jamf Pro account

  • One or more target computers with macOS 11 or later, enrolled with Jamf Pro

  • Familiarity with deploying configuration profiles to macOS computers via Jamf Pro

Note:

If you use a firewall or proxy on your network add edns.wandera.com or *.wandera.com to your safelist to ensure that Network Threat Prevention operates as expected.

Jamf Protect network threat prevention is not compatible with EPP/EDR software that deploys a firewall network extension on the device (for example, Microsoft Defender or Crowdstrike Falcon). Due to macOS limitations, network threat prevention is disabled whenever an extension of this type is activated on the endpoint.

Activating Your RADAR Account

A RADAR account is required to use Network Threat Prevention. You will receive an email with instructions for how to activate your RADAR account. If you need assistance or have questions, contact Jamf customer success.

  1. Click Set a Password in the email from Jamf.
  2. Create a strong password as prompted.
  3. Log in with your email address and newly created password.
  4. Accept the Software License and Services Agreement when presented.

    This agreement is identical to the agreement you have already accepted to use Jamf Protect.

Configuring a Security Policy

With an active RADAR account, follow these steps to configure the service to protect your macOS devices from network threats according to your organization's security policy.

For more information related to configuring security policies, see the RADAR documentation Security Policy Configuration.

  1. In RADAR, navigate to Policies > Security > Threat Response.
  2. On the screen that appears, click Apply Smart Policy to apply suggested security default settings.
  3. Click Laptop under Filter by Platform.
  4. Review the pre-configured policies and modify to fit your organization's security requirements.
  5. Click Savein the top-right corner of the page.

Configuring a Block Policy

Create a block policy to enforce category-based internet content filtering or custom block rules. You can do this by selecting a default set of rules, and then configuring them as required.

For more information related to configuring block policies, see the RADAR documentation Block Policy Configuration.

  1. In RADAR, navigate to Policies > Internet > Block Policy.
  2. Under the Default Rules tab, select Block High Risk in the Pre-defined rules section.

    This applies the built-in policy that blocks known risky content.

  3. Review and modify the configured block policy rules, then click Save.

Deploying Network Threat Prevention to macOS Devices

In order to deploy Network Threat Prevention to macOS devices you need to download the configuration file from the Activation Profile in RADAR and deploy the configuration file using your UEM/MDM solution. See Deployment to Managed Apple and Android Devices in the Jamf Security documentation for detailed instructions.

For more information about Activation Profiles in RADAR, see Activation Profiles in the Jamf Security documentation.

About macOS UEM/MDM Support

Jamf Pro is currently supported with tested configuration profiles available in RADAR. Administrators may be able to modify the profile to work with their UEM/MDM solution, but will need to proceed at their own discretion. If you are a Jamf School customer, contact your Jamf Customer Success Manager for more information.

Important:

Jamf strongly recommends deploying Network Threat Prevention to test devices before deploying to production users.  Depending on your other networking tools and architecture, you may need to define Advanced Split-DNS Settings.

Testing and Validation

Use the following instructions to make sure Network Threat Prevention has been deployed and is working properly on your target devices.

There are two areas to check: on the target device endpoint itself, and in the RADAR administrative portal.

Validating Endpoints

Follow these steps on a device with Network Threat Prevention deployed. If your device doesn't match the validation steps below, check your UEM/MDM solution for profile deployment errors.

  1. Open the macOS System Preferences application.
  2. Click Profiles.

    You should see the name of the profile you created in your UEM/MDM solution with a DNS Settings payload present.

  3. Navigate back to System Preferences and select Network.
  4. Verify that you see an entry titled "DNS Settings".
  5. Verify that the profile is active, as indicated by a green dot and the word "Running" beneath the title of the profile.
  6. Verify that $UDID has been correctly replaced with a real device UDID in the DNS Settings URL. If the $UDID variable, or an alternative, is present, the profile has been created incorrectly in your UEM/MDM.
  7. If you have specified "Phishing" as a block category in the RADAR management console, open a web browser and navigate to https://phishing.threatops.co.uk, or try a custom blocked hostname as defined in RADAR.

    A block page appears, indicating that the content is not allowed to load.

Validating Devices in RADAR

When a new macOS computer is deployed from your UEM/MDM solution, it is automatically added to your RADAR account when it connects to the internet.

These devices are dynamically added to your device list. You must configure UEM Connect for Jamf Pro to display the correct platform, otherwise the device type appears as "Unknown" in RADAR.

  1. In RADAR, navigate to Devices > Manage.

    The devices you have deployed NTP to should appear, with random user identifiers.

  2. Verify that there is a green checkmark in the Network column for the device.
  3. Click the Details tab for a device in the table.

    If you have configured UEM Connect for Jamf Pro, the External ID matches the device's identifier in your UEM/MDM solution.

  4. Navigate to Reports > Internet > Blocks.

    A list of the sites that were blocked on the endpoint per the above endpoint testing should be shown.

  5. Navigate to Reports > Internet > Usage or Sites and Apps and verify that the reports show the allowed usage generated by your devices.

Advanced Split-DNS Settings

When deployed, the Network Threat Prevention service handles all DNS requests generated on a macOS device.

In more complex networking environments, there is a need for "split-DNS" handling, where DNS request routing is prescribed based on your specific networking requirements.

The DNS Settings profile used by the Network Threat Prevention service enables two levels of control that you may adopt based upon your networking requirements:

  • Disabling Network Threat Prevention completely under specific network conditions.

  • Configuring specific domains to always bypass the Network Threat Prevention service.

Both of these configurations rely on the DNS Settings profile's On Demand rules parameter. These rules are constructed using XML and must be crafted manually either in your UEM/MDM solution's UI or by editing the profile downloaded from RADAR before being uploaded to your UEM/MDM solution.  In either case, it is important that you test the profile changes on test devices to ensure proper behavior before deploying to production.

Modifying On Demand DNS Settings

Depending on your UEM/MDM solution, the On Demand rules section of the DNS Settings profile may or may not be directly editable via the solution's management console.

For Jamf Pro, the On Demand XML settings can be edited in the web app.

  1. Navigate to the "Jamf Protect NTP" configuration profile you imported during setup.
  2. Click Edit in the lower right.
  3. Select the DNS Settings payload.
  4. Scroll to On-demand rules.
  5. Follow the steps in the sections that follow based on your requirements.

    Keep the following in mind when making these changes:

    • The XML configuration must be free of syntax errors. Jamf recommends using a text editor with an XML validator to ensure your syntax is correct. An invalid profile will fail to be installed or updated on endpoint devices.

    • The On Demand rules are comprised of an array of dictionaries, with evaluation performed from top-down. Therefore, rules at the top of the array will be matched first when the evaluation is taking place.

    • Jamf strongly recommends making sure the On Demand rules provided through RADAR are retained to ensure service resiliency and fault tolerance. They should be placed after your organization's unique rules.

    • You can customize these configurations as required by your organization. However, support for specialized configurations is not available from Jamf Support.

    Note:

    For a full list of On Demand rules, see this documentation from the Apple Developer website.

Disabling Network Threat Prevention on Endpoints

There are certain situations where your network security policies require you to disable Network Threat Prevention completely on the endpoint. These situations include:

  • When devices are using an enterprise network that has a local security stack or proxy that the device must use.

  • When the device connects using a corporate VPN, all DNS requests must be handled by the enterprise's DNS name servers.

Note: If you want to bypass specific domains to handle split-brain DNS scenarios, see the Bypassing Specific Domains section.

To configure this rule, define the specific network state criteria that must be matched in order for Network Threat Prevention to be disabled. This criteria may include:

  • A Wi-Fi SSID

  • A DNS name server IP address

  • A DNS search domain match is assigned to the device

As part of the definition of these criterion, define the connection that should disconnect when that criteria is matched.

The following example shows a sample On Demand rules payload that does the following to the Network Threat Prevention service on the device, evaluated in this order:

  1. Disable Network Threat Prevention if the DNS search domain issued to a device matches *.customer.com.

  2. Disable Network Threat Prevention if the DNS name server addresses issued to the device is 10.102.46.20 or 10.102.46.30.

  3. Otherwise, enable Network Threat Prevention.

<array> 
  <dict> 
    <key>DNSDomainMatch</key> 
    <array> 
        <string>*.customer.com</string> 
    </array> 
    <key>Action</key> 
    <string>Disconnect</string> 
  </dict> 
  <dict> 
    <key>DNSServerAddressMatch</key> 
    <array> 
        <string>10.102.46.20</string> 
        <string>10.102.46.30</string> 
    </array> 
    <key>Action</key> 
    <string>Disconnect</string> 
  </dict> 
  <dict> 
    <key>Action</key> 
    <string>Connect</string> 
  </dict> 
</array>
Note:

You can use the following steps to discover the DNS search domains and DNS name service addresses that are configured by the network you are connecting:

In Terminal, enter the command scutil --dns when your macOS device is connected to the network in the manner in which you would like Network Threat Prevention disabled.

The resulting response should include a list of search domains and DNS name server IPs, like this: 

DNS configuration 
resolver #1 
  search domain[0] : cof.ds.customer.com 
  search domain[1] : ds.customer.com 
  search domain[2] : kdc.customer.com 
  search domain[3] : osd.dev.customer.com 
  search domain[4] : dev.customer.com 
  search domain[5] : uk.customer.com 
  search domain[6] : customer.com 
  nameserver[0] : 10.102.46.20 
  nameserver[1] : 10.102.46.30

Then, issue the same command when the device is "off net", and ensure the returned values sufficiently differ from the "on net" values that were returned.  You can then use those "on net" values to define the conditions in which Network Threat Prevention should be disabled.

Bypassing Specific Domains

In network environments where a "split-brain" DNS is present—that is, where hostnames belonging to a specific domain can only be resolved by (internal) private DNS name servers—it is often necessary to bypass those domains from the Network Threat Prevention configuration. Otherwise, those private/internal hostname lookups will be sent to Jamf, where a public resolution will be attempted and will fail in most cases.

This is very common where VPNs are used or for situations where a device should only be able to resolve and connect to specific services when directly connected to the organization's local network (for example via Wi-Fi or Ethernet). 

Unlike the solution to disable Network Threat Prevention on endpoints in this scenario, it may be desirable to keep Network Threat Prevention active to protect the device from network threat, but to bypass (that is, ignore) specific organization-owned domains.

To do this, define EvaluateConnection rules in the On Demand rules section of the DNS Settings profile. The DNS Settings ship from RADAR with some of these rules already configured, so you can add your own entries to the existing EvaluateConnection dictionary.

Assuming you want all DNS lookups destined to .company.com and .company.lcl to always bypass the Network Threat Prevention service—thereby using whatever DNS resolver has been set on the device given its current network connection—you would modify the On Demand rules as follows: 

<array> 
  <dict> 
    <key>Action</key> 
    <string>EvaluateConnection</string> 
    <key>ActionParameters</key> 
    <array> 
      <dict> 
        <key>DomainAction</key> 
        <string>NeverConnect</string> 
        <key>Domains</key> 
        <array> 
          <string>*.customer.com</string> 
          <string>*.customer.lcl</string> 
          <string>*.jamf.com</string> 
          <string>*.jamfcloud.com</string> 
          <string>*.push.apple.com</string> 
          <string>identity.apple.com</string> 
         <string>iprofiles.apple.com</string> 
         <string>setup.icloud.com</string> 
         <string>vpp.itunes.apple.com</string> 
         <string>deviceservices-external.apple.com</string> 
        </array> 
      </dict> 
    </array> 
  </dict> 
  <dict> 
    <key>Action</key> 
    <string>Connect</string> 
  </dict> 
</array> 
Note:

The service bypasses *.jamf.com and *.jamfcloud.com along with specific Apple services to enable service continuity in the event of a major Network Threat Prevention outage. This would allow the Network Threat Prevention service to be temporarily removed from endpoints in the event of a service outage. 

If you are not using Jamf Cloud, Jamf recommends adding the hostname (for example, mdm.company.com) used by your macOS devices to communicate with your MDM server to the list of EvaluateConnection hosts.

Using Multiple Bypass Rules

On Demand rules are processed from top to bottom; once a match occurs, all further rules are ignored.

This means that because the EvaluateConnection section always counts as a match, with the domains/hostnames contained within being bypassed or not, any further Connect or Disconnect actions that are added lower in the list of On Demand rules will always be ignored.

To exclude entire networks from using Network Threat Prevention, these rules must be added above the EvaluateConnection rule that is added by default to the payload.

Known Limitations

The following situations represent the product in its current state. This list will be updated as the functionality evolves and the limitations change.
App status column in RADAR

The app column is not applicable for Network Threat Prevention devices. Currently, red X icons display in this column indicating there is no app activity. This is a known issue and will be changed to a "not applicable" icon soon.

Block Policy

Network Threat Prevention macOS devices are affected by the "Traffic Interface: Domestic" block policy type at all times.

Reporting

Network Threat Prevention macOS devices are shown under the "Traffic Interface: Domestic" filter in the Reports section.

Captive Portal Networks
For devices running a version of macOS prior to 12.5, certain Wi-Fi networks that require authentication to reach the Internet—such as coffee shops, airplane networks, and hotels—may not work while the service is enabled. To avoid this limitation, upgrade devices to macOS version 12.5 or later. If it is not possible to upgrade the devices to macOS 12.5 or later, you can configure Network Threat Prevention in Jamf Pro with a scope that is limited to users running macOS 12.5 or later. For more information on configuring scope in Jamf Pro see Scope.
iCloud Private Relay

Jamf Protect Network Threat Prevention is not effective on end user devices if iCloud Private Relay is enabled on the device. This is because Apple designed iCloud Private Relay to take precedence over the DNS settings configuration used by Jamf Protect Network Threat Prevention.

Workaround: To ensure that Jamf Protect Network Threat Prevention is effective device-wide, including for applications that use iCloud Private Relay, you must disable iCloud Private Relay using one of the two following options: