Protected Rules & All Those System Processes

General discussions about Little Snitch
Posts: 4
Joined: Thu Dec 01, 2016 2:19 am

Protected Rules & All Those System Processes

Postby droltama » Thu Dec 01, 2016 3:59 am

Ever wonder what all those system processes are doing? So did I...

I recently picked up Little Snitch and I've had a fun time watching all the traffic that one little MacBook can send! I wasn't satisfied to just filter my user-level programs -- why should I trust a system process when it could be hijacked just like any user process? (For example, see this mDNSResponder vulnerability from June of this year that allows for arbitrary code execution. Yikes!)

So, I decided I would actually bother to investigate what all those different system-owned processes and daemons did. I've had some adventures selectively enabling and disabling services with launchctl, running processes through dtruss, Wireshark, and other tracing tools, and occasionally breaking my computer along the way.

Here's what I've found on some of the processes you might have noticed if you ever disabled the protected rules:

AirPlayXPCHelper - Background on XPCs: An XPC is user-level service (like a daemon) that runs in the background and helps apps accomplish some goal. Apple recommends using XPCs for fault-tolerance: if you have some component in your application that is likely to crash, throw it in an XPC so that even if it crashes, the main user-facing program won't, and can simply restart the XPC service. (Aside: this seems like Apple is saying "got buggy code? Don't fix it, just throw it in an XPC!" which sounds pretty awful but whatever, that's not what we're here for). Furthermore, every individual XPC service is sandboxed so it can't affect other processes.

AirPlayXPCHelper obviously helps with AirPlay. However, my AirPlayXPCHelper tried to connect to something on port 7000. Since port 7000 isn't listed as an AirPlay port on Apple's list of ports used by Apple products, I blocked it. Haven't had any issues so far.

AppleIDAuthAgent - As the note on the protected rule states, "AppleIDAuthAgent is used to check whether Apple-ID certificates are valid." I recommend letting this one connect to Apple (and Apple only) at least periodically to keep the system happy. I've blocked it at times, and the OS seems to accept not being able to verify the user's identity sometimes.

apsd - From the protected rule notes: "Part of Apple’s PushService framework." Turn it on when you want push notifications from Apple, block it otherwise. Note that apsd is responsible for sending and receiving iMessages and texts in Messages, so if you use that then you'll want to allow it access to the domain.

assistantd - This is Siri, and other voice control stuff. I blocked it unconditionally since I don't use the feature, and I'd rather my MacBook not be always listening to everything. You can use launchctl to disable the service permanently if you want; you can find it at /System/Library/LaunchAgents/

automount - This tool mounts drives of all kinds, including network drives. If you don't need to mount network drives, you're good to block this one. (But don't disable it in your OS! Otherwise all kinds of stuff may not mount properly)

cloudd - A daemon related to iCloud. I allowed it to connect specifically to iCloud servers while on my home network, and blocked it elsewhere. Depends how accessible you need your iCloud to be. (Never use iCloud? block away!) - Another XPC, this one's name can be read "Geo-D", short for "geolocation daemon". If you're paranoid about being tracked by The Man, block this one unconditionally. I let it connect to Apple, because I suspect it's used by Find My Mac, and I'm more worried about my laptop being stolen than my location being tracked by the fed.

configd - This one controls a host of mostly network-related tasks, but also some other stuff. Use "man configd" in the terminal to take a look at its manual. If you block it, you won't be able to connect to WiFi hotspots, or at least not always or very well. So we have to allow some traffic, but we can restrict it pretty hard: on most networks, it's sufficient to only allow incoming UDP on ports 67 and 68, and outgoing UDP on the local network.

findmydeviced - As with, this one comes down to whether you'd prefer to find your stolen property, or not let Apple and other APTs know your location.

gamed - This is the daemon for the Games Center. If you never use the Games Center (I don't), then you can not only block this one, but also disable it using launchctl. When blocked, it retries every second, which can be annoying, so disabling it is a nice fix.

helpd - This daemon fetches content provided through the "Help" drop-down menu of most applications. It will try to connect mostly to Apple, but also occasionally to help resources on other domains (e.g. SourceForge) for non-Apple applications. If you never use "Help", you can probably block this one entirely. I let it connect to Apple and no-one else.

ksfetch - This is an updater daemon for Google products, notably Chrome. There's also a Google Software Update app installed within Google, so I'm not sure why Google needs an updater app AND an updater daemon. I have it blocked currently, but maybe I shouldn't.

launchd - This is a service dispatcher (like inetd on Linux) that launches other services. It is sufficient to only allow incoming connections; launchd just listens and launches other daemons to hand off the incoming data to. I don't recommend turning it entirely off, since it will break some stuff, but (in my experience) you can limit it to the local network without issue, unless you're running a webserver or something.

mDNSResponder - This one's been a big headache for me. It originally only did Bonjour (Apple's "zeroconf networking" solution, allowing devices to find each other automatically on the local network), but as of MacOS 10.6 it took on a bunch of regular DNS tasks as well. I discovered this when I disabled it entirely and found that it broke a bunch of stuff. I'm still working on a good profile for it, but for now I have it very selectively filtered: it can access a few DNS servers I trust on port 53 (DNS), and port 5353 (the Bonjour/mDNS port) only on my local network. It's otherwise blocked off, and this seems to work alright for now. Your mileage may vary. If you have a decent filter for mDNSResponder, I'd love to hear about it.

mount_nfs and mount_url - Just like automount, if you don't have any network drives to access, you can safely block these entirely. Note that these two can mount internet filesystems in addition to local ones.

netbiosd - NetBIOS is a super-old local network drive-sharing protocol. If you don't have any network drives on your local network to access, you can block this one too.

nsurlsessiond - I'm guessing that the "ns" at the beginning of this one's name refers to "NeXtStep" and not "namespace", which indicates to me that this is probably pretty old tech. I don't know all the things it's used for, but it is used at least to sync data from iCloud. Others are finding it's also responsible for leaking your data to Apple and Microsoft in the built-in Spotlight and Bing searches (if you haven't already, turn off Spotlight Suggestions and Bing Search from the Spotlight settings so that your keystrokes aren't all sent over the wire whenever you search for a local file). I've got it locked down to only call out to iCloud servers, and that seems to work well.

ntpd and sntp - These little daemons keep your system clock in sync with Apple's clocks. I'm not sure why the OS needs two of them (looking into this is on my to-do list). Blocking them does little harm, but I suggest instead just locking them down to only be able to connect to Apple's servers.

ocspd - This daemon is used by the system to check X.509 certs. I've got it blocked when I'm outside of my own home for now, and that doesn't seem to be a problem. I assume it might be a problem if I try to install any new software while it's blocked.

storeaccountd and storeassetd - So far I've only ever seen these two call out to iTunes-related domains. I assume they do "what it says on the tin," grabbing resources for the Store. I've got them blocked everywhere, and I disable the rule when I need to use the Apple Store or iTunes Store. Streaming music in iTunes through Apple Music doesn't seem to be affected by them being blocked, so I'm guessing it's only for actual Store stuff.

syncdefaultsd - Yet another iCloud-related thing, this guy keeps various preferences sync'd between Apple devices and such. You can probably block it, at least outside of your home network.

trustd - Like ocspd, this one verifies certificates. I haven't seen much traffic from it, and I have it blocked everywhere that isn't my own home, which seems to work fine.


I hope this information is helpful to someone out there. Stay safe, and good luck setting up your own profiles!

Posts: 16
Joined: Thu Oct 02, 2008 5:34 pm

Re: Protected Rules & All Those System Processes

Postby brian163 » Tue Dec 06, 2016 4:59 am

Thanks for this nice write up. I had to chuckle to myself as a lot of these daemons crop up in various online forums where folks are complaining about high CPU utilization or other perceived issue. You could probably share this on Apple's and a dozen other vendor forums to some benefit. :D

One tip regarding apsd. LS has a Protected Rule to permit outbound connections to domain But it appears Apple frequently adds hosts to this pool that don't always resolve (I suspect at least "initially"). So if you grow tired of approving random outbound connections for this process as I did, you can add a rule to expand on the scope of the Protected Rule to include all of the IP's in Apple's IP address space (all 16.8 million of 'em :shock: ). (Source: https: //

i.e. "apsd - Allow outgoing TCP connections to port 5223 of" (which you can enter as while creating the rule)

The risk associated with doing so is arguably very low. Your only allowing apsd to make outbound connections to a known registered address space on a specific service port.

Posts: 6
Joined: Wed Nov 19, 2014 12:59 pm

Re: Protected Rules & All Those System Processes

Postby theophilus » Tue Dec 06, 2016 1:28 pm

Thanks for this! Can you pls. indicate additionally which OS X u are using?

Posts: 9
Joined: Sat Nov 19, 2016 12:15 am

Re: Protected Rules & All Those System Processes

Postby maelcum » Wed Dec 14, 2016 7:54 pm


Thanks for going all the way explaining and documenting what you've found! This is just so great!
I've been looking for something like this for so long.

Posts: 3
Joined: Tue Jan 26, 2016 12:29 am

Re: Protected Rules & All Those System Processes

Postby Tunes » Mon Jan 16, 2017 11:46 pm


Shall we refer to this as "The Document Apple Should Have Had In Their Knowledge Base?"

Now my question is about devices that are using AirPlay because I am getting this quite a bit and it's new on my El Capitan machine. Does Time Machine use it by chance?

It keeps asking to connect to: so I assume that to mean any device with a third octet containing any number from 1 through 255 in "192.168" that has a fouth octet of ".8". (Typing that racked my brain).

In the past I didn't worry about any of this stuff but these days with so many exploits appearing based on attacks of "Internet Of Things" I know there's a need to be more watchful. I just got a security camera and instead of using the docs that came with it, I searched online for them so I didn't have to open the shrinkwrapped CD and load it. In the search results, there were litterally hundreds of citations to an exploit and updating the firmware to avoid it. Yikes! Firmware updated immediately.

Posts: 3
Joined: Sun Jan 29, 2017 6:18 pm

Re: Protected Rules & All Those System Processes

Postby Kenneth » Thu Feb 02, 2017 1:20 am

Thanks droltama! Obdev should include this with the Little Snitch download.

Posts: 10
Joined: Fri Mar 10, 2017 6:49 pm

Re: Protected Rules & All Those System Processes

Postby sova214 » Fri Mar 10, 2017 6:57 pm

Excellent post. Thank you very much!!

Posts: 1
Joined: Tue Mar 14, 2017 7:00 am

Re: Protected Rules & All Those System Processes

Postby tnizz » Tue Mar 14, 2017 7:06 am

Little snitch popped up with something pretty concerning for me for storeaccountd... I saved the info here:

Code: Select all

wants to connect to on TCP port 80 (http)

   IP Address
   Reverse DNS Name
   Established by   /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Resources/storeaccountd
   Process ID   559
   User   asdf123 (UID: 501)

For me to have a system process like this try to ping some Chinese server is freaky! There is absolutely no reason this URL should be on my system. Is this process compromised on my system??

Return to “Little Snitch General”

Who is online

Users browsing this forum: Baidu [Spider] and 2 guests