Well, as it turns out it was indeed Little Snitch’s handy “automatically deny after 60 seconds” setting that was keeping me from seeing what was going on with dashboardadvisoryd. Here, for your viewing pleasure, is the window that popped up for me. As you can see, it’s parent PID is 1, which is launchd, so it really is a periodic service fired off by launchd.

I’ve now added a permanent Deny rule to Little Snitch for this, as I don’t really approve of this check-in procedure by Apple to verify the widgets I’ve installed. Of course, now I really want to get a license of Little Snitch for my wife’s iBook…

I’ve been reading with some interest all the discussion online regarding Apple’s secret thrice-daily checkup with the mothership to determine if your Dashboard widgets match what Apple has published on it’s own site. I think a good part of this was kicked off by the “Apple Phones Home, Too” article on Daniel Jalkut’s Red Sweater Blog. At least, I’ve only noticed the other blog posts swirling around the ‘Net after reading his.

I am, however, a little confused, as I run a number of widgets on my Dashboard, but I find no running “dashboardadvisoryd” process running. I, too, run Little Snitch to try to keep an eye on what my computer is doing on the network, and I have not yet been asked what to do about “dashboardadvisoryd”. I even went so far as to explicitly delete all the rules in Little Snitch for the Dock, in case this “phone home” thing was running under the Dock’s name, but still, nothing.

Feeling left out, I decided to see if I really had updated my system. Yup, Software Update says I’m up to date, and About This Mac tells me I’m at 10.4.7. Okay, so this mystical daemon must be on the system somewhere. Dropping to a terminal window (I tend to prefer iTerm over Terminal), I broke out the trusty find command, which told me that yes, indeed, the daemon exists on my system. The only two files with “dashboardadvisoryd” in their names were:

/private/etc/mach_init.d/dashboardadvisoryd.plist
/System/Library/CoreServices/Dock.app/Contents/Resources/dashboardadvisoryd

So, does that mean my system is not phoning home to the Apple Mothership, or does this thing only run periodically (say, from cron or launchd?) Nobody I’ve read yet has really specified how it runs. Anyone know? Or has Apple disabled this in something else I installed via Software Update? (Yes, unlikely, I know.) I suppose one final option is that Little Snitch has been asking me about it, but I’ve not been around to answer it, so it happily defaults to denying the connection. Couldn’t find anything in the system logs from Little Snitch, so I’m not sure about this last theory.

UPDATE: Yes, I had Little Snitch set to automatically deny any connection request after 60 seconds. I’ve disabled this for now to see if I can catch this little daemon in the act.

In an effort to spare others the pain that I’ve gone through in the past week, here are some helpful pointers for avoiding giving an attacker an “easy” way in to your systems.

Don’t assume that because you lock down your network traffic at the firewall that you can avoid any of these issues.

0. I originally thought I didn’t have to mention this, but you’re already not allowing any unencrypted login access to the system, right? No telnet, no rsh/rexec/rlogin, no unsecured IMAP/POP3? You’re sure? You’d better be sure.

1. Whatever you do, block X11 traffic everywhere you can.  At the border.  On the individual hosts.  At any intermediary routers.  If you’re running a thin-client lab and the host server is on a different subnet, make an exception.  Otherwise, shut it the hell down. When a remote X app is needed, it can be tunneled by SSH.

2. Don’t automatically enable ForwardX11 or ForwardX11Trusted in SSH.  If you connect to a compromised host, you could very well be doomed.  It’s not that hard to toss an -X or -Y onto the command line when you really _do_ need to fire up a remote X app.

3. Never, ever, under any circumstances, allow root logins via ssh.  PermitRootLogin no is your sshd friend.  If you absolutely must allow root to log in, choose between without-password (only public key authentication) or forced-commands-only (which will only allow you to run commands and not get an actual shell, again by public-key authentication only.)

4. Never, ever, under any circumstances, use the same administrator/root password on more than one machine.  If you’re using LDAP or NIS, exclude all privileged users from your directory.  This does mean you need to keep a store of these passwords somewhere, if you have a lot of them. I’d suggest gpg-encrypting them onto a USB stick on a trusted host. We’re looking at PDAs that will allow us to lock/encrypt data on them, too (more useful). Change the root passwords periodically. A tool like apg (A Password Generator) is your bestest friend. I run it like:

   apg -n 10 -m 8 -x 8 -t -a0 -MNCl

   This will generate ten pronounceable eight-character passwords that will include at least one numeric, one capital letter and lowercase letters. Some people really want to have non-alpha-numeric characters in passwords, too. For that, just change the -MNCl to -MNClS and be happy with symbols.

5. On any machine that’s not meant for general use, disallow all but the absolute necessary logins (i.e., only admin staff).  On top of that, disallow SSH password authentication, and force all your staff to use public-key authentication.  Ensure that staff have workstations that have workstation-local home directories, to prevent the private keys from leaking out to insecure hosts.  This way, even if a password gets cracked, an attacker still can’t easily log in to these locked-down hosts without brute-forcing an SSH DSA private key.

6. Consider a career other than Systems Administration.