Re: Revisiting wireless NAC

["Hahues, Sven" <shahues () FGCU EDU>]

Mr. Curry,

I do not know if there is a solution like this sold by a particular vendor, but we are kind of doing what you are 
looking for in regards to peer to peer enforcement on our housing network, but it probably wouldn't be too hard to 
extrapolate this a little further:

In our housing network we run an application called Integrity by RedLambda which is basically a fancy packetsniffer 
with a lot of p2p signatures.  If this device sees peer 2 peer traffic, it sends an SNMP trap over to our NAC which 
causes the device to be moved into a quarantine vlan.  There we hijack the DNS and redirect them to a page where the 
users have to log in with their username and password (ldap lookup) and they are shown what their device was found to 
be wrong with their network traffic.  They can read what they did here, and finally are able to put themselves back on 
the network using a three strike system.  (Every strike increases a timeout that the users have to wait though there 
are some opt-out methods for legitimate uses of p2p)

Depending on your NAC you may be able to steer your users to a remediation portal that is configurable for what you are 
looking for.  Our NAC at least lets us do so for AV/Updates.  Extending this a little further should not be a problem.

Ultimately, I think what you are looking at doing is being able to have your devices have some sort of multi-tiered 
access on the wireless (at least that's how we would like it):

*  Institution owned devices such as laptops or PCs are able to get on the same as your wired clients (eg. Internal 
Network)
*  Devices that cannot be fully validated, or are mobile devices should have some access to internal data, but not full 
access like a computer that is authenticated using a certificate and uses network traffic protection
*  Untrusted devices such as the laptop Joe student brings to your campus to just surf the web, or chew up your 
Internet bandwidth by watching Netflix on your wireless

Hope that helps!

Sven

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of David 
Curry
Sent: Friday, January 4, 2013 2:44 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Revisiting wireless NAC

Hello,

We're currently in the process of re-designing our wireless network to split it into a guest side and a "secure" side, 
add a guest management system, replace the captive portal sign-on with 802.1X authentication on the secure side, etc. 
As part of this project, we're also taking a look at our use of Network Access Control and thinking about what we're 
really trying to accomplish. At the moment, we use a "permanent agent" based NAC on PCs and Macs connecting to the 
wireless network, but the only policy we enforce is that the computer must have antivirus running with up-to-date 
signatures. If the connecting computer doesn't pass that check, we put it into a remediation VLAN.

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 because malware has changed, and an argument can perhaps even be made that now that 
Windows and Mac OS X come with built-in firewalls and whatnot, the requirement to have antivirus installed is obsolete. 
And then there's the fact that the majority of devices on our wireless network now are not PCs and Macs anyway, and our 
existing NAC doesn't do anything with those. So, given all that plus some of the push-back we've received from our user 
community about the NAC requirement in general and this specific NAC in particular, we started thinking...

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. 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 (with a captive portal or whatever) that his/her computer may be infected with malware 
and provided with advice/tools on cleaning it up. This seemed easy enough, but when we started looking for products, we 
couldn't find any. There are plenty of IDS/IPS systems out there that can detect and block the traffic; that part's 
easy. But we've been unable to find any products that can also do the other part--sending users to some sort of 
quarantine/remediation portal so that they know why their computer isn't working on the network anymore. This last part 
is critical to us, as we do not run a 24x7 help desk, and we don't want to just silently drop users' traffic with no 
explanation when there's nobody they can call to find out what's happening.

So finally, my question: Has anybody implemented something like this? If so, would you be willing to share how you did 
it?

Thanks,
--Dave




--

DAVID A. CURRY, CISSP * DIRECTOR OF INFORMATION SECURITY

THE NEW SCHOOL * 55 W. 13TH STREET * NEW YORK, NY 10011

+1 212 229-5300 x4728 * david.curry () newschool edu <mailto:david.curry () newschool edu>


________________________________

No department at FGCU will EVER ask you for your username and password in person or through e-mail. If you receive an 
e-mail requesting your EagleMail or FGCU email password, DO NOT respond. Delete the e-mail immediately. If you receive 
a questionable e-mail, please contact the Help Desk at 239-590-1188.

________________________________

BUSINESS TECHNOLOGY SERVICES WILL NEVER ASK FOR YOUR PASSWORD. You should never give out your username or password for 
any accounts you have, including bank accounts, credit card accounts, and other personal or University accounts. 
Business Technology Services will never contact you using a return e-mail address that is not @fgcu.edu. If you receive 
a questionable e-mail or an e-mail asking for passwords and logon information, DO NOT RESPOND, and please contact the 
Help Desk at 239-590-1188.