Apple Enterprise and the 17.0.0.0/8 disclosure

[gpalau]

https://www.jamf.com/jamf-nation/discussions/23477/paranoid-infosec-doesn-t-trust-apple-at-all#respo...

Aside from the information provided by @franton that is unofficial, but easily reproducible and is really great and much thanks to him for doing all that hard work and sharing it. Does Apple provide an official white paper, support document, business.development document, etc. Where they present officially, what are the servers that live behind *.apple.com and/or at least document saying officially in order for APNS or DEP or whatever to work, the following addresses are critical.

It has been well documented that some businesses are ok with flipping the switch and allowing all 16,777,214 addresses in that space free reign from/to their networks, but there are also other places which due to federal compliance, regulation or good l'fashioned security, need a document stamped by Apple and deemed as official, that reproduces a portion of that spectrum or at least the parts relevant to each of the services.

It would server really well if they just grabbed @franton 's list and put the Apple Logo on it and made it official... I think a lot more businesses that use Apple would be more open to opening this ports...

It's been a couple of years now that Apple wants to publish how much they want to get in the Enterprise and how its leveraging this and that to make the Enterprise much happier with Apple, but its lack of attention to detail like this that makes Enterprise not really happy with them. Apple has not really stepped up and provided the much needed enterprise level documentation about what is available within that spectrum and Apple Engineers, Managers, and other higher level management don’t seem know if even such documentation exists or is available somewhere.

We shouldn’t have to guess on what their technologies contain, how do they exactly work from a security perspective. I wish someone from Apple read this and made some true effort in either making this documentation appear or provided it for everyone else that needs it.

[hjcao]

Try this - https://support.apple.com/en-us/HT203609

Since Apple owns the entire range, and use load balancing, their services can skip around the range daily. That's why they only as you to open certain ports. It's also a security precaution because if Apple published what ranges, for example, APNS lived on, they'd be much more open to attacks trying to down the service.

[cbrewer]

Here you go...

https://support.apple.com/en-us/HT201999

[sdagley]

Get started using Apple Business Manager or Apple School Manager with Mobile Device Management is one you'll need to pay attention to for Device Enrollment

[gpalau]

@cbrewer Thanks for pointing that out, but not remotely close to what I am looking for... If you check the excellent https://www.richard-purves.com/2017/07/21/apple-17-0-0-08-services-redux/, its what im referring to.

[CantScript]

I also believe that Apple have now out grown the 17.0.0.0/8 range, so even if you were happy opening up the entire range of IPs it’s likely to not cover everything you’ll need.

We first noticed this with DEP enrolments. If you’ve used the ‘services test’ iOS app it gives you a small list of servers that are used, rather than just *.apple.com but I can’t imagine that’s anything like all that going on.

The best thing I can suggest, if you want an extensive list, is to plug an iOS device into AC2 with the console window open and active a device. The console should show you all the URLs it hits during enrolment and setup

[sdagley]

@gpalau You really can't rely solely on @franton's Apple 17.0.0.0/8 Services Redux article. Note the comment he added to the top of the original Apple 17.0.0.0/8 Services article last year:

3rd September 2018: I keep this blog post as a historical document. Over the last two years it’s become more and more apparent that the “whack-a-mole” approach is more work than it’s worth. There’s a variety of new Apple URL’s appearing all the time and the maintenance work simply isn’t worth it. My recommendation is to allow *.apple.com URL free passage to/from your network on 80 and 443. In particular it has to be the URL and I’ve other posts that explain why.

It'd be nice if that were actually possible, but it's definitely not an option for some, so keep asking Apple to make the information on the server addresses and roles less opaque. Who knows, one of these days they might listen. The fact that HT207516 and HT201999 exist are small steps in the right direction.

[bradtchapman]

Hey y’all, not to toot my own horn but I covered this in depth during my presentation at JNUC 2017:

https://www.jamf.com/resources/videos/a-push-odyssey-journey-to-the-center-of-apns/

It is an outbound connection to Apple on 443 and 5223 for managed devices, and 443+2195-2196 for Jamf Pro servers.

You do not need to create an inbound rule from Apple into your network; however, this doesn’t mean that you treat APNS like a “drop box” where packets go and never return. What it means is that devices will open a connection to APNS and expect to keep it open. You do not need to accept unsolicited connections from Apple because it will never make them.

Apple devices will make every effort to keep the socket connection open to APNS. Don’t shut it down prematurely. They need to be connected to listen for push notifications.

[franton]

What @bradtchapman said. It's an unmanageable problem that comes from a Windows centric perimeter security way of thinking that is slowly going the way of the dodo.

I was engaged at a financial institution trying to maintain this. Lots of people contributed various items and it was getting to the point where it was distracting from my main tasks. Add to that the convoluted multi-month change process in high security environments like financial and maintaining a list like mine becomes a full time job in itself and you'll never be current with it . Ever.

That's why @sdagley correctly points out my addition as to why I retired the list. Sure it was handy, but it was mutating all the time. And then comes my discovery (from Brad's APNS talk) that Apple's download CDN's don't even reside in 17/8 !. https://www.richard-purves.com/2017/11/17/apple-now-it-hurts-when-ip-address/

On a different note, I'm never going for a punny title like that again :)

So yeah, you can't rely on just opening 17/8 and expecting to hit everything as stuff for downloads exist outside of it. It has to be *.apple.com on 80 and increasingly 443, HTTP HTTPS and HTTP/2 protocols.

[franton]

Oh and hey @bradtchapman ... APNS is coming under changes too. See https://www.richard-purves.com/2018/06/26/2018-apns-changes/. I even have a feature request on this too at https://www.jamf.com/jamf-nation/feature-requests/7612/apns-api-change