Configuring Network Threat Prevention

Preview Feature Documentation

Previews give you a first look at upcoming features and functionality, and allow you to provide feedback and submit defects to our software developers. Preview features and documentation are provided for testing purposes and should not be considered final.

The Network Threat Prevention feature of Jamf Protect helps further protect your macOS endpoint by preventing threats from reaching your devices. This Preview feature:

  • Blocks threats such as: phishing, malware, Command and Control (C2) servers, and unauthorized app stores

  • Allows category-based content filtering, enabling IT and security teams to prevent access to risky content

  • Can be deployed through a Jamf Protect installation without an additional agent by utilizing Apple-native technology built into macOS, or as a standalone agent-less network threat prevention solution through Jamf Pro

  • Contains built-in HTTP and HTTPS block pages presented with clear information and without confusing error messages

Important:

Network Threat Prevention is currently available in a Preview capacity to all Jamf Protect customers (not available to Jamf School customers). Management of the feature is performed in the Jamf Security RADAR portal, and not in the Jamf Protect web app.

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 (Optional)

  4. Creating an Activation Profile

  5. Deploying Network Threat Prevention to macOS Devices

  6. Testing and Validation

Network Threat Prevention Data Processing Notice

By enabling the Network Threat Prevention feature of Jamf Protect all customer data, including personal data, processed by using this feature will be transferred, processed and stored within Jamf infrastructure located in Ireland. If you choose not to enable the Network Threat Prevention feature, there will be no change to how your data is processed when using Jamf Protect.

General Requirements

  • Administrator access to your Jamf Pro or Microsoft Endpoint Manager 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 or Microsoft Endpoint Manager

Note:

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

Activating Your RADAR Account

A RADAR account is provisioned for you by Jamf after your organization joins the Preview for Jamf Protect Network Threat Prevention. An email is sent to you when complete.

  1. Click the Set a Password button 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.

  1. In RADAR, navigate to Policies > Security > Threat Response.
  2. On the screen that appears, click the Apply Smart Policy button 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 Save in the top-right corner of the page.

Configuring a Block Policy (Optional)

Create a block policy if you want to enforce category-based internet content filtering or custom block rules. If you do not need to do this, skip to the next step.

  1. In RADAR, navigate to Policies > Internet > Block Policy.
  2. Under the Default Rules tab, Jamf recommends clicking the Smart Policy button and selecting Block high risk.

    This applies the built-in policy to block known risky content.

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

Creating an Activation Profile

An Activation Profile defines the capabilities and configurations that devices adopt when enrolled into Network Threat Prevention.

  1. In RADAR, navigate to Devices > Deployment > Activation Profiles.
  2. Click Create Profile or Create Activation Profile.
  3. Provide a Name for your activation profile (e.g., Jamf Protect NTP).
  4. Leave Device Group set to Default Group.
  5. Click Next.
  6. On the Capabilities and Routing screen, select Data Policy and Threat Defense.
  7. Click Next.
  8. On the User Identification screen, ensure Without Identity Provider and User Random Identifier are selected.
  9. Click Next.
  10. On the Advanced Settings screen, Jamf recommends leaving all configurations set to their defaults, and clicking Next.
  11. On the Review screen, verify your configuration and then click Save and Create.
  12. Click Create Profile on the alert that appears.

Deploying Network Threat Prevention to macOS Devices

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 some Advanced Split-DNS Settings.

  1. On the Deployment tab for the Activation Profile you created in the previous step, select the UEM/MDM solution that you are using to manage your macOS devices.
  2. Under UEM Configuration Profiles, expand macOS Devices.
  3. Click the link for this configuration profile and save the file to your local computer.
  4. Follow the steps provided in the expanded section to complete your deployment.

    Depending on your UEM/MDM solution, the configuration profile deployment time may vary from a few seconds to up to an hour.

    About macOS UEM/MDM Support

    Jamf Pro and Microsoft Endpoint manager are 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.

The service should now be deployed and active on your target devices.

You can use your UEM/MDM solution to verify that the configuration profile was deployed successfully.

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 an endpoint with Network Threat Prevention deployed.  If your endpoint 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 you see an entry called "Jamf Protect NTP".
  5. Verify that the profile is active, as indicated by a green dot and the word "Running" beneath the title of the profile.
  6. Assuming 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.

  1. In RADAR, navigate to Devices > Manage.

    In the view that appears, you should see the devices you have deployed appear, likely 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.

    Observe 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 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 are editable via 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 upon 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 to result in 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 what DNS search domains and DNS name service addresses the network you are connecting to is configuring:

In Terminal, issue 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 required 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 being used or for situations where a device should only be able to resolve and connect to specific services when directly connected to the organizations local network (e.g., 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 (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 a few of these rules already configured, so the simplest solution is to simply 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 very unlikely event of a service outage. 

If you are not using Jamf Cloud, Jamf recommends adding the hostname (e.g., 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 Issues

App status column in RADAR

The app column is not applicable for Network Threat Prevention devices. As part of this Preview release, 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

During this Preview phase, Network Threat Prevention macOS devices are affected by the following block policy types at all times:

  • Platforms: Mobile

  • Traffic Interface: Domestic

Reporting

During this Preview phase, Network Threat Prevention macOS devices are shown under the current filters in the Reports section:

  • Platform: Mobile

  • Traffic Interface: Domestic

Captive Portal Networks

During this Preview phase, certain WiFi networks that require authentication to reach the Internet—such as coffee shops, airplane networks, and hotels—may not work while the service is enabled.

Workaround: Allow end users to disable the service in the Network preferences pane while logging into the captive network.

iCloud Private Relay

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

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: