Partilhar via

A discussion about Wake-on-LAN

  • Artigo

Did you know that System Center Configuration Manager 2007 will include support for Wake-on-LAN?  See https://www.microsoft.com/technet/prodtechnol/sms/smsv4/smsv4_help/43092b3c-06fb-4162-b589-28f14057873c.mspx for the full details, as well as Jeff Gilbert's blog posting at https://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 https://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:

  • Limited broadcast.  In this case, you send a magic packet to a special TCP/IP address (255.255.255.255); it is received by all computers on the same segment but not forwarded to computers on other segments.
  • Directed broadcast.  In this case, you have to know what subnet the computer is on (or at least where it was last known to be) and send a broadcast packet to that segment; the router or switch takes care of forwarding the packet to all the machines on the subnet.  Because of the security implications of this (see https://en.wikipedia.org/wiki/Smurf_attack for a description of the SMURF denial-of-service attack), most companies have disabled directed broadcasts.
  • Unicast.  In this case, you have to know the computer's last IP address and send the magic packet directly to that address.  As long as that IP address is still valid, and the router or switch still has cached what port that computer is attached to, the magic packet gets to the computer and it wakes up.

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 https://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.

Comments