Opening ports on Firewall to JSS - Network Security balking. Help!

Is your DMZ cluster node set to be a 'computer and mobile device access' node? If not, try that first.
Has JAMF confirmed with you that DEP enrollment with a cluster node should not work, either by design or as a defect?

I know the concept of opening up a FW to an entire range sounds pretty daunting to a security group, but this seriously is done everywhere these days. this is part of how Apple devices talk back to the mothership, and any device is going to do this the second you are outside the FW, so, where is the issue?

Only ports that need to be open for APNS items are the first 3, 443 has nothing to do with APNS.

Hey Mark,
Apple's white paper says it needs to be open as a fallback on WiFi only, when devices are unable to communicate to APNs over 5223.

John, yes it was.

Yes, JAMF confirmed.

At my site, we don't have 443 open just to APNS, but the idea is you don't need 443 if you have 5223 open. 5223 is outbound anyways, the device is initiating the contact, not APNS inbound. Its all really outbound, even from the JSS. the talkback inbound traffic is really over the same connection.

I'm never a fan of the "Fortress" approach to security, its a fairly lazy approach to security….InfoSec teams tend to build these walls up, and can claim they are safe because nothing is open… but then nothing gets done either..

If they are smart, they will allow point to point holes in their FW, or use the secure methods that can be used for further hardening.

the ports being open allows you to lock and wipe a lost or missing device, which alone is worth the risk. It allows you to send device profiles, which can be used to set network access and other items that would require some measure of Security intervention ( PKI certificates for wifi would be one application)

Usually when it comes to APNS, if one JSS sees it, all will, so i'm not sure why your external needs to be the master JSS.

Port 443 is needed for OSX clients to receive their a token from Apple.

Else, you'll get the MDM profile on them & nothing else.

RE:"Usually when it comes to APNS, if one JSS sees it, all will,"
That is not what I have seen. If my DMZ host is the master, this all works perfectly. If my internal host is the master, with the DMZ host running in limited access mode, it fails.

JAMF support has spent many hours trying to make this work. It simply won't without this ports open.

BTW, JAMF support. It. doesn't. get. any. better.

@Kevin ,

Sometimes, when I get pushback from security teams while working on a case, I like to give them Apple’s “aimed at developers” documentation along with the more general customer facing documentation.

Oddly, it seems network security people like the tech-ier sounding document than the, “Hi, please open these up, okay thanks! :)” style public, and easy to find KBs.

http://support.apple.com/kb/TS4264 would be the ‘friendlier’ version.

https://developer.apple.com/library/ios/technotes/tn2265/_index.html is the version I usually refer to as the Admin Version. It’s linked from the bottom of the first KB article. It's actually the version I prefer as well, as it goes more into the 'why' as opposed to just saying, "Do this, it's required."

I use the second one frequently when trying to explain why we need to whitelist things on a proxy to allow APNs related traffic to bypass it completely for this one tiny blurb:
“As is documented in the Local and Push Notification Programming Guide, developers are expected to open a connection and leave it open. If a connection is opened and closed repeatedly, APNs will treat it as a denial of service attack and block connections for a period of time.

This temporary block will expire if no connection attempts are made for about one hour.”

That can and does happen, and it’s frustrating when it does as you’ll see APNs related things work for awhile, then it stops for an hour or two, then suddenly starts up again and the log files typically indicate that 2195 is being blocked when it’s in a not-working phase. In a lot of cases, unless you have a network security team that’s opening and closing that port just to mess with someone, the cause is Apple cutting traffic off temporarily due to the constant opening and closing of connections from the environment’s proxy.

That second document elaborates a bit, in terms of why the ports are required to be open, on the first one with, “Push providers, iOS devices, and Mac computers are often behind firewalls. To send notifications, you will need to allow inbound and outbound TCP packets over port 2195. To reach the feedback service, you will need to allow inbound and outbound TCP packets over port 2196. Devices and computers connecting to the push service over Wi-Fi will need to allow inbound and outbound TCP packets over port 5223.

The IP address range for the push service is subject to change; the expectation is that providers will connect by hostname rather than IP address. The push service uses a load balancing scheme that yields a different IP address for the same hostname. However, the entire 17.0.0.0/8 address block is assigned to Apple, so you can specify that range in your firewall rules.”

I’ve run into it, more than once, that security teams think that JAMF is requesting the ports/addresses be opened or whitelisted as opposed to it being an Apple requirement for their APNs services, and clearing that up in a way that shows them, 110% that these requests are Apple requirements and not JAMF requirements, it can help quite a bit as well.

Amanda Wulff
JAMF Software Support

Thank you Amanda. I have a meeting today with my security team to discuss this. This tech note will help.

Circling back around on this…

My security team agrees that they can do something to accommodate my request. They agree to NAT, then proxy the ports I need to my internal JSS. The problem is, it won't work when proxied. The APNs traffic has to go straight to the JSS.

So the dilemma is…
The traffic has to go straight to the internal JSS without proxy.
My security team won't direct it there without proxy until Hell freezes over.

My options:
Forget iOS device management.
Move my master JSS to the DMZ.
Get Hell to freeze over.

Moving my master JSS to the DMZ makes everything work fine. The issue then becomes security. The JSS clients communicate over port 8443. Web administration takes place over port 8443. Essentially, anyone with a password could log in. Password strength is determined by our AD policy. Most AD users do not have 20 character complex passwords. We have to be in PCI compliance, so exposing a web login to the internet would be a violation.

I know many of you work at companies that must pass PCI, HIPPA and other security audits. How are you guys making this work?

Hi @Kevin

I totally understand your situation. Having had the personal opportunity to work with a lot of Info Sec people I have learned a lot on how they think and operate with security.

The ports open to APNS only need to be outgoing and persistent. You can also, in your firewall rules, only allow the JSS to communicate to APNS, outgoing. You don't need to open up anything incoming, because APNS should make a persistent outgoing connection. As already mentioned, this is an Apple requirement. Every iOS device by default already phones home via MDM to these addresses. The reason why you open the whole subnet range is that DNS can change, or Apple could add a bunch of clustered APNS servers behind a NAT'd IP pool or something, and then your firewall won't update it's DNS settings in sync with Apple's.

You also don't have put a web app in the DMZ per se. You can put proxies in place that route traffic with ACLs to your JSS in your data center. I know some orgs will never allow a web app with database credentials in an XML file in the DMZ. So, you can extend your infrastructure out into the borderzone by simply adding a load balancer externally, and tossing some Apache proxies behind it, and then route all traffic to your internal web apps (and a different load balancer) and you can get around the DMZ security issues that way.

I work with some large enterprises and this is typically how they accomplish what you are trying to accomplish. If you put the JSS into debug mode and watch it shoot out APNS commands to devices you can see it is pretty limited into what it can do. Furthermore, you gain a ton of security features by doing this. With the JSS able to communicate to devices off premise, you get the ability for compliance reporting, and taking action on devices out of compliance for both iOS and OS X. You also gain a remote lock and remote wipe feature with the MDM commands. The data is the most important thing, correct? That is what we are securing here. If someone were to steal one of your org's Macbook Pros, that could have sensitive data on it, the next time it comes on line you can have it locked or wiped.

So the compliance reporting and the extra security features should be selling points to security teams. Unfortunately APNS will not work through a proxy, but all other client traffic will.

Hope this helps,
Tom

@tlarkin

First, thank you.

By default, we have everything opened up outgoing. According to JAMF and Apple's documentation, 2195, 2196, and 5223 need to be open inbound, as does 443.

Background: We have had a clustered JSS environment for couple of years, working fine for inventory and package delivery. We discovered a problem when we tried to use DEP and discovered that we could not get Prestage enrollment to work. The culprit turned out to be that our certificate was being generated on our internal JSS (the master) and the communication from APNS was coming back in through the DMZ host. Obviously, not the same device, so we get certificate mismatch errors and prestige enrollments fail. If I move the master JSS to the DMZ host, and generate the certs and token there, it works, but then we have the security issue of having the web interface exposed externally.

So the issue is… how to have communication to the master JSS and not open a security hole.

JAMF has been heavily involved in troubleshooting this issue (and been great btw) and they were insistent that these ports had to be open inbound…

If this is supposed to work with only outgoing traffic on these ports, I must have another issue…

Hey @Kevin

My colleague verified, that outbound persistent connections are all that is needed. If you don't allow for persistent (sticky) connections, then you would have to allow inbound connections, but even then I think if a new connection is created inbound it would not work, because that connection would not match the auth token for that MDM command.

The documentation is a bit off and vague. I have talked with my co-worker about fixing it. You can check by trying to telnet outbound to the APNS services.

Thanks,
Tom