One of the latest privacy features released with iOS 15, and available to paid iCloud subscribers, is
iCloud Private Relay.
This is a service designed by Apple to send your web traffic through two separate relays. It will hide your IP address, location, browsing history from your ISP, and the websites you visit.
This stops companies from tracking your data and creating targeted advertising based on your browsing habits. At present Private Relay is available in a handful of counties across the globe, with Apple expected to expand support to more regions in 2022.
For supported locations turning on Private Relay is as simple as heading into your iCloud settings and enabling the feature there. By default, your location is hidden from any sites you visit. For services that host geo-restricted content, e.g. Netflix, you’re able to select a country to spoof your location. This allows you to continue to use services that rely on your location, without sacrificing your new found privacy.
Private Relay functions like a VPN, when enabled your iPhone establishes an encrypted tunnel between itself and one of Apple’s Private Relay Servers. Any internet traffic from Safari is sent down this tunnel before being forwarded onto the destination webserver. All responses follow the same route back through your encrypted tunnel to your iPhone. As the tunnel is encrypted this stops your ISP, or the local network you’re connected to, from viewing the traffic. If your Organisation has a policy in place that requires all network traffic be audited, and hence prevents VPNs, Apple has released information on the DNS records you’ll need in place to block Private Relay. When blocked correctly, end users are presented with an error explaining Private Relay isn’t supported on the network they’re connected to.
To block Private Relay, configure your DNS server to return a negative result to the following hostnames
Avoid causing DNS resolution timeouts or silently dropping IP packets sent to the Private Relay server, as this can lead to delays on client devices. Jamf have also announced support for split routing using iCloud Private Relay. With the correct MDM configuration Profiles in place users will have their personal traffic sent over iCloud Private Relay, while corporate traffic is routed normally through the network and still auditable.
TeamViewer Quick App Support
When a TeamViewer remote session request is sent from Jamf the integration checks for the presence of the TeamViewer app on the target Mac. If the application is present the support request can utilise the existing client for remote access. If TeamViewer is not installed it will direct the user to download and open the TeamViewer QuickSupport app which is a lightweight version of TeamViewer designed for simple support sessions. The QuickSupport app doesn’t get installed onto the Mac, rather it runs as a portable app from the downloaded DMG. However, like the full client, it would still prompt the end user to allow certain requests such as Full Disk Access and Screen Recording.
With Apple’s requirements for PPPC Profiles to pre-approve requests such as Full Disk Access, or Accessibility, it was common to find IT admins choosing to deploy the full version of TeamViewer through Jamf. This allowed them to ensure the client app was available on their fleet of Macs, while also making it easier to deploy pre-existing PPPC profiles available on Jamf Nation. QuickSupport is a relatively new addition to the TeamViewer suite of apps, and uses different Bundle IDs compared to the full client, hence less articles/pre-configured profiles being available online.
Applications & Workflows
Our recommendation would be to explore TeamViewer QuickSupport as the application never gets installed and is removed as soon as the end user unmounts the downloaded DMG, logs out, or restarts their Mac. There is no shortage of stories in which end users are tricked into handing over remote support credentials to unauthorised users. If the full client is available on their Mac, this makes it easier for them to handover these credentials. With a request in the Self Service app, and the need to download the QuickSupport app every time they expect someone from IT to connect to their Mac, the end user is less likely to make this mistake.
With that, we would suggest the following workflows are considered: –
- Speak to your TeamViewer account manager and make sure you have the correct license in place to facilitate any security measures around conditional access. Why let any device in the world running TeamViewer access your corporate devices, when there is a feature to only permit a certain group of IT admin devices?
- Use the power of Jamf Pro with Extension Attributes and Smart Groups. If an IT admin needs to request remote access to a device, you could quickly have them change a dropdown box within the device record in Jamf Pro to permit remote access. This could do one of two things, firstly it could install TeamViewer on only the devices that require it, or secondly it could move the TeamViewer.app out from a restricted software policy so the user could then launch it.
- Provide the TeamViewer application in the Jamf Pro Self Service for a user to install if they require remote support. But add in a workflow that would then remove the application once support has completed. The best way we have found to achieve this is to add in a post install script to the TeamViewer install that removes the application after 1 hour.
There will be many more techniques used I am sure, but the main thing here is to consider whether the automatic deployment of a remote access tool to all of your users is best practice for your security needs. Should you require any assistance with Apple security workflows please click the contact us button below.