[unisog] Bonjour Sleep Proxy Server issues

Krassimir Todorov krassimir.todorov at epfl.ch
Thu Sep 17 08:11:50 GMT 2009


Hello.

I don't know if this could help :

The Wikipedia http://en.wikipedia.org/wiki/Sleep_Proxy_Service#Implementations
 says :

Computers running Mac OS X Snow Leopard act as a Bonjour sleep proxy
server when Internet sharing is enabled.[5]

referencing :

[5] Apple Inc. Worldwide Developers Conference (WWDC) 2009, Session
508, Zero Configuration Networking Using Bonjour

Here we seem not to have those problems (at least for now, but they
can come ...)

_______________________________________________________________________

Krassimir TODOROV
http://dit.epfl.ch/
http://www.epfl.ch/
krassimir.todorov at epfl.ch
_______________________________________________________________________

 GPG KeyFingerprint=7EF8 DBA0 3700 8A56 2E48  7899 C39E 6C16 FFEB F5C1
_______________________________________________________________________



On Wed, Sep 16, 2009 at 2:58 PM, Paul FM <paulfm at me.umn.edu> wrote:
> I note that I can find no other posts to this list (in the last 30 days) that
> report any similar problem (nor have I seen it on any internal lists where I
> work).  So I suspect it is something about the way your Mac 10.6 machines are
> set up.  Perhaps you have a person that everyone of the victims goes to,
> giving incorrect advice. Or, maybe there is a Trojan (or even some cute
> little free P2P program) going around that turns sleep proxy on.
>
> Did the victim machines have the mac firewall turned on?
> The firewall might block enough of the negotiation to prevent this behavior
> (if it is a default behavior).
>
> Have you checked the configuration of the victim machines?
> Did someone turn on the sleep proxy service, or was it even configured?
> Is there perhaps a parameter being sent by your DHCP server that turns it on?
> Is there another service turned on that causes sleep proxy to be set up (like
> file or print sharing - or media sharing)?
>
>
> You should also get the word out to your users how to make sure their devices
> never are victims nor perpetrators (and you may want to block the mac
> addresses of devices that are either so they have an incentive to set apple
> equipment up correctly).
>
>
>
>
> Irwin Tillman wrote:
>> Another update:
>>
>> Our institution has now seen a number of additional incidents.
>>
>> The devices that have stolen IP addresses in this way have included Apple Time
>> Capsules, an Apple AirPort Express or Extreme Base Station (model not clear),
>> and a number of Mac OS X 10.6 workstations.
>>
>> All the victims to-date have been Mac OS X workstations. (In the cases where I
>> was able to obtain version information from the owner, I've seen that the
>> workstations were running Mac OS X 10.6.)
>>
>> I see that the updated version of http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
>> (version -08 dated September 10 2009) now documents that this is in fact the way
>> that a Bonjour Sleep Proxy Server is intended to behave. That is, section 17 of
>> that document states that a Sleep Proxy Server does indeed take over the IP
>> address of the Sleep Proxy client.
>>
>> So I understand that the incidents we are seeing is in fact due to the intended
>> behavior of the Sleep Proxy Server.
>>
>> ( I note that in a number of the incidents I have seen, the devices that stole the IP addresses
>> -- the device acting as a Sleep Proxy Server -- were workstations running Mac OS X 10.6.
>> So despite what http://support.apple.com/kb/HT3774 says about which Apple devices can
>> act as Sleep Proxy Servers, it seems to me that Mac OS X 10.6 *can* act as a
>> Sleep Proxy Server, at least under some circumstances. )
>>
>>
>> I have revised the bug report I filed with Apple, to indicate
>> that these are my issues with the behavior of the Sleep Proxy Server:
>>
>>
>> 1) I'm unhappy with the fact that a Sleep Proxy Server takes over the IP address
>> of a Sleep Proxy client (it claims the IP address via ARP, and sends packets
>> with the client's IP source address), because it makes managing an enterprise
>> IP network harder.
>>
>> One of the most effective tools I have for detecting problems with our
>> institution's IP network is automated reviewing of our IP routers' IP ARP caches to
>> locate devices (identified by hardware address) using IP addresses they are not
>> assigned to use.  This allows us to detect a wide variety of problems,
>> from accidentally and deliberately misconfigured machines, to malware
>> stealing large blocks of addresses.
>>
>> The behavior of the Sleep Proxy Server makes this infeasible.
>>
>> Also, our institution is often required to identify what hardware address was
>> using an IP address at a particular time. Sometimes this is for legal reasons,
>> say, prompted by reports of copyright violation. Now some of those incidents
>> will be tagged as being the fault of the person responsible for the Sleep
>> Proxy Server (rather than the sleeping client), because the Sleep Proxy Server
>> had taken over or relinquished the IP address close to the time of the
>> incident. It's bad because the Sleep Proxy Server (or really, the person
>> responsible for the device running the Sleep Proxy Server) gets blamed for the
>> incident, and also bad because that person never had any intention of running
>> a Sleep Proxy Server.
>>
>>>From my point of view, the device acting as a Sleep Proxy Server was assigned to
>> use one IP address, yet the behavior of the Sleep Proxy Server results in this
>> device using other IP addresses as well. Without the Sleep Proxy Server present,
>> daily review of the IP ARP cache data reveals a number of anomalies -- problems
>> (such as devices configured to steal another's IP address) that need to be
>> diagnosed and corrected. But finding those anomalies becomes impractical once
>> there are Sleep Proxy Servers on the network. Our network has 20-30K network
>> interfaces attached during the course of a day. Even with just a hundred or so
>> Sleep Proxy Servers (say, just the Time Capsules and AirPort Base Stations), the
>> number of anomalies to handle each day becomes impractical. Spotting the anomalies that
>> *aren't* due to Sleep Proxy Servers is no longer feasible.
>>
>>
>>
>>
>> 2) If the IP address was assigned to a client via DHCP, is it really
>> appropriate for the client to temporarily "transfer" this IP address to
>> another device? Put another way, is a DHCP lease transferrable?
>>
>> I've always viewed a DHCP lease as something a DHCP server awards to a DHCP
>> client. The client can use the lease, renew it, or release it, but it can't give
>> it to someone else (even temporarily). I don't feel the DHCP lease includes the right
>> to (temporarily) transfer the leased IP address to another device.
>>
>>
>>
>>
>> 3) Is it easy for an attacker on the same IP network as the Sleep Proxy Server
>> to leverage the Sleep Proxy Server behavior to force the Server
>> to participate in a Denial of Service attack?
>>
>> That is, say an attacker on the same subnet as the Sleep Proxy Server
>> sends the Server a message telling it to take over the IP address of some victim
>> (on the same network) for some time period.  Perhaps the attacker send messages telling
>> the Sleep Proxy Server to take over every IP address on the network,
>> or just the address of the network's IP router.
>>
>> Or does the protocol include measures that make this sort of attack
>> impractical?
>>
>>
>>
>>
>> 4) I feel that any Sleep Proxy Server implemenation (e.g. in the Apple Time
>> Capsule, AirPort Base Station, Mac OS X 10.6, and any platform on which it is
>> implemented) must have an "on/off" switch, to allow the owner of the device to
>> cause the device to *not* act as a Sleep Proxy Server.
>>
>> That's in keeping with a general philosophy that if 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. Otherwise
>> you are (in effect) saying "If you attach your Time Capsule to the network,
>> we're going to force you to offer Sleep Proxy Service to the network."
>>
>> In addition to providing the user with a way to disable the Sleep Proxy Server
>> functionality, I think that the default setting should be that the
>> Sleep Proxy Server is disabled.
>>
>> That default is in keeping with a philosophy that my device shouldn't offer a
>> service to the network without my explicitly telling it to do so. I don't expect
>> a modern OS or appliance to (by default) act as an FTP server, TFTP server, SMTP
>> server, TELNET server, file server, etc. I expect such services to be disabled
>> by default; the owner of the device must enable the services s/he wishes to
>> offer to the network. Offering services to the network by default (without the
>> owner explicitly turning on the service) harkens back to the bad old days, when
>> OS's were shipped "insecure by default."
>>
>> I would like to see Apple add an "enable/disable the Sleep Proxy Server" setting
>> to the user interface of each of the products that is capable of acting as a
>> Sleep Proxy Server, and have that setting default to the Sleep Proxy Server
>> being disabled. And I'd also like to see this be added as a requirement to the
>> http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
>> specification, so that other vendors who implement Sleep Proxy Servers could be
>> expected to do the same thing.
>>
>> (One exception, I imagine, would be for a product that is intended to function
>> solely as a Sleep Proxy Server. If someone were to ship an appliance or a
>> program that acts solely as a Sleep Proxy Server, it wouldn't need such an
>> on/off control, as presumably the person deploying that product did intend for the
>> product to act as a Sleep Proxy Server to the network.)
>>
>>
>>
>>
>> /Irwin Tillman
>> OIT Network Systems, Princeton University
>> _______________________________________________
>> unisog mailing list
>> unisog at lists.dshield.org
>> https://lists.sans.org/mailman/listinfo/unisog
>
> --
> ---------------------------------------------------------------------
> The views and opinions expressed above are strictly
> those of the author(s).  The content of this message has
> not been reviewed nor approved by any entity whatsoever.
> ---------------------------------------------------------------------
> Paul Markfort   Info: http://www.menet.umn.edu/~paulfm
> ---------------------------------------------------------------------
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog
>



More information about the unisog mailing list