Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Bonjour Sleep Proxy service stealing IP addresses?

During September 3-13 I've seen eight Apple devices on our institution's network
steal IP addresses leased to other devices.
All the victims have all been Macintosh workstations.

I suspect that the new Bonjour Sleep Proxy service is involved.

The devices that have stolen IP addresses are:
Apple Time Capsule: 5
Apple AirPort Express: 1 (device type not yet confirmed with ower)
Mac running Mac OS X 10.6: 1
Mac running Mac OS X: 1 (device type and OS version not yet confirmed with owner)

If you monitor your network closely enough
to reconcile actual IP address usage (e.g, based on IP ARP cache data) against IP address assignments
(perhaps based on DHCP server logs), you may see this too.

I've not been able to locate published documentation of the Bonjour Sleep Proxy protocol.
(I've already seen the Apple KB article http://support.apple.com/kb/HT3774
providing an overview of the "Wake on Demand" feature, the reference
to "Sleep Proxy Servers" in http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt , and the Sleep Proxy Service patent in http://patft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u= %2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,330,986.PN.&OS=PN/7,330,986&RS =PN/7,330,986 .)

I've opened a bug report with Apple for one of the incidents (in which the thief was a Mac running Mac OS X 10.6);
in that case I was fortunate to have a system.log file from the "thief".
In my bug report I've also mentioned the Apple Time Capsule incidents too.
I'm still trying to retrieve logs from some of the other thieves and victims,
to expand my bug report with more examples.

One detail that's surprising is that one (possibly two) incidents to-date indicates that
the Bonjour Sleep Proxy Server is also present on (at least) some Mac OS X systems.
Apple's published doc to-date indicates that only Apple Time Capsules and
Apple AirPort Base Stations with 802.11n running firmware 7.4.2 provide
that service.

(I also wonder how easy it would be for someone to exploit a Bonjour Sleep Proxy Server
to launch a denial of service attack on the network to which it is attached. Without documentation about the
actual Bonjour Sleep Proxy protocol, I'm only speculating, but it seems these
Bonjour Sleep Proxy Servers accept a message that causes them to "steal" an IP address
for a period of time. What would prevent someone from sending a series of these
messages to a Bonjour Sleep Proxy Server to tell it to steal many IP addresses (on the local
IP network)...or perhaps just the IP address of the network's IP router?)

Irwin Tillman
OIT Network Systems / Princeton University

Mac Pro (early 2008), Mac OS X (10.6.1)

Posted on Sep 14, 2009 5:22 PM

Reply
19 replies

Sep 14, 2009 5:23 PM in response to irwintillman

Here's an example of one of the incidents.

(IP addresses, MAC addresses, and computer names have been anonymized.)

The "thief" is a Mac OS X 10.6 workstation.
The "thief" has Ethernet hardware address 00:11:11:11:11:11 and Wireless hardware address 00:22:22:22:22:22.
On September 10 it was connected via its wireless interface to our wireless network.
The wireless access point via which it connected operates as a bridge.
The thief's wireless interface used DHCP to obtain a lease on IP address 192.168.2.1.

The "victim" is a Mac worktation, operating system version unknown.
The "victim" has Ethernet hardware address 00:01:02:03:04:05 and Wireless hardware address 00:01:02:03:04:06.
On September 10 it was connected via its wireless interface to our wireless network.
The wireless access point via which it connected operates as a bridge.
It was not the same wireless access point used by the thief.
The thief's wireless interface used DHCP to obtain a lease on IP address 192.168.5.1.

Both the thief and victim's wireless interfaces were on the same IP network.

Although the thief used its assigned IP address 192.168.2.1,
during approximately 1820-1910 September 10, it also stole
IP address 192.168.5.1. (Times are approximate to within ten minutes.)

We were aware of the incident because every ten minutes we take a snapshot of the IP ARP cache from
the IP router. After the day is over, we compare that to that day's log from the DHCP servers.
This showed is that the thief was using an IP address that had not been assigned to it by the DHCP servers.

Our logs show that the thief had not previously been assigned (e.g. via DHCP)
the IP address it stole.

I note that the thief's system.log file
makes a number of references to stolen IP address 192.168.5.1;
whatever the thief thought he was doing with that IP address, he certainly knew about it:

Sep 10 14:52:15 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:17 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:17 jdoes-MacBook-Pro mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:18 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:19 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:19 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:20 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:22 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:23 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:27 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:31 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:35 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:52:48 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:52:51 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:53:20 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:53:23 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 14:54:24 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 14:54:27 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 15:08:04 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 15:08:07 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 15:08:08 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 18:11:21 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 18:11:23 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 18:32:40 dynamic-oit-vapornet-e-1 mDNSResponder[29]: Waking host at en1 192.168.5.1 H-MAC 00:01:02:03:04:05 I-MAC 00:01:02:03:04:06 for 21 mycomputer. ssh.tcp.local. SRV 0 0 22 mycomputer.local.
Sep 10 19:49:57 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:49:58 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:49:59 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:01 jdoes-MacBook-Pro mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:01 jdoes-MacBook-Pro mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:02 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:05 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:08 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:13 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:16 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:50:30 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:50:33 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:51:02 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:51:05 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.
Sep 10 19:51:46 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendResponses: No active interface to send: 10 4 mycomputer.local. Addr 192.168.5.1
Sep 10 19:52:09 dynamic-oit-vapornet-e-1 mDNSResponder[29]: SendARP: No interface with InterfaceID 101024E00 found 15 1.5.168.192.in-addr.arpa. PTR mycomputer.local.


I note that among the messages above is even one (at Sep 10 18:32:40) that specifically cites the Ethernet and Wireless hardware
addresses of the victim:

Sep 10 18:32:40 dynamic-oit-vapornet-e-1 mDNSResponder[29]: Waking host at en1 192.168.5.1 H-MAC 00:01:02:03:04:05 I-MAC 00:01:02:03:04:06 for 21 mycomputer. ssh.tcp.local. SRV 0 0 22 mycomputer.local.

The "Waking host" text is what first led me to the Bonjour Sleep Proxy service for these incidents.
Data from other incidents also point to the Bonjour Sleep Proxy service.

Sep 14, 2009 6:07 PM in response to irwintillman

Everything you've described and documneted only shows the Sleep Proxy Service working as designed. It's a part of MulticastDNS which Apple calls Bonjour. From Wikipedia (first hit on Google):

The Sleep Proxy Service is a component of Multicast DNS, designed to assist in the reduced power consumption of networked electronic >devices. A device acting as a Sleep Proxy Server will respond to Multicast DNS queries for another, compatible device which has gone into >low power mode. The low power mode device remains asleep while the Sleep Proxy Server responds to any Multicast DNS queries.
When the Sleep Proxy Server sees a query which requires the low power mode device to wake up, the Sleep Proxy Server sends a special >wake-up-packet to the low power mode device. Communication parameters are then updated via Multicast DNS and normal >communications proceed.


So by design, it is answering MulticastDNS queries for other hosts, using their IP addresses, while they are sleeping.

Message was edited by: LittleSaint

Sep 14, 2009 6:14 PM in response to LittleSaint

I understand that a Bonjour Sleep Proxy Server might respond to mDNS queries about the services for which it's been told to proxy.

But I'm surprised that it would be designed so that the server actually used the assigned IP address of the sleeping device as the IP source address of an mDNS response sent by the server, and that the server would send IP ARP Response packets claiming that the owner of the sleeping device's IP address is the Bonjour Sleep Proxy Server's hardware address. I would imagine instead that if the server sends an mDNS response, it would come from the IP address of the Bonjour Sleep Proxy Server, but contain the IP address of the sleeping device inside the payload of the mDNS response. Of course, without documentation of the protocol used by Bonjour Sleep Proxy service, this is speculation.

Sep 14, 2009 6:40 PM in response to LittleSaint

Where is the protocol used by Bonjour Sleep Proxy documented?
I understand it makes use of mDNS, but I do not see it documented.

The closest I've found is Section 17 of
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
("Multicast DNS"). It provides some information, but it doesn't
say that the Sleep Proxy Server sends IP packets using the IP source
address of the sleeping client, or that the Sleep Proxy Server sends ARP Response
packets claiming that the owner of the sleeping client's IP address
is the Sleep Proxy Server's hardware address.

It says that the full specification of mDNS / DNS-SD Sleep Proxy Service
is to be described in a future document. But I've not been
able to find that published yet.

LittleSaint wrote:
If it didn't use the actual IPs with corresponding ARPs, how else would traffic get to the proxy? Sticking the source address in the payload doesn't work because the original sender is expecting a reply from a real host not a proxy.


Why wouldn't the mDNS response have an IP source address of the Sleep Proxy Server,
but with payload that says that the service you are looking for
is provided by ...(the IP address of the sleeping client)?

Sep 14, 2009 6:57 PM in response to irwintillman

Because that's not how mDNS works. The point of the proxy is so the reply appears to querier as if it comes from the real host because as mDNS is designed that how it is supposed to appear.

The bigger and more interesting question here is why you have (if you do indeed have) workstations acting as proxies. This function is only supposed to be enabled on Airport stations.

Sep 14, 2009 8:24 PM in response to LittleSaint

I still don't see that mDNS of necessity works this way;
it seems to me that IP source address of an mDNS response packet
is not required to be the same as the IP address that appears inside any A-records
or AAAA-records in the payload. I can imagine an mDNS response packet
sent by a device that is proxying (in the general sense) for another might
have an IP source address of the sender, but contain A-records or AAAA-records
that specify the IP address of another device.

But I do see that the September 10 2009 edition of
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
(draft-cheshire-dnsext-multicastdns-08.txt)
provides additional information about the Sleep Proxy Service in section 17,
compared to the earlier September 10 2008 edition (draft-cheshire-dnsext-multicastdns-07.txt) I had previously seen.

The new edition does indeed make it clear that the intent of that specification is
that the Sleep Proxy Server actually takes ownership of the
sleeping device's IP address(es). That is, the Sleep Proxy Server
will indeed send packets with an IP source address that belongs
to the sleeping client. While it doesn't explicitly say that the mDNS response packets
sent by the Sleep Proxy Server have an IP source address of the sleeping device,
it does describe other packets that the Sleep Proxy Server sends as coming
from the IP source address of the sleeping device. And because it states
that packets destined to the sleeping device's IP address are delivered
to the Sleep Proxy Server, it does indeed imply that the Sleep Proxy Server
will also send ARP Response packets claiming that sleeping device's IP address belongs to the
hardware address of the Sleep Proxy Server.

So the behavior I am seeing from Bonjour Sleep Proxy Servers on our network
(that they are using IP addresses not assigned to them)
is not an implementation bug, but is their intended behavior.

The issues I am left with are:



• If the IP address was assigned to sleeping client via DHCP,
is it really appropriate the sleeping client to temporarily "transfer"
this IP address to another device? Put another way, should a DHCP lease
be transferrable?

I've always viewed a DHCP lease as something a DHCP server awards to
a DHCP client. The DHCP client doesn't get to transfer that lease to
another device.

I'm not sure how well this idea (that the DHCP client can transfer its
IP address to some other device) fits into the DHCP world.



• Wouldn't it be easy to leverage this Sleep Proxy Server behavior (from an attacker
on the same IP subnet as the Sleep Proxy Server) to force it to perform
the Denial of Service I described above?



• I've seen a Mac OS X 10.6 workstation "steal" an IP address
in the way that a Sleep Proxy Server would. (The incident description
I posted above, with the incriminating system.log file.) But Apple's doc
doesn't say that Mac OS X 10.6 acts as a Sleep Proxy Server.



• Shouldn't the Sleep Proxy Server implemenation (e.g. in the Apple Time Capsule,
AirPort Base Station, and anywhere else it's present) have an "on/off" switch?
It seems to me that if I own the device, I should be able to turn on and off
the various (optional) services that the device offers to the network.

Just as my Mac has an on/off switch for whether or not it acts as a file server
to the network, I would think that if my device is capable of acting as a
Sleep Proxy Server for the network, I should be able to turn that on or off.

And I also think that the feature's on/off switch should
by default be turned off; my device shouldn't start offering
a service to the network without my explicitly telling it to do so.
(Except perhaps if my device were some sort of dedicated Sleep Proxy Server;
if that's the only thing my device is intended to do, then presumably I want
that behavior turned on by default.)

Sep 14, 2009 8:34 PM in response to irwintillman

AirPort base stations are usually purchased by home users, perhaps shockingly, for use in the home. If you're maintaining a complex network and need billions of configuration options and total control over everything every router does, your IT purchasing department should probably not be considering the for-dummies version in the first place.

Prove the attack is possible before you go setting off alarms.

Sep 14, 2009 8:57 PM in response to Q Lazarus

Time Capsules and AirPort Base Stations are also purchased by students, faculty, and staff. And they attach them to an institution's network. (Why shouldn't a student want to attach a Time Capsule to the network, to function as a networked storage device for her personal use?) It seems reasonable to me that the owner of the device shouldn't be forced to also have the device operate as a Sleep Proxy Server.


I didn't say "alarm: an attack is possible!". I asked (given what information is currently published about how the Sleep Proxy Server works) whether it would be easy to leverage it to construct an attack. It's the sort of thing anyone who maintains a large network with lots of these devices attached is likely to ponder.

Sep 15, 2009 4:30 AM in response to Q Lazarus

While our institution discourages our customers from attaching devices operating as wireless access points to the campus network, and indeed forbid it in certain buildings, there are many buildings where it is permitted, although not encouraged. Our university, like many others, does not enforce network use policies as strict as might be found in a corporate network.

But that's besides the point. WAP-related concerns, for example, would not apply to a Time Capsule that is configured to not operate as a Wireless Access Point. And the Time Capsule is among those devices that operates as a Bonjour Sleep Proxy.

I've begun looking at the mDNS responder source at http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-212.1/mDNSMac OSX/
I see that it includes a Sleep Proxy Server implementation. Perhaps Mac OS X 10.6 does indeed act as a Sleep Proxy Server under some circumstances, regardless of what http://support.apple.com/kb/HT3774 says.

Sep 15, 2009 5:41 AM in response to irwintillman

The proxy server should not be running from workstations. That would be my only concern if you are truly seeing such behavior. You should only have one proxy per LAN segment: the access point. Is it possible those syslog messages are mDNS messages from the access point and not internal to the workstation? Are you sure it is the MAC address of the workstation that you see with multiple IP addresses in your ARP snapshots?

If the proxy assumes IP addresses of sleeping workstations for mDNS, it doesn't really affect regular communication because those workstations wouldn't reply to anything but a wake packet anyway, and the proxy will facilitate that. Turning off Wake-On-Network mitigates this entirely as that also disables any registration with the proxy service. Proper use of DHCP snooping and ARP inspection on your routers mitigates things from an enterprise perspective.

There isn't a network tool or feature out there that can't also be used for nefarious purposes. You just weigh the pros and cons of each service and design your network and security policies appropriately.

Message was edited by: LittleSaint

Sep 15, 2009 5:46 PM in response to LittleSaint

The proxy server should not be running from workstations. That would be my only concern if you are truly seeing such behavior.


I've glanced at the mDNSResponder code at http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-212.1/
It contains support for acting as a Sleep Proxy Server; it can do so under some circumstances.
It's not apparent to me if that support is included in the version of the daemon
distributed in Mac OS X 10.6, and if so, whether Mac OS X 10.6. runs the daemon
in such a way as to tell it that it may offer a Sleep Proxy Server.

However, my experience is that some Mac OS X 10.6 systems here are indeed
acting as Sleep Proxy Servers.


Is it possible those syslog messages are mDNS messages from the access point and not internal to the workstation?


It doesn't appear that the syslog messages are coming from another device on the network.
It appears to me that they are being generated locally by the workstation.


Are you sure it is the MAC address of the workstation that you see with multiple IP addresses in your ARP snapshots?


Yes, no question.


I've now had a number of additional incidents; it's clear to me that (whether this is
something Apple intended or not) Mac OS X 10.6 workstations (at least under some circumstances)
will act as Sleep Proxy Servers.


If the proxy assumes IP addresses of sleeping workstations for mDNS, it doesn't really affect regular communication because those workstations > wouldn't reply to anything but a wake packet anyway, and the proxy will facilitate that. Turning off Wake-On-Network mitigates this entirely > as that also disables any registration with the proxy service.



To my way of thinking, mitigating the behavior of Sleep Proxy Servers by requiring
every user of Mac OS X (and in the future, any other platforms that include a Sleep Proxy client implementation)
to turn off "Wake on Network" is not practical. It makes more sense to me to mitigate this at
the devices acting as Sleep Proxy Servers.


Proper use of DHCP snooping and ARP inspection on your routers mitigates things from an enterprise perspective.


In what way?

Sep 15, 2009 7:29 PM in response to irwintillman

Depending on your network equipment, you may have switch features that track DHCP leases and the MAC/IP relationships on the LAN. An ARP message that does not match the tracked entry is dropped. Cisco calls this DHCP Snooping and Dynamic ARP inspection. The Sleep Proxy Service is essentially a type of ARP spoofing, and any measures to mitigate that would most likely also prevent the service from working. It does seem odd that this could run on any workstation as you could really only have one per LAN, but as Q Lazurus pointed out, there's really nothing wrong or "bad" happening here given the design of mDNS, it just looks like it in your logs. So, perhaps there's nothing to mitigate at all because it just works.

Sep 16, 2009 4:08 PM in response to LittleSaint

I agree that the use of DHCP Snooping and Dynamic ARP inspection of that
sort might be used to stop a Sleep Proxy Server from taking over
the IP address of a client.

It's not an approach we can use here, both because many of our clients are
attached via switch ports that don't support this, we permit clients
(on most networks) to use manual configuration instead of DHCP, but indeed this
approach might be a possibility in other environments. Thank you for
pointing this out.

Bonjour Sleep Proxy service stealing IP addresses?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.