Educause Security Discussion mailing list archives
Re: Revisiting wireless NAC
From: Jeff Kell <jeff-kell () UTC EDU>
Date: Sun, 6 Jan 2013 16:25:02 -0500
Touching on a few points in this thread... responses inline On 1/4/2013 2:43 PM, David Curry wrote:
Back when we first implemented NAC (this is the second product), requiring antivirus software was a major factor in keeping malware out of our network. But as we all know, it's not that simple anymore--just having antivirus isn't enough to keep the malware out
We also started with a "heavy handed, gatekeeper" NAC deployment. The gatekeeper aspect is what results in the most negative user reaction, and it just gets worse when you periodically re-evaluate and force remediation/quarantine on policy violations. Over the years we have downplayed the remediation aspect, but we do insist on the initial registration and agent. This firmly associates the user with the host/device in question, and the agent registers all of the network interfaces (wired/wireless/etc).
Why don't we get rid of the NAC all together? And instead, we'll just let any device connect to the network (provided the user authenticates), and let it do whatever it wants, right up until the point at which it misbehaves.
Yes, and the "misbehavior" is typically identified only by IP address (by your IDS/IPS/firewall/SIEM/etc). Now you need to associate that back to the user. If you now quarantine the device, you have to insure that you quarantine the WHOLE device (wired and wireless connections).
Instead of running the NAC system, we'll run some kind of intrusion detection system that's looking for malicious traffic. If it sees some, it will block the traffic from that device, and move the device into a "quarantine" or "remediation" VLAN where the user can be informed
This is essentially what we are doing, although there is not that much "automated" quarantine action directly from the findings. We evaluate the IDS/IPS/etc information and have a manual process to perform the quarantine action, and it also has a side database to track the reasons (and device/user history). It could be scripted to a greater degree of automation for "highly reliable" indications of compromise, but we're not there yet. The Helpdesks (campus and student/resnet) have Senior Techs that have access to clear the quarantine status after they are addressed. We would like some sort of "self-service, 3-strike" self-remediation available, but again, we're not there yet. If I had more programming staff and hours available I'd love to address that, but we're a skeleton crew with more than enough irons on the fire already.
So finally, my question: Has anybody implemented something like this? If so, would you be willing to share how you did it?
It's based on Bradford, and works across our wired (Cisco, Procurve, Brocade) and wireless (Aruba) networks, and we cover both Resnet and campus. We have been running with "remediation" disabled for the last few years, but employ their "quarantine" (dead-end) for the cases such as above. We also tweaked the quarantine vlan to allow continued access to our web site, helpdesk, email, so as not to completely cutoff the victim user. The "quarantine" however trumps everything else... you can quarantine an unregistered MAC address... regardless of where they connect. It's not dependent upon registration or having an installed agent to handle the magic. On 1/4/2013 4:04 PM, Mark Monroe wrote:
What is the best way people have found to do this without letting ipads or tablets or personal laptops getting on that wireless network?
We allow pretty flexible BYOD at this point, and tweaked the NAC registration to support the wider variety of devices. Most anything that has a browser can be registered quickly, and we don't push any agents to wireless devices. We just authenticate and register the device to the user.
Institution owned devices such as laptops or PCs are able to get on the same as your wired clients (eg. Internal Network)
We do role-based security that is assigned by device (initially inherited from the user, but devices can be individually changed). Phones/PDAs/etc get their own default role... but currently we don't really have any restrictions different from default campus network access. The role-based security translates to a vlan on the wired network, or a role at the Aruba controller. On 1/5/2013 1:31 PM, John Kaftan wrote:
I have been thinking about the same thing. For us registration takes 10 + min the first time because they have to register, get scanned, load the agent, get scanned again and then go through our network use agreement etc. It is very heavy on the front end, i.e. guilty until proven innocent. I'd rather let them on and then just spank them if they are doing something bad.
There is the initial "pain" here as well, but we have minimized much of it (the somewhat kludgy captive registration portal) by pushing new devices into our "setup" wireless SSID. This leverages XpressConnect to configure the device for our wireless (wpa2/enterprise), and as a bonus will install the NAC agent if it isn't already present. This essentially bypasses the registration portal, the agent pops up for authentication credentials, does a scan, and registers the device.
The other thing we are missing is that we are not catching other questionable behavior such as folks trying to hack our network. With this system we could quarantine someone if they did a Netscan or hit the admin account on our DCs or anything that we don't like. It would be amazingly powerful and secure and cool.
As noted above, the "quarantine" trumps everything. If we can get a MAC address, we can quarantine it. Our NAC tracks MAC/IP/switchport connections for even unregistered (rogue) devices so this is fairly easy to do. Jeff
Current thread:
- Revisiting wireless NAC David Curry (Jan 04)
- Re: Revisiting wireless NAC Justin Azoff (Jan 04)
- Re: Revisiting wireless NAC Patrick Gorsuch (Jan 04)
- Re: Revisiting wireless NAC Hahues, Sven (Jan 04)
- Re: Revisiting wireless NAC Mark Monroe (Jan 04)
- Re: Revisiting wireless NAC SCHALIP, MICHAEL (Jan 04)
- Re: Revisiting wireless NAC Martin Golizio (Jan 05)
- Re: Revisiting wireless NAC John Kaftan (Jan 05)
- Re: Revisiting wireless NAC Jeff Kell (Jan 06)