Lab Notes

As part of my job, I spend a lot of time working with Mac OS X Server. Of course, that means I recently have been getting intimately familiar with Tiger, the latest version of Mac OS X Server. There's many nice upgrades — it's a great piece of software that I'm very happy with, but there has been one unwelcome upgrade that has had my attention today.

Like any good system adminstrator, one of the first tasks I perform when installing Mac OS X Server (or Windows Server, or a Linux server) is to configure the built-in firewall. Mac OS X comes preconfigured with firewall rules allowing basic network traffic, but most services are disabled by default. My interest was piqued when I found that one of the services enabled by default is an utterly undocumented service called "Serial Number Support" running on UDP port 626.

Like any service that I don't recognize and can't find any documentation describing, I closed off the firewall on that port. I restarted and check the status of the firewall — and Server Admin reported that the port is open! I checked my firewall rules, and they said it should be closed. Hmmm.

I checked to see if UDP port 626 actually was in use:

Yup, somebody's listening for UDP packets on port 626. Who?

Shows a process called serialnumberd listening on the "ASIA" port . man serialnumberd helpfully says "serialnumberd is the daemon for the Serial Number Infrastructure." Now that I have a general idea as to what its purpose is, it's time to figure out what data is being transmitted. A packet sniffer did the trick.

The serialnumberd process broadcasts 32 byte packets on the local subnet (i.e., it sends them to IP address 224.0.0.1). The contents of these packets seem to indicate that it is looking for another server on the local subnet with a serial number of its own. I have only the one server, so I don't know what happens when it gets a response. I'm sure that Apple is using this mechanism to prevent piracy — that is, to ensure that every copy of Mac OS X server on a network has its own unique serial number. Working for a server vendor myself, I can see where they are coming from.

So what's the moral of this story? Don't punch holes in a server's firewall without telling the administrator, even if you are doing it for a legitimate purpose.. Other than killing the serialnumberd process (such as by replacing /usr/sbin/serialnumberd with a dummy script that does nothing, the effect of which is unknown), I can't see how to avoid having this port open on my server. What's more, I only knew about it because I was paranoid enough to go back to the firewall configuration and make sure that everything was kosher. For us, this is not a show-stopper because our Mac OS X server is behind our main firewall, but I would think twice about putting a server on the internet that has mysterious open ports that can't be closed.