Close

See How Your Peers Are Moving Forward in the Cloud

New research from CDW can help you build on your success and take the next step.

Oct 24 2007
Security

Block Unhealthy Systems

Campuses face unique challenges to implement effective network access control.

Campuses face unique challenges to implement effective network access control.

{mosloadposition mostpop}

You know you have a problem when your students show up with computers filled with viruses, worms and other malware; virus definitions that have been outdated for years; and security vulnerabilities that should have been patched a year ago. That was the case at our school, State University of New York-Purchase, and I’m sure many higher education institutions face the same predicament.

After several years of fighting a losing battle to keep the network running while answering the constant alarms from our intrusion detection system, we decided to implement network access control (NAC) last fall to keep computers that were infected — or had impaired immune systems — off our production network until they could be remediated.

A NAC system detects a device when it is powered on or connected to the network, determines if the system meets the site administrator’s standards for system health, and either grants access to the production network or tosses it in a quarantine network until its owner takes the steps to bring it into compliance.

Sounds simple enough, right? But the university world has unique NAC challenges, mainly because campus networks are far more open than those in the business world.

Most NAC systems are primarily designed for the corporate world where system administrators have more control over user workstations than we do over student machines in the dorms.

When implementing NAC, we discovered the key criteria were the way systems assessed user systems for health and how they quarantined machines that failed to meet standards for our network.

Typically, system health checks can require that students install and enable current antivirus software, operating system patches and hot fixes. With some NAC solutions, you can also ban from your network systems with peer-to-peer file sharing or other troublesome applications installed.

These issues are crucial on campus. We don’t know and can’t control what students show up with on their computers, and peer-to-peer file sharing can cause sticky legal problems because of alleged copyright infringements.

These are the major questions we asked when installing NAC:

Would we use agents on devices? If so, what type?

Would we go with a network-based, host-based or in-line NAC device?

What type of access control would we use?

Hire an Agent

The obvious way for a NAC solution to collect system health data is through a software agent users install on their systems. After the agent is installed and configured to run under the security context of a privileged user, it looks into the file system and registry to determine if the system has the required patches and antimalware software installed.

The problem is, users don’t like to install permanent agents. Frankly, neither do most system administrators. They take up memory and disk space, have to be distributed and occasionally updated, and slow down systems. Alternatively, some NAC products collect system data without an agent.

Agentless NAC solutions can determine system health by remotely logging in to the system and looking for the same files and registry entries that an agent would. This technique works fine in the corporate world where central IT has administrator privileges through Active Directory to all the systems that need access to the production network. But not for a university where student-owned machines need access to the network from dorm rooms.

Agentless systems can also scan systems for known vulnerabilities on devices. Unfortunately, unpatched systems with software firewalls might pass a vulnerability scan because the firewall will block access, but it won’t block infected attachments sent through Web-based e-mail.

Transient agents are another option. Transient agents acquire the same information as an agent with no permanent software on the user’s system. The user loads the transient agent ActiveX control or Java applet from the NAC controller’s captive portal page before being granted access to the network.

The transient agent allows the NAC solution to determine if the system meets the site’s health policy and disappears when the user ends the browser session. The NAC solution can scan file systems and the registry for patches and antivirus settings, and there’s no pesky agent left on the user’s computer.

We picked transient agents at the start. However, users missed the little banner message from Internet Explorer asking for permission to load the ActiveX control and were annoyed that they had to load it every time they wanted access to the network. They also made it difficult to reinspect systems that were connected to the network for weeks at a time but didn’t keep the initial browser windows open. We soon asked users to install permanent agents, and that significantly cut our help desk calls.

Find the Right Spot

Another issue is where the NAC will reside.

In-line NAC solutions install an appliance in the network through which all users’ traffic passes. These appliances can block access to devices that haven’t passed a health check or only allow them to access remediation sites such as Windows Update and antivirus vendors’ Web sites. There, users can download the correct antivirus software. This approach can provide finely granular access control, but the NAC appliance can also introduce network latency, reduce available bandwidth and become a single point of failure.

To solve these problems, large networks either will need many appliances or must install the appliance near the core — allowing infections to spread through edge devices.

Host-based solutions add a centrally controlled software firewall to the agent that users install on their systems. The firewall limits access to resources based on instruction from the central control server. Systems that pass their health check can have full access and others are limited. We were concerned that student machines might behave strangely off campus if we used this approach. Plus, we would have to buy agent licenses for new students each semester because the software would still be on machines of students who left.

Network-based systems use the IEEE 802.1X protocol or simple network management protocol (SNMP) to authenticate machines through network switches, or request and obtain an Internet protocol (IP) address through the dynamic host configuration protocol (DHCP). Network-based systems are out of band, because the user traffic does not pass through the NAC device.

Nothing but Net

We picked a network-based solution. We considered host-based NAC too intrusive for student computers we didn’t control. In-band NAC might use too much bandwidth and leave us open to a system failure.

But we still grappled with the issue of how we would control access. We originally intended to use 802.1X to assign systems to virtual local area networks (VLANs) based on user identity. However, our campus users objected to having their Web surfing identified, so we decided not to require authentication to access the network.

Instead, our initial rollout used DHCP for access control. Each VLAN on the network had two IP subnets assigned — the production subnet and a quarantine subnet that used the NAC appliance as its Domain Name System server.

Requests to access Windows Update and other remediation sites received valid IP addresses in response to DNS requests. Other requests went to the NAC appliance, which would display a message telling the user to remediate. We worried that clever users could bypass this system by assigning their machines a valid IP address from the production subnet, but fortunately none did.

We’ve since moved to a system that uses SNMP to assign switch ports to production or quarantine VLANs. This eliminates the risk of users bypassing the system. The trade-offs were that it required us to replace a few switches in our network that weren’t supported by our NAC vendor, and we had to do quite a bit more configuration work than we did with the old DHCP system.

A NAC system is a great way to keep systems off the production network unless they are secure. With standards still evolving, you’ll have to make sure that you choose a NAC solution that fits with your network design and management philosophy.

NAC Tips

When implementing NAC, keep these tips in mind:

  • NAC is not a substitute for patch management or intrusion detection.
  • No system is perfect. Look for one that addresses 90% of your environment.
  • Transient agents are the best way to check guest notebooks.
  • Leave some grace period for updating virus definitions; otherwise users might be required to install an update they can’t download yet.
  • VLAN and 802.1X solutions require NAC vendor support for all of your switches.

Goals

A good NAC system will do three things:

  • Identify users — who is on the network, when and where.
  • Keep the end-point clean by making sure only secure devices log on.
  • Enforce usage policy by monitoring devices already on the network to make sure they stay clean.