The built in application firewall allows the following services to receive connections by default, even in stealth mode:
- /usr/libexec/configd - used for DHCP among other things
- /usr/sbin/mDNSResponder - used for DNS and MDNS (Bonjour)
- /usr/sbin/racoon - used for IPSec
- /usr/bin/nmblookup - used for NetBIOS name lookups
- System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconfig - no idea
You can edit the /Library/Preferences/com.apple.alf.plist file to change this.
You can greatly limit the amount of information leaked by your device, by disabling MDNS broadcasts as per the following link from Apple https://support.apple.com/kb/HT3789
In addition, the following built-in Apple services initiate connections to Apple services constantly:
- /System/Library/PrivateFrameworks/ApplePushService.framework/applepushserviced - Apple's push services
- /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Resources/storeagent - Something to do with the OSX app store
I then flipped open WireShark to have a look at what the Push Services were doing, especially as I had disabled all push services (you can check in it's configuration file /Library/Preferences/com.apple.applepushserviced.plist) and it was still initiating connections to Apple.
Two interesting facts appeared:
- The code appears to have been ported from iOS to OSX based on the IOS strings present in the machines certificate sent.
- Each Mac has a unique certificate ID (and hence unique machine ID) stored in the push services configuration file mentioned above, under the "CertificateName" key that is disclosed in the clear with each connection to Apple's push services, despite it using TLSv1.
The implication of the last point is that you should be able to uniquely identify a Mac on a network, and tie future communications to it.
Finally, each connection is to a new IP. My first thought was to use the CN of the certificate from the server, courier.push.apple.com, but that's a CNAME to a non-existent Akami A record. So, after scripting the service to be killed every 5 seconds, which causes it to restart and initiate a new connection, it appears that the push servers occupy the whole 17.232.95.0/24 range (lowest .51, highest .222). Thus, blocking it should be a case of fire-walling all outgoing TCP/443 connections to that range.