Paranoid InfoSec doesn't trust Apple at all

We are a fairly paranoid/restrictive Medical institution. Our security folks haven't had any qualms with whitelisting 17.0.0.0/8 or the requisite on premise Jamf servers. Is it possible an attack may come from an IP address owned by Apple ? Sure. Is it likely? Doubtful.

I'd argue (you probably have as well) Apple devices are less secure in an environment where you can't be assured APNS traffic can transit to and from a client or on premise Jamf server. :)

Would it be nice for Apple to provided a solution for closed networks to leverage and proxy APNS, yes. Is it going to happen, doubtful.

APNS has been vetted by the Defense Information Systems Agency, per IOS/macOS STIGs Apple Push Notification Service (APNS) is an encrypted and authenticated communication tool allowed for use in the DoD.

If it's trusted enough for the DoD it's good enough for our Security folks.

I would talk to a qualified firewall guy and not rely on my info here, but I've been told by Apple there is two ways to clear...either the 17.x.x.x/8 OR if you can clear by DNS (at least to make push notifications work...other services YMMV). Basically if you clear all traffic from gateway.push.apple.com; feedback.push.apple.com; gateway.sandbox.push.apple.com; and 1-courier.push.apple.com that is supposed to work. That being said, like everyone else on here we simply clear the 17.0.0.0/8

Two things that may help in your quest to get things narrowed down...this includes port numbers and tech details from Apple:

https://developer.apple.com/library/content/technotes/tn2265/_index.html

I would also consider Apple's port document: https://support.apple.com/en-us/HT202944

and consider downloading Two Canoes Push Diagnostics app on your Mac if you want to test as you are opening ports and addresses.

I feel your pain though...the InfoSec folks really hate clearing a whole slash-8, but I told them if not, I'll be bugging you about "we can't do this or that every single day." It seems that Apple is almost de facto requiring the slash-8 to be cleared.

On a final note, reading the post above about the DoD clearing Apple's push notification service is very telling...it might make our InfoSec guys grumble a bit less.

Are you suggesting your InfoSec folks haven't read the macOS STIGs :)

http://iase.disa.mil/stigs/os/mac/Pages/mac-os.aspx

It helped my InfoSec department to learn that the 17.0.0.0/8 block is not called out due to laziness on Apple's part. They don't just own a bunch of pieces of that block of IPs and want you to open the whole thing to make it simpler, they literally own all 16,777,214 addresses in that space.
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

You may already know that, but they may not.

I had given them that info too...they didn't like it but it's one of the things that ultimately allowed us to clear it.

I can sure say that someone at Apple back in 1992 made one of the smartest decisions ever to snag a whole slash-8. I doubt they could forsee the kind of heavy service utilization that Apple uses today in 2017, but it's worth thinking about for a second. They were among the first companies to reserve a block.

@bvrooman they definitely know the entire 17.0.0.0/8 IP range belongs to Apple. They don't care. They just see it as 16 million points of potential attack. Sometimes I wonder how we're able to use the Internet at all. Ironically, they don't seem to have a problem opening up the multitude of IP ranges Microsoft has. MS may not have been insightful enough to obtain an entire Class A network way back when, but they do have chunks of blocks here and there.

This is going to sound nuts. but is it really your issue? Yes it's your issue but, if your InfoSec says no then, just CYA and move on to your next task/issue.

When you manager, CITO or users want some great new feature, or even better when your InfoSec asks for some new OS feature blocked, point out that you can't accommodated those requests until InfoSec provides you with a modern Apple recommend environment.

It's no fun being the bad guy and make no mistake you and Apple are the bad guys from InfoSec point of view. Do you have the time, energy and political clout to try and change that point of view?

C

Unfortunately things such as the EmbeddedOS installation are critical for the basic functionality of the computers. VPP was actually a mandate from my superiors Blocking Apple prevents me from doing my job at all. And unfortunately the problem has been put squarely in MY hands to solve... as long as it doesn't involve "exposing us to 16 million IPs." When I say they're hostile toward Apple devices, i'm serious. The Windows engineers don't face half of the friction I get. "oh you need to open up a bunch of IPs and ports to Microsoft? ok sure thing. Done."

"The Windows engineers don't face half of the friction I get. "oh you need to open up a bunch of IPs and ports to Microsoft? ok sure thing. Done."

Sounds like your talking to wrong folks then.... to go to the C level, make your case and get backing, pull in HR if you have to let them know you feel like your security team is trying to intentionally trying to stall your work over petty misgivings they have about Apple. If you are being stalled, then the users are being stalled, if they are be stalled, then business is taking a hit. It all comes down to money.

I think we all can appreciate the predicament you are in (I know I've been there, still am lol), trying to solve a management problem with technology. But it boils down to if your organization is going to utilize Apple devices as part of your ongoing business it's not feasible to have nonfunctioning APNS. If your org wants to utilize VPP. It's not feasible to have nonfunctioning APNS. If your org wants to utilize configuration profiles for device security and management. it's not feasible to have nonfunctioning APNS. There are plenty of banks/hospitals/gov facilities that are ok with opening 17.0.0.0/8 to manage and secure their organizational devices. Unless your infosec team has some serious evidence to the contrary the DISA vetting and approving APNS for use on DoD networks was good enough for anyone round my org.

How does the security team like an (pure) cloud based MDM solution?

The jamf pro server(s) is (are) the (only) device needing the 17.0.0.0/8 address access isn't is? So moving them outside your network is a solution (but not my favorite for bandwith reasons)
The iOS clients ultimately need only port 443 and dns access to enroll and be managed by profiles, and port 8443 (default, but configurable) for jamf pro.

If that is more to their liking, I hope your infrastructure can cope with the bandwith for software management.

Personally I've always ratcheted that up as the cost of being an Apple guy ... professionally , I recall a quote from someone at jamf privately on the subject of ports ..." opening these ports and addresses is what it takes to properly support iOS....if we are not able to open these ports and addresses, then we have to decide as an organization whether we want to support iOS or not." I will attribute that to a random jamf at JNUC 2015.

I have to agree with several folks here. I'm sorry you're going through such hell to get this approved and working, but at this point, you need to make sure security is owning this problem, not you. They know full well there will be no way to manage your Macs/iOS devices effectively with them blocking any access to Apple's IP range for their services, and I can assure you they are betting on that. As you clearly stated they have a strong animosity toward Apple, and it's clear they are being obstinate on purpose. It's time to get upper management involved in this and explain that you have tried in vain to work with InfoSec and they are refusing to allow something that thousands of other organizations, including many government facilities, are OK with allowing. This is not acceptable and you are not able to do your job under these conditions.

I know these types well. They are likely the kind that used to happily laugh back in the 90s when Apple was bleeding red and would pray that Apple went out of business so they could be lazy and never have to deal with anything but one Operating System for the rest of their careers. They seem bitter that Apple came back and is now a major force in the industry, but it's time they grew up and accepted that their fantasy didn't come true. If companies like yours want to effectively manage their Apple devices, they need to give a bit and allow this range access to your network. It doesn't mean they have to start liking Apple. They can continue to be haters if they want, but they should not continue to be obstructionists. They aren't doing anything but hindering your Mac users, and you, from being productive. Make sure management is well aware of this and let them deal with it from a management perspective.

IBM has approved Macs and Linux for it's secure gov service providers. Obviously they don't know what they're doing. :P I'm dealing with the same mentality, but not from a security standpoint. Half my department says that macOS isn't an appropriate enterprise solution. However, I'm kicking SCCM's tail with JAMFPro management.

APNS is a client initiated protocol, stateful connection, and a 256 byte packet is all Apple sends back to the Mac, telling it to check in with JSS to get something. It's all initiated by the client. Hmm

@mm2270 had some good commentary on this in my opinion. I'm not happy personally that the will not drill down on IPs. I have MS admins that can show me a mile long list of Office 365 URLs to clear as purported evidence that other companies are okay with identifying their servers...they say "why can't Apple?".

I honestly don't have an answer, but much like everyone else saddled with this type of thing, I put it to our infrastructure guys somewhat bluntly...if we can't allow this then I can't effectively manage these devices. When I did, we had just expended some major money and PR for our iPad 1 to 1 program...and that kind of forced their hand.

I do feel for folks like @AVmcclint simply because not all infrastructure teams are alike. I like hearing @csm0004 notes that 'Jamf Pro is kicking SCCM's tail'.

We had a recent moment where our MS guys are asking why we are paying for Jamf Pro and not using inTune? We have Surface devices and our district can get inTune for next to zero. Turns out that inTune at the moment can't even support device-based app deployment on iPads or Apple educations payloads. (source cited here...link is to a support document from January 2017 and was current at time of this posting: [https://docs.microsoft.com/en-us/intune/deploy-use/manage-ios-apps-you-purchased-through-a-volume-purchase-program-with-microsoft-intune](link URL))

It turns out the our Microsoft guys aren't happy with inTune though either and are keeping SCCM. Luckily we survived that one.

Thank you to all for your input. The hurdles ahead of me are very high and I'm just a lowly Mac Engineer in a land where InfoSec reigns supreme. Any and everything that is done under the aegis of "Security" is unimpeachable. Thanks to a recent discovery https://www.jamf.com/jamf-nation/discussions/23472/freshly-imaged-mac-not-getting-any-profiles#responseChild142204 and the input here about the DoD not having a problem with APNS, I hope I now have the ammunition I need to make my case.

We actually don't use APNS, partly because we built up our Mac support processes and infrastructure before it was a thing, and partly because it doesn't offer us much. Our JSS is not exposed to the Internet and I'm happier that way, and in fact our InfoSec is moving towards a more secure and closed off network anyway with 2FA everywhere. They are also heavy Mac users though.

I can see how that might work on a Mac (awkwardly, but very possible) but with iOS devices, you don't have a choice but to use APNS.

Not every organisation will allow full unfettered access to *.apple.com . People forget there are still places that have very stringent security policies, usually for legal reasons that can't easily be bent or broken. Late last year I had the same issue, so I spent a lot of time trying various things like reverse DNS lookup of apple.com and eventually ended up doing various other nasty things so you don't have to.

http://www.richard-purves.com/2016/09/10/apple-services/

Hope that helps. It turns out for DEP, APNS and related services you don't need to whitelist all that much, but doing it as a DNS name vs an IP address is recommended.