[MacTUG] Profile Manager and Firewalls

Thu Mar 14 19:10:43 EDT 2013

While I was only interested in blocking inbound connections to my server for the time being but I have now moved beyond that, solely in the name of SCIENCE ;-) I have been curious on what the impact of a firewall will have on the interaction between the Mac Client and the Mac Server. (Note that I am coming from the perspective of a firewall being a good thing)

To recap, I enabled a fairly locked down (for incoming connections) firewall on the Mac Server (courtesy of IceFloor) and things worked fine.

If I blocked outgoing connections outside of UW on the server, the changes to the client profile did not seem to make it from the server to the mac client. They would not even show up as 'active tasks' in the management window for profile manager.

Merely out of curiosity, I enabled the firewall on a client limiting incoming connections to within the Campus. Frankly from what I had read (and how the blocking of outgoing connections from the server caused probs) I expected problems. But the profile updates from the Server did make it to the client. Weird, I hate when things work ;-)

Mike, I know that you are right in that APNs started on iOS devices, but I am pretty sure that they are powering Profile Manager's notices it sends out to the clients. Clearly it looks like the Server needs to talk out to the world regarding changes to the profiles. I am wondering if the clients are not really being 'pushed' these APNs but are polling for them every now and then (and it looks like they are pushed), and I would guess that if they are initiating the discussion, then the server could respond back on those ports, even if there are some blocks on incoming activity.

I wonder, but as I am taking tomorrow off, I will try not to wonder too hard until next week ;-)

------------------------------------
Donald Duff-McCracken
Technical Services Manager
Mapping, Analysis & Design
Faculty of Environment
University of Waterloo
(519) 888-4567 x32151
https://uwaterloo.ca/environment-computing/about/people/donald-duff-mccracken

------------
To request help from MAD please use Request Tracker. For info see:
https://rt.uwaterloo.ca/~wwwrt/cgi-bin/rtuser.pl

------------
This email communication is intended as a private communication for the sole use of the primary addressee and those individuals listed for copies in the original message. The information contained in this email is private and confidential and If you are not an intended recipient you are hereby notified that copying, forwarding or other dissemination or distribution of this communication by any means is prohibited.  If you are not specifically authorized to receive this email and if you believe that you received it in error please notify the original sender immediately.

On 2013-03-14 12:16 PM, "Mike Patterson" <mike.patterson at uwaterloo.ca<mailto:mike.patterson at uwaterloo.ca>> wrote:

I talked with Bruce Campbell a bit shortly after I sent my note to you this morning, Don, and we agree that if Apple actually does require MacOS clients of a 10.8 server to be available on public networks and to allow 17.0.0.0/8 access to them, that's an amazingly hostile move on Apple's part. For one, that would mean that if Waterloo's network was like most corporate networks, and was almost all private IP addresses internally with NAT for external access - like wireless is already, say - you couldn't use Macs in a managed environment.

That doesn't seem right at all.

Reading:
http://support.apple.com/kb/TS4264?viewlocale=en_US

It seems that they're only talking about iOS devices, so that shouldn't make a difference in your environment. And I believe they're talking about allowing those ports outbound, not inbound, although it's not particularly clear on some of the rules they suggest.

http://support.apple.com/kb/HT5302
seems to suggest you need the same ports for your lab, but I wonder if what they're talking about is your clients need to be able to talk to your server on those ports?

That's the only way it makes sense - surely Apple can't be telling people "oh, you've got a NAT? tough, can't run our software then."

Mike

--
Nothing is more dangerous than an idea when it is the only one
you have.  - √âmile Chartier

On 2013-03-14, at 12:05 PM, Donald Duff-McCracken <dsmccrac at uwaterloo.ca<mailto:dsmccrac at uwaterloo.ca>> wrote:

So I have been thinking a bit about the implication that firewalls will have on mac management.
A Mike P, as you are no doubt reading, I think it is a good thing that we are finally getting a campus firewall, I just want to make sure any critical ports are available. :-)
A campus firewall will have much more of an implication than it would have a few years ago when we were using the Golden-Triangle and all the issues of authenticating  a lab or office Macintosh were happening within the UW network. As that point, we could have ran a Mac system authenticating with AD/OD and not have any outside contact. This has changed a bit with Profile Manager and Apple Push Notifications (APN). APN is the real issue. At any rate, this is what I have determined and we should have mull this over and I would certainly appreciate it I am wrong on any of my thoughts about this…
Briefly (as I understand it as I have only been playing with Mountain Lion Server for a bit over month), the server and the clients are subscribed to apple push notification service and this is the way that the clients understand that there are any changes made to their 'profile' (client settings, what membership the device is in, etc). These ports need to be open and talk to apple which is 17.0.0.0/8
I found these pages to be informative...
PORTS USED BY PROFILE MANAGER http://support.apple.com/kb/HT5302
UNABLE TO USE APPLE PUSH NOTIFICATIONS:
http://support.apple.com/kb/TS4264?viewlocale=en_US
Consequently, while I am currently letting the lab subnet have access any ports on my server*, I am limiting the rest of the world to 17.0.0.0/8 (which is Apple) having access to 1640 2195 2196 5223 on tcp. The rest of the world gets zilch. (Mike, in a previous conversation I had those ports open on UDP too but they do not appear to be needed to be open). The APN doc says that port may need 443 to be open in certain situations, but how could it not — similarly, within the campus we need the client macs to talk to the server on ports 80 and 443, but these are likely not an issue ;-)
To break down these ports:
  *   1640 is a tcp port used for enrollment access to the Certificate Authority
  *   2165 and 2196 are TCP ports used by Profile Manager to send push notifications
  *   5223 is a tcp port used to maintain a persistent connection to APNs and receive push notifications
  *   443 is a tcp port used as a fallback on Wi-fi only, when devices are unable to communicate to APNs on port 5223
So this is all something we should chew over :-)
*I will lock this down later, but as I am going from a no-firewall state of letting the world have access to the server, to just letting one subnet have access, I am feeling this is a good first step. I have clear ideas which ports they need when I start locking it down more, I just do not want to do it yet as this is my first deploy of 10.8 and use of Profile Manager, so I want to take the firewall deployment in baby steps.
-------------------------
Donald Duff-McCracken
Technical Services Manager
Mapping, Analysis & Design
Faculty of Environment
University of Waterloo
(519) 888-4567 x32151
https://uwaterloo.ca/environment-computing/about/people/donald-duff-mccracken
------------
To request help from MAD please use Request Tracker. For info see:
https://rt.uwaterloo.ca/~wwwrt/cgi-bin/rtuser.pl
------------
This email communication is intended as a private communication for the sole use of the primary addressee and those individuals listed for copies in the original message. The information contained in this email is private and confidential and If you are not an intended recipient you are hereby notified that copying, forwarding or other dissemination or distribution of this communication by any means is prohibited.  If you are not specifically authorized to receive this email and if you believe that you received it in error please notify the original sender immediately.
_______________________________________________
MacTUG mailing list
MacTUG at lists.uwaterloo.ca<mailto:MacTUG at lists.uwaterloo.ca>
https://lists.uwaterloo.ca/mailman/listinfo/mactug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uwaterloo.ca/pipermail/mactug/attachments/20130314/df18009c/attachment-0001.html>