Apple services use a variety of ports and connections that may not be immediately accessible when used on a corporate network. Here’s how to access them on enterprise networks.
Security is a big issue when using devices to connect to Apple Services – especially for enterprise networks.
In enterprise, security is a top concern due to the fact that companies and organizations are constantly under external pressure from hackers, ransomware, denial of service (DoS), botnets, and other attacks.
Apple devices communicate with a variety of services on remote servers. Apple Push Notifications (APNs) are one such communication channel.
For example, if you see a Messages or FaceTime alert, you’re seeing an Apple Push Notification.
Unlike some other network services, APNs require a service on a server that then communicates with Apple’s APN servers.
Apple and third-party apps know how to send and receive APNs through these channels to communicate in real time.
UNIX, ports, and protocols
In UNIX and Linux operating systems, networking layers and apps communicate on ports and sockets.
Think of a socket as a networking pipe where data flows between computers. Different networking protocols can be used on sockets in UNIX, but TCP/IP or UDP is used for most internet messaging communications.
TCP/IP uses a send-acknowledgment network packet model, whereas the UDP protocol sends data without receiving acknowledgments. The acknowledgment, or “ack” in TCP/IP is what allows reliable communication – if the networking layer doesn’t receive an ack when it sends a packet, it waits a certain interval and then resends it.
In TCP, resends continue until an ack is received, or until application-layer software tells the socket to stop. This could be after a timeout, for example.
TCP’s design was part of the original US Dept. of Defense ARPANET project, a project tasked with creating a reliable military communications network capable of withstanding a nuclear war. As such, the TCP/IP protocol knows how to automatically reroute data should communications fail.
This design ensured military hardware could continue to communicate even without human operators.
UDP, on the other hand, doesn’t wait for acknowledgments – it broadcasts data in streams on certain ports but it doesn’t care if certain destinations receive the packets or not. Hence UDP is known as the “streaming protocol” since it essentially broadcasts a continuous stream of data on a certain port.
UDP listeners can simply listen in on the indicated port to receive the stream of data packets. Most internet video and music streaming services use UDP for broadcast.
Other types of protocols are used for other kinds of communication. For example, web traffic uses HTTP or HTTPS.
Web security is provided by TLS/SSL and other security laters. The “s” in HTTPS stands for the “S” in SSL (Secure Sockets Layer). SSL was renamed to TLS, or Transport Layer Security years ago.
Hence the HTTPS protocol is really HTTP using transport or socket security (encryption).
Each service or protocol uses a numbered port. Ports tell an operating system where to listen for incoming data.
For example, standard HTTP uses port 80. The now little-used FTP protocol uses port 22.
TCP and UDP are lower-level packet protocols whereas HTTP/HTTPS, FTP, and others are higher-level protocols.
Each “service” or type of data has a predefined port number so that network traffic doesn’t get mixed up on arrival.
It is possible to change default ports to custom port numbers. Using custom port numbers is a security measure because hackers often look for specific types of traffic on known ports.
If you change the port number for standard types of traffic, hackers won’t see that data on the standard port and therefore will have a more difficult time intercepting it.
When you run an app that uses network communication it typically creates a networking socket in code, on a certain port, and then begins transmitting and receiving network packets on that port. At the UNIX networking layer, incoming and outgoing traffic is routed to each networking socket at the app layer as data arrives or is sent.
Most UNIX networking “stacks” are written in the C programming language for speed – and because the first complete released UNIX sockets implementation – Berkeley Sockets Distribution or BSD was written in C. Most of Apple’s current operating systems are based on modified versions of BSD called XNU developed at Apple.
Technically, the data packets are further broken down into frames at the data link layer, then finally into bytes at the physical or “phy” layer before they are sent by the networking device. But for the most part, you don’t need to concern yourself with the data link or phy layers.
Frames are used because each physical networking technology (Ethernet, fiber, etc.) may use different frame types.
At the other end of the connection bytes and frames are reassembled into packets and are passed up to the networking layer, then finally to the application layer where their data is read and used.
Proxy servers
For many reasons, most organizations use proxy servers as part of their network topology. A proxy server is a server that either acts as a data forwarding server, or as part of a firewall for security reasons.
Proxy servers can be used to receive requests, then forward those requests to other servers – usually content servers. Proxy servers are also sometimes used in load balancing systems.
Proxy servers are usually (but not always) physically distributed away from content servers.
Load balancers act as buffers so that content servers don’t get overloaded or stop working due to high traffic loads. A typical organization network topology will include several proxy, content, and load-balancing servers.
Some companies (such as Barracuda, Citrix, Cisco, and others) specialize in selling load-balancing appliances that can be configured in racks or banks and then receive and reroute external traffic to content server destinations. Large companies often have entire rooms full of load balancers to distribute network loads across servers.
Content servers can further be distributed across one or more CDNs or Content Delivery Networks. CDNs are effectively distributed load balancers, ensuring that traffic is routed as efficiently as possible both geographically, and performance-wise.
Barracuda Load Balancer 340
Apple Services
Apple provides a number of networking services and to do so it operates many custom servers and CDNs to handle the network traffic. To do so it often uses standard or custom ports for its servers.
With billions of Apple devices now in use daily, the network load on Apple’s servers and services is tremendous, and to ensure everything continues to work smoothly, it must carefully design how its networking traffic is handled.
Apple also uses many domains for device management. Enterprise deployment of Apple devices can be too large to handle manually, and as such Apple provides MDM or Mobile Device Management – a term that now encompasses all Apple devices.
Apple doesn’t provide MDM servers or services directly – it only defines how they are to be configured and deployed – implementation is left to third parties to handle.
Some Apple service domains support proxies and captive portals, but some don’t.
A captive portal is a server or web page that provides authentication (sign-in) for various organization services. If you’ve ever gone to a Starbucks and had to sign in to its free WiFi you are using a captive portal.
For internal enterprise use, Apple’s MDM defines the concept of enrollment – which is essentially registering an Apple device on a specific organization’s network. Enrollment is used to determine which devices are known and recognized on organization networks and which aren’t.
Enrollment helps security and network administrators detect hostile devices on internal and Virtual Private Networks (VPNs).
Other services provided by Apple act in conjunction with MDM and enrollment to provide miscellaneous functions such as time/locale settings, updates, and device termination.
For example the domains time.apple.com and time-ios.apple.com are used to set the date/time and even language for enrolled devices across all time zones/locations on the globe using Network Time Protocol (NTP).
MDM services
If you’re enrolling or deploying devices on corporate networks using an MDM solution, you’ll need access to at least APNs, enrollment, external services, and software updates.
For APNs you’ll need access to *.push.apple.com on ports 80, 443, 2197, and 5223 – and your third-party APN server solutions or proxies must be able to communicate over TCP on these ports without restriction.
If access to these ports is unavailable, then your enrolled users may not receive real-time notifications such as Messages, FaceTime, web, or software updates. Keep in mind many organizations like to use automatic software updates as doing so vastly reduces the need to manually update software.
Without access to APN ports automatic software updates may not work.
If you are using Apple School Manager or Apple Business Manager which utilize Apple device profiles, then you’ll also need access to iprofiles.apple.com.
To ensure all your MDM services work correctly, speak with your MDM administrator(s) or MDM service providers to make sure all servers and software are configured correctly.
Global HTTP Proxy MDM payload
Some organizations only allow web traffic to enter or exit the organization through predefined proxy servers. This topology ensures all web traffic can be traced, monitored, or blocked via proxy server configuration.
For example, proxy servers can be configured to block all traffic on certain ports, or only allow traffic on specific ports, while denying all traffic on other ports. This reduces the attack surface and minimizes ways for hackers to break into a network.
Proxy servers can also be used to forward or restrict which traffic gets sent to other servers – sometimes for security reasons, observability, or content delivery.
In the case of APNs, third-party servers essentially act as proxy servers for Apple’s Push Notification service.
In the APN model, apps first send to or listen on their own APN servers, which then forward and receive notifications from Apple’s APN service.
For organizational HTTP traffic, if you’re using an MDM solution, you’ll need to be aware of Global HTTP Proxy MDM payload settings for MDM-controlled devices.
A Global HTTP Proxy MDM payload tells an Apple device how and where to send and receive HTTP data on a proxy server.
For devices with manual authentication (i.e. – user name and password), you’ll need to ensure proxy servers can receive Global HTTP Proxy MDM payloads. For devices with automatic login, you’ll need to be able to provide a PAC file for each server or port you need access to.
Each HTTP Proxy MDM payload contains info on name and ID, which operating systems are supported, enrollment types, and if duplicates are allowed.
There are hundreds of Apple domains supported in HTTP Proxy MDM payloads, and your devices must ensure they can provide the correct payload for the services needed.
For complete info on HTTP MDM payloads see the section “Review MDM payloads for Apple devices” in the Apple Platform Deployment guide on Apple’s site.
Apple’s iCloud.
CloudKit, App Store, and TestFlight
If you are a developer or software deployment administrator at an organization, you’ll also need to be aware of any software that uses Apple’s iCloud, CloudKit, or TestFlight apps.
CloudKit is Apple’s API for communicating with iCloud’s database services. If an app uses CloudKit to access remote databases hosted on Apple’s servers you’ll need to make sure those networking services and ports are configured correctly.
Most (but not all) of Apple’s CloudKit APIs communicate on port 443 – the standard https port.
Without port 443 access, software can’t send and receive HTTPS web data unless a custom port has been defined.
There are, in fact, over a dozen Apple-hosted CloudKit domains you’ll need to be aware of.
Apple’s app validation, receipts, and Notarization services and security also use port 443 so to ensure most App Store apps work, all your enterprise servers will need port 443 also.
App Store downloads use the ASN.1 (Abstract Syntax Notation One) security, and software from the App Store that doesn’t validate using ASN.1 won’t work on Apple devices. ASN.1 is a vast topic in and of itself, so we won’t get into its details here.
Suffice it to say when you download or deploy software from the App Store to an Apple device, an encryption handshake of sorts happens which uses ASN.1 to exchange and validate a receipt tied to each app.
Without this receipt validation App Store apps can’t run on iOS devices.
For Mac devices, Notarization works in a similar manner – with apps being Notarized by Apple also requiring a validation in order to run.
All of these security checks are performed over the internet so your enterprise networking must be configured to allow them to work.
Touch ID and Face ID also use TCP on port 443 at *.appattest.apple.com for validation.
Apple’s developer TestFlight beta distribution service for pre-release apps also uses port 443.
Other services and Firewalls
There are dozens of other Apple Services we didn’t mention here. These include but aren’t limited to:
Some corporate networks support firewalls that can allow or deny network traffic based only on the domain name. This configuration is easier for admins to manage, but it provides a less granular-level control over which servers a client can communicate with.
If your organization’s firewalls allow domain-level access and filtering, you can allow access to all Apple remote services. This is done by allowing all Apple subdomains to pass through the firewall using the *.apple.com wildcard domain.
This is because all Apple remote services use servers on domains that end in “apple.com”.
If your firewalls don’t allow domain-level filtering and only support IP-level configuration, you can allow all outbound connections to Apple servers at 17.0.0.0/8 because the entire 17.0.0.0/8 block is assigned to Apple.
This page lists most public-facing services, domains, which ports and protocols they use, and which devices and operating systems are supported on each.
Not all Apple devices are supported on all services.
Additional documentation
There are several other deployment and networking documents from Apple you’ll want to take a look at. These include:
If you’re a developer, you’ll also need to read the sections Registering your app with APNs and Sending notification requests to APNs in the User Notifications section of Apple’s developer documentation.
That document also has info on how to set up APN servers.
Enterprise networking as well as device management are complex topics. We’ve only covered a part of what you need to know to use Apple devices on enterprise networks.
We also didn’t touch here on profiles – files Apple devices use to verify and install software and provide network security.
In future articles we’ll discuss deployment and MDM in depth, as well as firewalls, protocols, and networking information in more detail.
This story originally appeared on Appleinsider
