4

I’m considering enabling WoL (Wake on LAN) on the workstations on my network.

In order to boot a workstation using WoL I require its MAC address. I could store the MAC address in a database, however I’d much rather store it as an attribute of the computer object in AD. My intention is to write a startup script that will write the MAC address to a spare attribute in AD.

I’ve been unable to think of any security implications that this may introduce but would like to ask the community whether there’s anything I’m overlooking or should take into account before implementing this?

Fitzroy
  • 141
  • 1
  • 1
  • 4

2 Answers2

1

Some people consider the MAC address to be "somewhat secret". This is misguided, but be aware that making the MAC addresses public may generate some amount of nervousness. You may have to justify yourself.

For instance, a rather common configuration option on "intelligent switches" is to restrict each ethernet port to a single MAC or only a short list of MAC addresses; this is an attempt to discourage employees from bringing their own device. It is not a strong security system; it can be easily countered by setting the MAC address of an external device to a specific value. However, this has contributed to propagate the idea that the MAC address is a kind of password, hence the nervousness about publication.

Wake on LAN is in a similar situation: since it allows for waking machines up remotely, it could, potentially, be used by an attacker to attack powered-off machines. In that respect, switching the machine off no longer is the ultimate security.

(It can make for an interesting DoS. A computer which boots up uses more power than a computer which is merely "up"; this effects last for only a few seconds, until all hard disks are up to speed and the CPU has finished its boot-time self tests. With a generic Wake-on-LAN, it is possible to wake a bunch of machines simultaneously, and overload the fuses. I have known a computer room which could handle all systems up and running, but not all systems booting. So the machines had to be configured to not power-up automatically when power is back after a shortage. A generalized Wake-on-LAN may allow for the same kind of effect.)

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Storing information in AD doesn't mean it's public.. each object can have a different permission applied. Same goes for attributes – makerofthings7 Aug 30 '13 at 21:12
1

The challenge, as Thomas Pornin alluded to, is keeping the MAC address information secure, and not unnecessarily public.

Here are a few ideas that come to mind

  • Extend AD's schema to accomodate the data. You might be able to use the self permission and save it to the User object itself (the login script runs in the context of the user)

  • Write the data to a web server, which in turn writes it to AD. This is more of a way of proxying the writes to AD, and could be useful in auditing situations.

  • Find an attribute where you can use the built in the Confidential Flag. This may work best if you use the web server approach above, and don't want to extend the schema. That way you can save information to an unused attribute such as jpegPhoto, or something else.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536