Bonjour Sleep Proxy service stealing IP addresses?

macs running snow leopard will act as bonjour sleep proxy servers when they have internet sharing activated. this is likely the reason you're seeing sporadic occurrences on your network rather than the entire 10.6 installed base.

Irwin,

Thanks for starting this thread. This explains why the security logs on my FreeBSD server started reporting ARP thefts following the addition of a Time Capsule to the LAN. Nice to know this is a feature, not a weird bug in the Time Capsule.

I've seen two IP addresses involved here. Both of them are sleeping Snow Leopard machines. The MAC addresses shown match the true owners of the IP addresses, plus the MAC address of the Time Capsule, so it all ties up.

Nov 16 12:06:05 server kernel: arp: 10.10.18.164 moved from 00:1f:f3:ce:38:e4 to 00:26:bb:6c:36:3e on vr0
Nov 16 12:13:50 server kernel: arp: 10.10.18.164 moved from 00:26:bb:6c:36:3e to 00:1f:f3:ce:38:e4 on vr0
Nov 16 14:35:56 server kernel: arp: 10.10.18.164 moved from 00:1f:f3:ce:38:e4 to 00:26:bb:6c:36:3e on vr0
Nov 16 14:44:24 server kernel: arp: 10.10.18.164 moved from 00:26:bb:6c:36:3e to 00:1f:f3:ce:38:e4 on vr0
Nov 16 14:45:26 server kernel: arp: 10.10.18.164 moved from 00:1f:f3:ce:38:e4 to 00:26:bb:6c:36:3e on vr0
Nov 16 15:03:45 server kernel: arp: 10.10.18.164 moved from 00:26:bb:6c:36:3e to 00:1f:f3:ce:38:e4 on vr0
Nov 16 17:13:49 server kernel: arp: 10.10.18.164 moved from 00:1f:f3:ce:38:e4 to 00:26:bb:6c:36:3e on vr0

My initial reaction was that this trick sounded a bit dirty, but to be fair some thoughtful people will have designed the protocol, and it doesn't appear to be causing any problems here. Generally the Time Capsule seems like a nice bit of kit: quick, flexible, quiet and frugal with power (it spins the drive down when it's left idle).

With my pen-test (security consultant) hat on, I'm not really worried about this from a DoS attack perspective. An attacker with unfiltered Layer 2 network access can trivially kill the whole network segment by just ARP spoofing everything[*], so Sleep Proxies don't change anything there. The only issue is whether the sleep proxy's IP address banditry turns out to cause subtle problems, but presumably the designers have thought it all through carefully. But it will cause confusion in server and firewall logs.

[*] Aside: More often, the attacker will ARP spoof the default gateway router to launch a man-in-the-middle attack, so that they can steal data rather than just causing a DoS.

If I had a criticism of Snow Leopard's sleep mode, it would be that you can't have WOL (Wake On Lan) without ticking "Wake for network access" under the Energy Saver preferences. This setting allows sleep to be interrupted for file sharing (and other events?), whereas for maximum power saving I'd prefer my machines to stay asleep unless I send them a WOL packet, or press a key on the keyboard.

Kind regards

- Martin

We're Higher Ed and Research and have a spanning LAN with extensive use of DHCP to service both local supported hosts with fixed IP's (for flexibility) and visiting hosts (truly dynamic). We also allow Ineternet Sharing so students can NAT their laptops off the backs of their desktop Macs.

To keep this situation under control, we've implemented a set of monitor scripts that watch arp transactions and compare MACs to IPs. This allows us to quickly identify collisions and/or potential nefarious use.

Needless to say, the MacOS 10.6 (Snow Leopard) Sleep Proxy Service is now driving us buggy, as it's causing our security scans to generate an enormous number of false positives comprising well over 75% of the messages we receive every day. The signal/noise ratio has rendered this function virtually useless. We are obviously very concerned from a security standpoint, but can't see any useful way of filtering out the Sleep Proxy Server stuff.

Any ideas on how we might be able to distinguish SPS packet cruft from the rest of the traffic?

Or is there a way that we might disable the Sleep Proxy Server function on hosts we manage while leaving Internet Sharing and Wake-On-LAN running? Then we could designate one or two fixed servers on each of our switched subnets to handle the SPS services for their respective areas. That way we include filters in our security scans that ignore "thefts" perpetrated by these trusted hosts. While it wouldn't eradicate the problem completely, it might make it more livable.

To prevent the Sleep Proxy Service causing these kinds of false alarms, you could simply block mDNS or ZeroConf traffic. If you allow ZeroConf traffic (eg: because you want mDNS to work), you could refine your scripts so that they can identify MACs commonly used by Apple devices and ignore attempts by those devices to "steal" IP addresses belonging to other Apple devices?

If you're paranoid about IP address allocation like this, the obvious solution is to filter out ZeroConf traffic to stop the SPS being configured in the first place.