Did you know that System Center Configuration Manager 2007 will include support for Wake-on-LAN? See http://www.microsoft.com/technet/prodtechnol/sms/smsv4/smsv4_help/43092b3c-06fb-4162-b589-28f14... for the full details, as well as Jeff Gilbert's blog posting at http://myitforum.com/cs2/blogs/jgilbert/archive/2006/08/08/22911.aspx .
So what is Wake-on-LAN? It's a way to send a "magic packet" to a machine that isn't powered on. That package is received by the still-powered-up network card, and that causes the machine to be powered on. The Wikipedia entry at http://en.wikipedia.org/wiki/Wake-on-LAN provides a good overview, and the links at the bottom provide the historical perspective.
But there is no discussion about the different ways of implementing Wake-on-LAN, or the potential security implications of each of those ways. So let's go through those:
You can then build solutions on top of those three basic implementation types. The most common method is to build a "relay agent". In this situation, the agent receives a unicast request from a server (typically a TCP conversation, point-to-point), and performs a limited broadcast on its segment, e.g. Server A instructs Workstation B to wake Workstation C that is on the same segment, so B sends the magic packet.
So the agent approach can eliminate the directed broadcast security issue, but there is the added overhead of deploying those agents (not to mention that they need to be secure too, otherwise they can be "hijacked" to perform a denial-of-service attack).
Another option: Securing directed broadcast. You can take advantage of the ability of Cisco and other routers to configure "access control lists", limiting what different hosts can do. The router can be configured to accept directed broadcasts only from certain hosts and only certain protocols and ports. For example, you could permit only a single server to send only UDP directed broadcasts, and only on a user-defined port. (See the "ip directed-broadcast [access-list-number]" command in the Cisco IOS documentation.) That would significantly reduce the potential of denial-of-service attacks as it would require that your server (the one granted access through the ACLs) be compromised, and that the attacker know which port has been opened.
Another interesting option is to not use Wake-on-LAN at all. Intel has a new hardware feature called "iAMT" (see http://www.intel.com/technology/manage/iamt/ ) that uses a management processor on the motherboard (similar to what has been used in servers for several years) that you can communicate with out-of-band, even when the computer is off. It uses HTTP (web) requests to directly talk to the computer, so no broadcasts are required.
So back to where we started: ConfigMgr 2007's support of Wake-on-LAN. It supports both the "directed broadcast" method and the "unicast" method described above. For many of you, that will be all you need, but there are other third-party options available too that should integrate well into ConfigMgr 2007.