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:
Activating your RADAR account
Configuring a security policy.
Configuring a block policy
Deploying network threat protection to macOS devices
Testing and validation
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
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.
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.
- In RADAR, navigate to .
- On the screen that appears, click Apply Smart Policy to apply suggested security default settings.
- Click Laptop under Filter by Platform.
- Review the pre-configured policies and modify to fit your organization's security requirements.
- 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.
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.
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.
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.
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.
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.
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:
Disable Network Threat Prevention if the DNS search domain issued to a device matches
*.customer.com
.Disable Network Threat Prevention if the DNS name server addresses issued to the device is
10.102.46.20
or10.102.46.30
.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>
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>
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
- 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:
Via MDM Restriction Profile (In Jamf Pro 10.38 and later)
Using a Block Policy