Back in 2003, before network access control (NAC) became one of security's hot buttons, a few engineers at Harvard University developed a way to detect end points, discover their configurations, and isolate those that might present a security risk to the network.

In essence, these guys were doing NAC before NAC was cool.

The engineers, Kevin Amorin and David LaPorte, began working on the idea -- called PacketFence -- in their spare time, on their own computers, with the idea of creating a commercial product. But before they knew it, there were dozens of vendors swarming in the NAC space, and all of them had deeper pockets than the two university employees.

Today, the two men's dreams of making millions have largely fallen by the wayside, but the technology they developed still has legs. In fact, the engineers have turned PacketFence into an open source project which has captured the attention of some universities and small businesses.

"We've rebranded ourselves as an open-source NAC technology," says Amorin. "And we've seen some interest out there."

PacketFence, which is used in many parts of the Harvard network as well as in several other academic environments, offers some of the same features as Cisco's Network Access Control and Microsoft's Network Access Protection, but in a very different form factor.

"For them, it's all about attributes," says LaPorte, who notes that most NAC vendors put an agent on a known machine to collect data about configuration and risky behavior by end users. PacketFence, on the other hand, is designed to manage access by devices that aren't controlled by the NAC administrator and can't be automatically changed or remediated.

"In the academic environment, for example, you don't always control the student's computer," he says. "This is a way that organizations can help register and detect problems in those systems, without controlling them or putting an agent on them."

PacketFence started out as a series of "traps" designed to detect and isolate end users whose machines were worm-infected or unsafely configured, the engineers explain. They developed a method of mapping the MAC address of the machine to the end user's identity, and then helping the users with risky configurations to remediate their machines before being allowed to log onto the network.

Today, PacketFence contains a broad suite of scripts and applications, including open source technologies such as DHCP fingerprinting, Address Resolution Protocol (ARP), and the Snort IDS/IPS. The whole thing can be staged on a Linux server running Apache and PERL scripts.

"You can use it just for registration [of end points] or just for detection of potential issues, but most of our users do both," Amorin says. When an end user tries to log into a network protected by PacketFence, the system finds out what the client is running and isolates any devices that might be dangerous. The system then instructs the client on how to fix itself so it can be allowed onto the network.

At this point, PacketFence is no threat to large-scale commercial systems such as Cisco NAC or Microsoft NAP, because it doesn't collect attribute information and it doesn't stop all dangerous traffic. "What we do with ARP, for example, is best-effort," says LaPorte. "It's possible for a bad packet to slip through, which might not be good enough for a corporate user."

But the engineers have gotten some interest from small businesses that want the functionality of NAC but don't have the budget, Amorin says. "The GUI is unusually good for an open source product, and the functionality is good enough for a lot of academic and small business environments."

The engineers are watching the NAC standards battles with interest, and they may adopt some of the winning technologies for collecting and storing attribute information. They are also working on a method of mapping SIP phone numbers to MAC addresses. "We're still developing [PacketFence]," Amorin says. "We think it's got some potential."

— Tim Wilson, Site Editor, Dark Reading