NetDB & Host Security

In the quest for host security here at Stanford various network hacks have been suggested to further the cause. And if it has anything to do with the network, it eventually ends up in NetDB. This document gives a brief introduction to the NetDB changes that might be made to support host security.

Node State Attribute [Implemented.]

Sunia has suggested a node state attribute. Potential values might include good, vulnerable, compromised, blocked, etc. Certain values might trigger altered DHCP and/or DNS service for a node. The state attribute might also be used to create reports on the overall health of hosts.

DHCP Client Classes [Implemented - Node States can be Client Classes.]

NetDB currently supports a single DHCP client class, roaming. A roaming client is allowed to use dynamically assigned addresses anywhere on campus. It has been suggested that a second DHCP client class, guest, would be useful. A guest DHCP client would receive an IP address that is topologically off campus. Modifying NetDB to accommodate multiple DHCP client classes would allow for guest and other types of DHCP clients.

Here's a table showing potential DHCP client classes and how they might be used.

DHCP Service Areas [Not Recommended - See below.]

NetDB and Networking currently support a single campus-wide DHCP service. Nodes are added to the DHCP service when the DHCP flag is checked in NetDB. It is possible to modify NetDB so that the campus network can be divided into more than one DHCP service area. New areas could be created to accommodate disparate security or service models.

Details

Figure 1 shows the proposed changes to the logical data model to implement DHCP service areas, DHCP client classes, and the state (called quality (its old name) in the figure) attribute.

Figure 1 - Logical Data Model Changes

Figure 2 shows how the NetDB Node page would change if both DHCP client classes and service areas were implemented. It also shows the changes if just DHCP client classes were implemented. (Note that, once again, quality = state.)

Figure 2 - NetDB Interfaces changes for DHCP Client Classes & Service Areas

Recommendations

Implementing the node state attribute, DHCP client classes or DHCP service areas is more than a trivial exercise, so we shouldn't implement any of them until there's a real need and the resources to do the work. Service areas are more work to implement than client classes or the node state attribute and they'll complicate the LNA's job somewhat*, so make sure you really want them before charging ahead.

*LNA's would have to set DHCP flags and client classes for any DHCP area a node would be likely to use. So things get complicated as the number of areas grow.