This all boils down to physical security, and all of us know about that. No matter what operating system - no matter of DHCP verses static - without physical controls and physical security, your systems are at huge risk. And did I mention it depends upon physical security?
Two things - we don't allow visiting computers to connect to our net. This includes vendors, employees, and family. There are big signs warning that un-authorized computers are subject to confiscation. If we discover an un-authorized computer, the contents get inspected. If we find something malicious, we let security handle things - messy. If it's obviously innocent, we'll return it when the owner is evicted. Otherwise it gets a free disk wipe. "New" computers as well as existing ones returning on-site (from shows, and the like) also get the wipe and install before connecting to our network.
For those vendors who bring in computers for a presentation, we have a special sandbox - no connection to us, and a limited connection to the world.
Right out of RFC2131. Note the second paragraph.
- Security Considerations
DHCP is built directly on UDP and IP which are as yet inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure.
Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems.
Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.
I'm not at all surprised that it quit serving. Long ago, we had a user who wanted her "new computer" (a Mac IIci running OS 7.0), and it had been dropped off in an unconfigured state. So _she_ configured it. You know she got it wrong, and fumble-fingered the host IP address, setting it to the IP of an old Sun IPX (SunOS 4.1.3) that was the local NIS and DNS secondary. The Sun heard someone else answering ARP requests, and went into the corner and started to cry. Meanwhile, the entire building is now screwed. The router noted the change, and a security program flagged the change, sending mail to IT and Security. Only took about 20 minutes to find the Mac, and shut it down, but the Sun refused to talk. A networking restart brought it back up, but several other applications were wedged. We restarted ('telinit' rather than 'shutdown
-r now') as the fastest way back up, though I'm sure if we had the time, we could have gotten it up without the restart. The "user" got a written warning notice, and the intern who had delivered the computer got a lecture, as did the guy who was doing Mac support. "Procedural changes were made" is a polite way of saying there was he11 to pay.
Old guy